SSL/TLS Renegotiation Attack

Saldırının üst düzey etkisi, saldırgan kuralına uygun bir istemci-sunucu haberleşmesi içine bir network trafiği enjekte edebilmesi; TLS sunucunun da bu trafiği sanki istemciden geliyormuş gibi kabul etmesidir. Bu da saldırgana sunucu tarafında istemcinin credential bilgileriyle işlemler yürütmesine olanak tanır (Örn: istemci bilgileriyle pizza siparişi gibi). Ancak bu saldırıda saldırgan sunucudan dönecek yanıtı (response) göremeyecektir.

TLS Detayları:
Saldırı, TLS'in renegotiation (yeniden anlaşma) özelliğini kullanır. Bu özellik, aralarında zaten bir TLS bağlantı bulunan istemci ve sunucu arasında yeni parametreler, yeni anahtarlar vb ile yeniden anlaşma yapmasına olanak tanır. Yeniden anlaşma, var olan TLS bağlantısının içinde gerçekleşir.
Saldırının en basit şekli şu şekilde özetlenebilir:

Bir saldırıyı hayata geçirebilmek için saldırgan önce TLS sunucusuna bağlanır. Rasgele sayıda talep/yanıtlarla sunucuyla iletişim kurar. Tü bu trafik kriptoludur ve şekilde "==" ile ifade edilmektedir. Hazır olduğunda, saldırgan, kurbanın sunucu ile olan bağlantısını çalar (hijacking) ve sadece kriptolu kanalda seyreden kurban trafiğini proxy gibi üzerinden akıtır. Kurban, sunucu ile anlaşır ve bu noktadan sonra kurban ile sunucu doğrudan iletişim kurar. Dikkat edilecek nokta, kurban, saldırgan ile açık trafik üzerinden iletişim kurar ama ikinci el sıkışma kriptoludur ve saldırganın kanalı üzerinden yapılır. Bu durumda da kurban, sunucu ile "yeniden" anlaştığını bilmemektedir. Bununla birlikte, sunucu da ilk başta anlatılan saldırgan ile arasında iç trafiğin de kurbandan geldiğini düşünür.

Var olan uygulamalardaki etkisi:
TLS sadece bir güvenlik protokolüdür,bu saldırının etkisi TLS üzerinde koşulan uygulama protokolüne bağlıdır. Bu protokollerin en önemlisi tabi ki TLS üzerinden HTTP (HTTPS)'tir. Çoğu web uygulaması ilk kimlik doğrulamasını kullanıcı adı ve şifre çifti ile gerçekleştirir ve doğrulama durumunu HTTP cookie'ler ile devam ettirir. Bir saldırgan,  bu durumu, kendi özel isteğini anlatan bir HTTP request ön-parçası göndererek exploit edebilir. Sonra bu talep, istemcinin gerçek talebine ön ek olarak takılır.

Örnek:
Diyelim ki saldırgan, şu talep parçasını gönderiyor:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
X-Ignore-This:

ve son satırı, CR/LF (enter) koymadan boş bırakıyor. Sonra istemci kendi talebini gerçekleştiriyor:

GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
Cookie: victimscookie

ve bu iki talep birleşiyor:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
Cookie: victimscookie

Sonuç olarak saldırgan, siparişi için istemcinin hesabını kullanmış oluyor.

Benzer bir saldırı, sunucunun sertifika-tabanlı istemci kimlik doğrulaması kullandığı durumda da gerçekleştirilebilir: İstemci sertifikaları kullanan sunucular için istemcinin bağlanmasına ve bir kaynak talep etmesine izin vermesi ve eğer talep edilen kaynak korunuyorsa yeniden anlaşma (renegotiation) talep etmesi yaygın görülen bir durumdur. Saldırgan şu şekilde bu durumu exploit edebilir: önceden bir anlaşma (handshake) yapar; korunan kaynağı talep eder; yeniden anlaşma (renegotiation) işini de istemciye bırakır. Bu noktada sunucu, ilk talebin de istemciden geldiğini sanacaktır.

Önleme/Hafifletme:
Önlem, uygulamaların %99'undan fazlası için basittir: sunucu basitçe tüm yeniden anlaşmaları (renegotiation) disable eder; bu, saldırıları durduracaktır (OpenSSL, uygulama yeniden anlaşma için kurulmamışsa bile otomatik olarak yeniden anlaşır ve bu şekilde saldırının başarılı olmasında yardımcı olur). İstemci tarafında ise önlem almanın herhangi bir yolu yoktur. Tabi ki bu önlem, yeniden anlaşmanın zorunlu olduğu yaklaşımlar için uygulanabilir değildir.