r   e   k   l   a   m   a
r   e   k   l   a   m   a

Kolejny ciekawy atak na TLS: kiedy przestaniemy korzystać z szyfru RC4?

Strona główna Aktualności

Nie pierwszy to raz, kiedy stojący u podstaw bezpieczeństwa Internetu protokół TLS stał się celem udanego ataku kryptografów. W 2002 roku po raz pierwszy wykazano podatność TLS na ataki typu padding oracle (którego twórczym rozwinięciem jest tegoroczny atak Lucky 13). W 2011 roku badacze Duong i Rizzo zaprezentowali słynnego BEAST-a – przeglądarkowy exploit przeciwko SSL/TLS, by rok później przedstawić CRIME – atak wymierzony nie tylko przeciwko połączeniom HTTPS, ale też i google'owemu SPDY. Biorąc pod uwagę to, że jeszcze w lutym tego roku jedynie 20 procent webowych serwerów stosowało implementacje SSL/TLS odporne na te wszystkie ataki, można powiedzieć, że opowieści wystawców certyfikatów SSL o jakimś niezwykłym bezpieczeństwie gwarantowanym przez „kłódeczkę” przy adresie strony internetowej, można między bajki włożyć. A to przecież nie koniec problemów z TLS.

Nowy atak, przygotowany przez badaczy AlFardana, Bernsteina, Patersona, Poetteringa i Schuldta nie ma ciekawej nazwy, nazywa się po prostu AlFBPPS (podobno używanie seksownych akronimów stało się passé). Pozornie wydaje się też dość akademicki – aby go zrealizować, należy przechwycić miliony połączeń przenoszących takie same dane. Pozwala też przechwycić jedynie pierwszych kilkaset bajtów zaszyfrowanych danych. Jednak jego znaczenie, jak dowodzą autorzy, tkwi w czymś innym: demonstruje ryzyko stosowania powszechnie wykorzystywanego w oprogramowaniu szyfru RC4.

Co RC4, szyfr symetryczny (używający tego samego klucza do szyfrowania i deszyfrowania) miałby mieć wspólnego z TLS, bazującym na kryptografii klucza publicznego? Otóż TLS jedynie częściowo korzysta z kluczy publicznych. Ich wykorzystanie jest zbyt powolne dla całego ruchu sieciowego, więc para kluczy prywatny/publiczny wykorzystywana jest tylko przy inicjalizacji połączenia i wygenerowaniu losowego klucza, który będzie wykorzystywany w symetrycznym szyfrowaniu, obejmującym wszystkie pozostałe dane przesłane po połączeniu. Jaki to szyfr symetryczny – nie jest powiedziane. Jedna z najpopularniejszych implementacji TLS, OpenSSL, zapewnia m.in. obsługę szyfrów AES, DES, Blowfish i RC4.

Ten ostatni, mimo znanych słabości, jest stosowany wciąż bardzo często – według autorów nowego ataku, około 50 procent całego ruchu TLS w Sieci jest szyfrowana za pomocą RC4. Najwyraźniej twórców oprogramowania nie przejęły specjalnie odkrycia z początku tego stulecia, kiedy to Adi Shamir (ten od szyfru RSA) i Itsik Mantin przedstawili praktyczny atak na RC4 (który później pozwolił na łamanie zabezpieczeń bezprzewodowych sieci WEP w ciągu kilku minut). Problem dotyczy jakości zaszyfrowanego przez RC4 strumienia danych – na początku występuje wiele statystycznych anomalii, które można wykorzystać do odczytania zaszyfrowanych danych.

Atak AlFBPPS również wykorzystuje statystyczne anomalie w strumieniu RC4, na sposób dotychczas niespotykany. Badacze przygotowali tablice prawdopodobieństwa wystąpienia każdej wartości bajtowej (od 0 do 255) dla pierwszych 256 pozycji strumienia (łącznie 65536 pomiarów). Dzięki nim, dysponując odpowiednio dużą próbką strumieni RC4, można zgadnąć klucz wykorzystywany w TLS. Technicznie pozyskanie takiej dużej liczby strumieni nie jest w warunkach webowych niewyobrażalne (można np. masowo serwować różnym klientom zaszyfrowane ciasteczka), a z upływem lat i rozrastaniem się Sieci będzie coraz łatwiejsze.

Paul Ducklin z Sophos Security tak opisuje możliwy scenariusz ataku: załóżmy, że wiesz, że 48. bajt jawnego tekstu, P48, jest zawsze taki sam, ale nie wiesz jaki on jest. Inicjujesz więc miliony połączeń TLS, zawierających to stałe, lecz nieznane P48. W każdym połączeniu, używającym losowo wybranego klucza sesji, P48 zostanie zaszyfrowane za pomocą pseudolosowego bajtu szyfru K48, by uzyskać pseudolosowy bajt szyfrogramu C48. Po pozyskaniu milionów różnych próbek C48, wyobraź sobie, że jedna z wartości C48 pojawia się o 1% częściej niż powinna. Nazwijmy tę odchyloną wartość C48 jako C'.

Z tabeli prawdopodobieństwa dla K48 odkrywasz, że bajt szyfru użyty do zaszyfrowania P by uzyskać C' to 208, ponieważ K48 przyjmuje tę wartość o 1% zbyt często. Innymi słowy wartość C' to P XOR 208, więc wartość P to C' XOR 208 – właśnie uzyskałeś 48 bajt jawnego tekstu.

Oczywiście aby tablica prawdopodobieństw dla RC4 znalazła zastosowanie, liczba zebranych próbek musi być duża. Dopiero zainicjowanie 2^32 (4 miliardy) sesji TLS daje prawdopodobieństwo odczytania wszystkich pierwszych 256 bajtów na poziomie 1,0 – jednak dobre wyniki można uzyskać już z 2^24 sesji (16 milionów).

W zasadzie nie ma powodu, dla którego wciąż w WWW spotyka się serwery korzystające z RC4 – dziś wszystkie nowoczesne przeglądarki pozwalają na wykorzystanie znacznie lepszych kryptosystemów. Ducklin z Sophos Security pyta, czy ktokolwiek spośród administratorów, którzy porzucili wsparcie dla TLS-RC4, zauważył przez to jakieś niedogodności? Jak na razie nikt niczego takiego nie zadeklarował – ani na jego blogu, ani w dyskusjach toczących się w innych miejscach Sieci. Może zatem ze słabymi szyframi jest tak, jak z WEP - wciąż korzystają z nich po prostu ci, którzy albo o bezpieczeństwie niewiele wiedzą, albo którym po prostu się nie chce. Najlepszym rozwiązaniem byłoby więc po prostu porzucenie przez producentów przeglądarek wsparcia dla RC4, tak jak w nowych routerach powinno być porzucone wsparcie dla WEP.

r   e   k   l   a   m   a
© dobreprogramy

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.