Zainstalowałem niedawno tę małą, zieloną kłódeczkę na blogu xpil.eu. Oznacza to, że od tej pory transmisja danych między Twoją przeglądarką, a serwerem, na którym blog sobie mieszka, jest chroniona protokołem SSL.
Wszystko działa pięknie i w zasadzie bezobsługowo. Będę tylko musiał pamiętać raz na trzy lata, żeby odnowić certyfikat (co będzie mnie kosztować około €5 raz na trzy lata - jakoś wytrzymam).
Jak bezpieczny jest protokół SSL?
Cóż. Okazuje się, że historia ataków na SSL sięga samych początków jego wynalezienia i od zawsze działała na zasadzie tarczy i miecza. Ponieważ SSL jest odpowiedzialne za większość szyfrowanego ruchu w Internecie, programiści odpowiedzialni za implementację nie zasypiają gruszek w popiele i naprawiają wszelkie dziury w trymiga. Niemniej jednak nie wszyscy administratorzy serwerów na bieżąco aktualizują owe serwery, w związku z czym mamy dziś całkiem pokaźną ilość serwerów "niezałatanych", na które można skutecznie przeprowadzać różnego rodzaju ataki.
Niedawno na moim ulubionym portalu informacyjnym Hacker News pokazały się trzy pod rząd artykuły dotyczące dziur w SSL - dziś króciutko na ten temat. Dwa z tych artykułów opisują całkiem interesujące ataki na SSL.
Dziura pierwsza: "DROWN attack". Okazuje się, że na serwerach, które są zgodne z protokołem SSL w wersji 2, istnieje możliwość złamania kluczy szyfrujących serwera za pomocą ataku znanego już od 1990 roku. Atak ten, bez wchodzenia w szczegóły techniczne za bardzo, polega - w wielkim uproszczeniu - na tym, że serwer odpowiada klientowi, czy wysłany przez niego klucz szyfrujący jest poprawny, czy nie. Poprzez wielokrotne wysyłanie odpowiednio spreparowanych kluczy, atakujący może wreszcie wyliczyć klucz szyfrujący sesji i przechwycić transmisję.
W praktyce wygląda to tak, że atakujący musi najpierw podsłuchać około 1000 uruchomień sesji SSL między klientami a serwerem (tzw. "handshakes"), potem musi zgromadzić około 40000 zapytań do serwera przeprowadzonych w ramach tych sesji, a następnie - już offline - przeprowadzić około biliona różnych operacji arytmetycznych, żeby rozszyfrować co trzeba. I wtedy zawartość wszystkich podsłuchanych sesji będzie dostępna atakującemu. Jeżeli któraś z nich będzie zawierać dane naszej karty kredytowej, albo hasło dostępowe do jakiegoś ważnego konta, możemy być ugotowani. Wszystko to jednak pod dwoma warunkami: że nasz serwer obsługuje starsze wersje SSL oraz że do różnych wersji SSL jest używany ten sam klucz szyfrujący.
Na dzień dzisiejszy około 17% serwerów www na całym świecie jest podatnych na ten rodzaj ataku.
Dziura 2: Atak typu CacheBleed. Tu już nie jest tak groźnie, jak w poprzednim przypadku, ale za to robi się interesująco.
Okazuje się, że można wydedukować zawartość klucza szyfrującego na serwerze wyposażonym w SSL (najnowszą wersję!) poprzez pomiar czasu, jaki jest potrzebny na wykonanie pewnych operacji związanych z szyfrowaniem. Warunkiem skutecznego przeprowadzenia ataku typu CacheBleed jest możliwość wykonania własnego kodu na atakowanym serwerze, dlatego właśnie błąd został zaklasyfikowany jako "mało groźny" - ale fakt pozostaje faktem, da się w ten sposób odczytać zawartość klucza szyfrującego.
Szczegóły metody są dość zawiłe, dlatego skupię się tylko na ogólnej idei: otóż każdy nowoczesny procesor jest wyposażony w podręczną pamięć cache, używaną w celu przyspieszenia operacji zapisu lub odczytu między procesorem a pamięcią RAM. W uproszczeniu, jeżeli procesor potrzebuje odczytać zawartość jakiejś komórki RAM, zawartość owa wraz z zawartością komórek z nią sąsiadujących zostaje zapisana w pamięci podręcznej (cache) procesora. Dzięki temu jeżeli procesor potrzebuje za chwilę odczytać zawartość następnej komórki (bardzo możliwe, że tak właśnie będzie - rzadko kiedy potrzebujemy tylko jednego bajtu z RAM-u), otrzyma te dane z prawie 100x szybszej pamięci podręcznej, bez potrzeby oczekiwania na wolną jak mucha w smole pamięć główną.
Szyfrowanie danych, z matematycznego punktu widzenia, polega tak naprawdę na wielokrotnym mnożeniu i dzieleniu modulo dużych liczb. Te liczby trzeba odczytać z pamięci RAM. Okazuje się, że poprzez analizę statystyczną czasów odczytu i zapisu danych między procesorem a pamięcią podczas obsługi protokołu szyfrującego można wydedukować małe fragmenty tych danych. Po przeprowadzeniu odpowiednio dużej ilości operacji atakujący jest w stanie odczytać około 60% bitów klucza szyfrującego. Pozostałe 40%, ze względu na nadmiarowość klucza, daje się wyliczyć na szybkim procesorze (gdzieś "na boku") w ciągu kilku minut.
Powyższy opis jest bardzo uproszczony. W rzeczywistości atakujący wykorzystuje luki wynikające z tego, że procesor ma wiele rdzeni oraz współdzielone banki pamięci cache. Ale aż tak bardzo nie chce mi się zagłębiać w temat, bo jestem za leniwy 😉
Podsumowując, jak widać zabezpieczenia w Internecie są na tyle dobre, na ile dobre są implementacje protokołów szyfrujących, które trzeba zawsze aktualizować. Innymi słowy, bez regularnego apt-get update; apt-get upgrade ani rusz...
Jeżeli chcesz do komentarza wstawić kod, użyj składni:
[code]
tutaj wstaw swój kod
[/code]
Jeżeli zrobisz literówkę lub zmienisz zdanie, możesz edytować komentarz po jego zatwierdzeniu.