SSL‑owa zielona kłódeczka — czy naprawdę zapewnia nam bezpieczeństwo?
21.08.2016 11:51
Bezpieczeństwo przesyłanych danych w globalnej sieci jest jednym z ważniejszych zagadnień. Codziennie wykonywane są miliony przelewów, transakcji w sklepach internetowych, czy mikropłatności w aplikacjach. Wielokrotnie przesyłamy na daną stronę WWW informacje, które nie powinny zostać odczytane przez nikogo postronnego (jak np.: informacje o zdrowiu w usłudze Microsoft HealtVault). Wierzymy, że poufność przesyłanych danych zapewni nam zielona kłódeczka, czyli protokół HTTPS. Chociaż ostatnio pojawia się coraz więcej, coraz poważniejszych ataków, czy należy zacząć się obawiać? Jeśli chcesz się dowiedzieć co nieco o protokole, który zabezpiecza transmisje w całym współczesnym Internecie, to przeczytaj.
Co chroni nasze dane podczas wędrówki przez sieć Internet?
Alicja wysyła wiadomość do Boba … (atak Man In The Middle)
Załóżmy, że mamy dwie strony transmisji – Alicję i Boba. Alicja wysyła wiadomość do Boba. Nie ma tu nic dziwnego. Przypuśćmy że pomiędzy nich wepnie się Ewa (osoba atakująca). Alicja, wysyłając wiadomość do swojego kumpla, tak naprawdę wyśle ją do Ewy, gdyż będzie to jedyna możliwa trasa. Ewa będzie mogła odczytać korespondencję adresowaną do przyjaciela Alicji. Żeby nie budzić podejrzeń, transmisja jest kontynuowana. Bob otrzymuje wiadomość. Nie wie i nie ma jak się dowiedzieć, że jej treść została wcześniej poznana przez atakującą osobę. Ten atak jest podręcznikowym przykładem przechwycenia danych, kiedy nie stosujemy żadnej formy zabezpieczenia danych. Powyżej zobrazowany atak zwie się profesjonalnie: „Man In the Middle”.
Powyższy (uproszczony) przykład udowadnia, że przechwycenie niezaszyfrowanych danych płynących przez sieć Internet jest banalne. Dlaczego? Jednymi z pierwszych urządzeń, które służyły do łączenia kilku komputerów w jedną sieć, były HUB‑y, czyli koncentratory. Ze względu na swoją zasadę działania, każdy z podłączonych komputerów mógł odbierać także dane adresowane do innych urządzeń. Sytuacja trochę się poprawia, kiedy zastosujemy Switch (przełącznik). Wtedy, aby przechwycić dane przeznaczone dla innego urządzenia w sieci lokalnej musimy już wykonać tzw. ARP Spoofing. Mimo dziwnie brzmiącej nazwy, jest to czynność bardzo prosta, która wymaga wydania zaledwie kilku poleceń w konsoli systemu. (Jeśli chcesz wiedzieć więcej, odsyłam do śledzenia pisanego przeze mnie kursu Packet Tracer 6.2 - od zera do sieci tworzenia ).
Historia SSL
Ochrona danych przed odczytem przez osoby trzecie nie jest problemem nowym. Kwestia ta była rozpatrywana już od starożytności (np.: szyfr Cezara). Wraz z upływem lat, kiedy pospolity człowiek posiadał coraz większą wiedzę, również i metody szyfrowania musiały ulec poprawie. Standardy kryptografii, które są obecnie powszechnie wykorzystywane, zostały wymyślone na kilka lat przed powstaniem Internetu, jaki znamy dzisiaj. Amerykańscy i izraelscy kryptolodzy opracowali zestaw algorytmów, które zapewniały poufność danych i weryfikację tożsamości. Wynik prac ochrzczono mianem PKI, czyli infrastruktury klucza publicznego. Rozwiązania te trochę zakurzyły się na półce, zanim zostały użyte w praktyce. Na drodze do ich powszechnego zastosowania stanęło kilka problemów – zaczynając od kwestii natury prawnej, na problemach technicznych kończąc.
Pierwszą firmą, która wzięła się za wdrożenie nieużywanych dotąd rozwiązań było Netscape – twórca popularnego w swoich czasach Netscape Navigatora. Wersja pierwsza standardu SSL została opracowana bardzo szybko. Nie została wprowadzona do żadnej wersji przeglądarki, gdyż wiązało się z nią sporo problemów. Przede wszystkim, SSLv1 nie posiadało mechanizmu sum kontrolnych. Dlaczego stanowiło to problem? W swojej długiej drodze przez routery dane mogą zostać przypadkowo zmienione, ot, na przykład, przez miernej jakości kabel. Dzięki systemowi sum kontrolnych możemy stwierdzić, czy przesyłane informacje nie zostały w ten sposób uszkodzone. Innym problemem był brak numeracji pakietów. Atakujący mógł wykorzystać te kwestie w niecnych celach. Te i wiele innych wad czyniły protokół SSLv1 podatnym na działania cyberprzestępców.
Działającego SSL‑a, oznaczonego numerem 2, mogliśmy zobaczyć już w pierwszej wersji słynnego Netscape Navigatora. Pozwalała już zweryfikować poprawność pakietu dzięki MD5.
Microsoft, główny rywal Netscape’a, który trochę spóźnił się na imprezę, rok później wydał pierwszą wersję Internet Explorera. Pokuszono się o wprowadzenie konkurencyjnego do SSL’a protokołu PCT (Private Communication Technology – Technologia Prywatnej Komunikacji). Co najciekawsze, PCT i SSLv2 praktycznie niczym się nie różniły. Były zresztą ze sobą kompatybilne. Format kodowania i przesyłania danych zarówno w przypadku SSL jak i PCT jest taki sam. W PCT wprowadzono kilka zmian mających na celu uodpornienie na znane ataki. Jakie były problemy SSLv2? Spójrzmy na dwa najważniejsze problemy.
- W SSLv2 certyfikat strony musiał być podpisany bezpośrednio przez zaufany główny urząd certyfikacji. SSLv3/PCT znosi ten problem, wprowadzając tzw. ścieżki certyfikacji.
- SSLv2 używało tego samego klucza zarówno do negocjacji połączenia, jak i szyfrowania. Dodatkowo, klucze były niezbyt długie (40 bitów). SSLv3/PCT znosi to ograniczenie.
Odpowiedzią Netscape’a było wprowadzenie protokołu SSLv3. Poza nowościami wprowadzonymi wcześniej przez PCT, nie wymyślono nic nowego.
Microsoft w 1996 jeszcze bardziej skomplikował sytuację, proponując rozwój protokołu STLP (Secure Transport Layer Protocol). Co wprowadzał nowego w stosunku do znanych już SSL i PCT? Niewiele – wsparcie dla protokołu UDP, ulepszenia w potwierdzeniu tożsamości klienta i kilka łatek mających zwiększyć wydajność całego procesu.
Gigant z Redmond, aby zwiększyć swoje szanse w rywalizacji z Netscapem, zaczął integrować Internet Explorera ze swoimi produktami. Netscape nie miał szans wygrać tej wojny. Wobec tego powołano stowarzyszenie Transport Layer Security, które miało ujednolicić protokoły szyfrowania. Wynikiem prac było opublikowanie w 1999 roku pierwszej wersji protokołu TLS, która w niektórych wypadkach, używana jest do dzisiaj.
Jak TLS dba o poufność danych?
Jeśli kiedykolwiek klikałeś na zieloną kłódeczkę, zapewne zauważyłeś, że w wyświetlonym okienku informacyjnym bardzo często powtarzają się takie słowa jak certyfikat, klucz publiczny, itd. Co to takiego jest? Jak to wpływa na poufność przesyłanych przez nas danych? Zastanówmy się.
Przede wszystkim, odpowiedzmy sobie na jedno pytanie: Skąd użytkownik ma wiedzieć, że dana witryna jest oryginalna? Przecież, jak to zostało przedstawione w poprzednim rozdziale, włamywacz może bardzo prosto podsłuchać komunikację. Ba, może nawet postawić fałszywą wersję strony WWW! My, jako że zwykle nie jesteśmy zafascynowanymi informatyką geekami, na pewno nie zauważymy takiej próby ataku. Atakujący też może utworzyć szyfrowane połączenie, czyż nie? Pomimo to, przeglądarka bez problemu rozpozna że taka witryna to podróbka i bardzo subtelnie nas informuje o swoich przypuszczeniach.
Tajemnica tkwi w samej zasadzie działania protokołu TLS. Na czym to polega? Całe bezpieczeństwo transmisji danych oparte jest na zaufaniu. Na całym świecie istnieje kilkadziesiąt tzw. Głównych Urzędów Certyfikacji. Osoba, która chce, aby serwer używał szyfrowania, może sama wygenerować sobie parę kluczy publiczny-prywatny. Niestety, na nic się to nie zda, jeżeli te klucze nie zostaną podpisane cyfrowo przez zaufany Urząd Certyfikacji. Urzędy te wydają specjalne cyfrowe certyfikaty, które składają się z wcześniej wspomnianego klucza publicznego (który, jak sama nazwa wskazuje, może być jawny) oraz odpowiadającego mu klucza prywatnego. Certyfikat jest podpisany przez Urząd Certyfikacji. Klucz prywatny jest trzymany w tajemnicy przez właściciela certyfikatu. Certyfikat wydawany jest zwykle na określony czas, po którym należy go odnowić. Obowiązkiem CA (Certificate Authority) jest weryfikacja wnioskodawcy. Dzięki temu, każda ze stron uczestniczących w komunikacji może wierzyć w jej poufność.
Warto zauważyć, że typowy administrator nie kupuje certyfikatu w głównym urzędzie certyfikacji (np.: Verisign) tylko w pomniejszych firmach (np.: nazwa.pl). Mimo to, dalej certyfikat ten jest akceptowany przez przeglądarkę. Dlaczego? Główny Urząd Certyfikacji może „podpisać” certyfikat innego urzędu. Dzięki temu, każdy certyfikat wydany przez „pośredni urząd certyfikacji” będzie zaufany. Przeglądarka prześledzi ścieżkę certyfikacji. Jeśli certyfikat jest poprawny oraz na szczycie hierarchii znajdzie certyfikat zaufanego głównego urzędu certyfikacji, to znaczy, że certyfikat nie jest podrobiony.
Klucz publiczny i prywatny
Szyfr stosowany do negocjacji połączenia w protokole TLS to szyfr asymetryczny. Używa się w nim dwóch kluczy – publicznego, znanego wszystkim i prywatnego – znanego tylko przez odbiorcę/właściciela certyfikatu. Zastanówmy się, co to jest i po co się stosuje klucz publiczny i klucz prywatny? Po prostu, informacje zaszyfrowane za pomocą klucza publicznego, możemy odszyfrować jedynie za pomocą klucza prywatnego. Nie jest możliwe odszyfrowanie danych, zaszyfrowanych kluczem publicznym, nie mając do dyspozycji odpowiadającego mu klucza prywatnego. Klucze te są „matematycznie” ze sobą powiązane. Każdemu z kluczy publicznych będzie zawsze odpowiadał jakiś klucz prywatny.
Dlaczego typowa komunikacja po protokole TLS jest odporna na typowy atak Man In the Middle?
Wróćmy do przykładu z Alicją i Bobem, przytoczonym na początku artykułu. Jak wyglądałaby komunikacja przy zastosowaniu protokołu TLS?
Alicja, zanim wyśle wiadomość do Boba, najpierw musi wynegocjować połączenie. Przede wszystkim należy ustalić, jakich zasad szyfrowania oraz jakiego klucza symetrycznego będziemy używali. Bob wysyła swój certyfikat i klucz publiczny do Alicji. Alicja weryfikuje, czy te dane są prawidłowe. Jeśli nie, wyświetlane jest ostrzeżenie. Jeśli tak – negocjacja połączenia jest kontynuowana. Jednym z ostatnich etapów jest wymiana liczbami losowymi, które posłużą do konstrukcji klucza symetrycznego. Bob do Alicji swoje liczby wysyła otwartym tekstem. Natomiast liczby Alicji są szyfrowane kluczem publicznym Boba. Ewa, podsłuchująca transmisję, nie będzie mogła odgadnąć tych liczb, a przez to nie będzie mogła odszyfrować dalszej części transmisji. W uproszczeniu, tak właśnie działa protokół TLS.
Szukamy haczyków ...
Weryfikacji certyfikatu serwera nie wykonujemy ręcznie. Byłoby to niezwykle uciążliwe. Zamiast tego, każdy system operacyjny, czasem nawet przeglądarki, posiadają bazę zaufanych głównych urzędów certyfikacji. Jeśli certyfikat, który zgłasza witryna nie jest podpisany przez żaden z zaufanych urzędów, wyświetlane jest ostrzeżenie.
Niestety, w tym miejscu możemy zauważyć jedno poważne zagrożenie dla bezpieczeństwa całego systemu. Jak już wcześniej powiedzieliśmy, cały system kryptografii klucza publicznego opiera się na zaufaniu. My, korzystając np.: z systemu operacyjnego Windows, z założenia ufamy certyfikatom wszystkich firm, które zostały umieszczone w bazie danych systemu. Ufamy nie tylko im, ale także wszystkim firmom pośrednim, których certyfikaty zostały podpisane przez główne urzędy certyfikacji. Istnieje tu pewne zagrożenie. Teoretycznie, urząd powinien skontrolować np.: czy wnioskodawca posiada prawa do danej domeny, czy podał prawidłowe dane osobowe i tym podobne rzeczy. Ale tak przecież być nie musi. Czarna walizka z nowymi studolarowymi banknotami czasami potrafi zdziałać cuda i uczynić rzeczy niemożliwe całkiem prawdopodobnymi. Dodatkowo, nie musimy wysłać jej do głównego urzędu certyfikacji, albo nawet urzędu umieszczonego w naszym kraju. Certyfikaty nie są wydawane ze względu na rejon. Urząd ze Sri‑Lanki czy Zimbabwe (o ile oczywiście jego certyfikat został zatwierdzony np.: przez VeriSign) ma takie same prawa do wydania certyfikatu dla www.ipko.pl jak Symantec czy Microsoft. Przestępca, posiadając taki plik, może bez problemu stworzyć fałszywą wersję witryny, a my jej zaufamy. Dane logowania do banku to jedna sprawa, ale tym samym sposobem możemy stworzyć fałszywy serwer poczty elektronicznej i odczytywać e‑maile, które wysyła ofiara. Czy system operacyjny/przeglądarka posiada jakiś powód, aby nie ufać takiemu certyfikatowi? Nie. Jedynym rozwiązaniem wydaje się być ręczna weryfikacja każdego certyfikatu i każdej strony, ale pospolity człowiek ani nie posiada tyle czasu, ani nie dysponuje odpowiednimi narzędziami, aby taką weryfikację przeprowadzić. Niestety, ten problem wynika z samej zasady działania systemu i w najbliższym czasie najprawdopodobniej nie pojawi się sensowne rozwiązanie tego problemu.
SSL-owa zgadywanka
Nasuwa ci się pewnie na myśl pytanie – czy nie możemy „odgadnąć” klucza prywatnego na podstawie przechwyconych danych oraz znajomości klucza publicznego? Teoretycznie jest to możliwe. Jednakże, istnieje jeden bardzo poważny problem natury wydajnościowej. Każdy procesor krzemowy bardzo lubi mnożenie (szczególnie przez 2), nieco mniej odejmowanie lub dodawanie. Układy te natomiast, nienawidzą dzielenia. I właśnie na tym problemie bazuje cała kryptografia klucza publicznego. W dużym uproszczeniu, zarówno klucz prywatny jak i publiczny powstają dzięki pomnożeniu dwóch ogrooomnych liczb pierwszych. Liczby te mają średnio ponad 1000 cyfr. Mnożenie, jak wcześniej powiedzieliśmy, jest dla komputerów bardzo proste. Jednakże, wykonanie odwrotnej operacji jest niezmiernie trudne. Znając wynik wcześniej omawianego mnożenia, jest praktycznie niemożliwością odgadnąć takie liczby pierwsze, aby pomnożone przez siebie dały oczekiwany wynik. Właśnie na tej zasadzie oparte jest bezpieczeństwo przesyłanych przez nas w Internecie danych.
Jeśli dobrze przeanalizowałeś wcześniejszy przykład (lub spojrzałeś na jeden z wcześniejszych schematów), z pewnością zauważyłeś, że kryptografia klucza publicznego jest używana jedynie w początkowej fazie połączenia – w tak zwanym procesie negocjacji. Wtedy właśnie serwer i klient uzgadniają między innymi, jakiego algorytmu szyfrowania symetrycznego będą używali w dalszej części komunikacji. Serwer i klient wymieniają się także losowo wygenerowanymi liczbami (klient oczywiście szyfruje swój wynik kluczem publicznym serwera). Następnie niezależnie od siebie, na podstawie wymienionych danych generują klucz symetryczny używany w dalszej części połączenia.
W przeciągu ostatnich lat powstało wiele, zarówno teoretycznych, jak i praktycznych ataków na SSL. Ataki te dotyczą nie tylko samych założeń protokołu TLS, lub towarzyszących mu innych protokołów, ale także poszczególnych ich implementacji. Duże znaczenie mają na przykład luki w przeglądarkach internetowych, czy nieprzestrzeganie przez nie polityki Same Origin Policy.
Omówiliśmy, dlaczego SSL/TLS jest (w większości przypadków) bezpiecznym protokołem. Zastanówmy się teraz, jak, na przestrzeni ostatnich lat, próbowano obejść zabezpieczenia SSL.
Ataki na SSL/TLS
Istnieje dość sporo ataków na protokół TLS. Każdy z nich nie atakuje samej kryptografii klucza publicznego – na dzisiejszych komputerach łamanie 4096 bitowego klucza RSA jest praktycznie nieosiągalne. Każdy ze znanych ataków próbuje:
- całkowicie wyłączyć szyfrowanie,
- zmienić proces negocjacji, aby użyto słabego zestawu kryptograficznego
- bazować na błędach i sytuacjach, których nie przewidzieli programiści.
Zajmijmy się najpierw bardziej spektakularnymi, ale i trochę skomplikowanymi atakami. Pierwszy pod nóż pójdzie BEAST.
BEAST
Zanim przejdziemy do analizy samego ataku, najpierw wyjaśnijmy sobie, co to jest szyfr blokowy. Takim szyfrem jest na przykład popularny w dzisiejszych czasach AES. Przed zaszyfrowaniem musimy tekst jawny podzielić na bloki określonej długości. Każdy z nich oddzielnie szyfrujemy danym kluczem, a następnie składamy w szyfrogram. Niestety, powstaje pewien problem. Jeśli dwa bloki będą miały identyczną zawartość (np.: „Mam kota”, „Mam kota”). To szyfrogram będzie taki sam w obu przypadkach. Aby tego uniknąć, wymyślono tzw. tryb wiązania bloków zaszyfrowanych (CBC). Co on robi? Na samym początku, przed rozpoczęciem komunikacji, generowany jest wektor inicjujący, oznaczany często symbolem IV. Wynik szyfrowania za pomocą operacji XOR jest łączony z wektorem inicjującym. Tak oto powstały szyfrogram jest już właściwym tekstem zaszyfrowanym.
Drugi blok natomiast nie jest już „xorowany” z wektorem inicjującym, ale z pierwszym blokiem. Trzeci blok z drugim, czwarty z trzecim itd. Spójrzmy na „tablicę prawdy” przy operacji XOR:
Wyobraźmy sobie teraz następujący scenariusz: Józef (dla odmiany :) ) wysyła wiadomość do Adolfa. Przeprowadzają proces negocjacji itd. Henryk przechwytuje szyfrogramy. Atakujący nie zna nic. Może za to „wstrzyknąć” swój kod do przeglądarek ofiar. Wektor inicjujący jest łatwy do odgadnięcia na podstawie obserwacji poszczególnych szyfrogramów. Załóżmy, że udało się go znaleźć.
Spójrzmy na te kilka wzorów:
Szyfrogram2 = AES(klucz,jawny2 xor szyfrogram1) – tak zostanie zaszyfrowany nasz blok
Szyfrogram1=AES(klucz,jawny1 xor IV) – tak był zaszyfrowany szyfrogram1
Henryk próbuje zgadnąć treść szyfrogramu. Oznaczmy tę próbę słowem prjawny
Prjawnydozaszyfrowania = IV xor prjawny xor szyfrogram1
Henryk wysyła teraz wynik swojego działania do zaszyfrowania
Prszyfrogram = AES(klucz, IV xor prjawnydozaszyfrowania)
Prszyfrogram = AES(klucz, IV xor IV xor prjawny xor szyfrogram1)
Prszyfrogram = AES(klucz, prjawny xor szyfrogram1)
Teraz wystarczy porównać Prszyfrogram z Szyfrogram2. Jeśli są takie same, to znaczy, że Henryk „zgadł” (czyli odszyfrował) co Józef chciał przekazać Adolfowi.
Zgadnięcie nawet 64 bitowej liczby (czyli 8 literowego słowa) jest dość trudne. Na czym polega więc drugi myk? Henryk musi znać choćby część tekstu jawnego, który przesyła Adolf do Józefa. Przykładowo: Adolf wysyła „Atakujemy 1709”. Jeśli Henryk wie, że w treści szyfrogramu występuje słowo „Atakujemy” to wystarczy zgadnąć jedynie cztery cyfry, co znacznie zmniejsza liczbę możliwych kombinacji. Możliwa jest także taka manipulacja strumieniem wejściowym, że będziemy odgadywali po jednym bajcie tekstu. Dzięki temu dla czteroliterowego słowa będziemy musieli przetestować maksymalnie 4*256 kombinacji. Jednakże, atak ten nadal jest mocno niepraktyczny, gdyż wymaga włamania się do sieci lokalnej oraz wstrzyknięcia do przeglądarki złośliwego kodu Javascript/apletu Javy. Ktoś musiałby być naprawdę zdeterminowany, aby wypróbować to na nas. Dodatkowo, wersje TLS 1.1 oraz 1.2 przez zmianę sposobu działania trybu CBC są odporne na opisany powyżej sposób działania.
Atak BREACH
Obecnie dostęp do Internetu jest bardzo powszechny. Niestety, o ile Internet stacjonarny najczęściej jest nielimitowany, o tyle mobilne okno na świat najczęściej posiada ograniczenia w ilości przesyłanych danych. Aby zmniejszyć koszty, staramy się oszczędzić jak najwięcej transferu na przeglądaniu stron. HTTP oraz HTTPS wspierają kompresję, która nieco zmniejsza rozmiar przesyłanych danych. Właśnie na tym polega następny z omawianych ataków – BREACH
HTTP najczęściej korzysta z algorytmu Deflate. Na czym on polega? W uproszczeniu, jeśli jakiś ciąg znaków jest często powtarzany, to powtórzenia usuwamy. Na przykład następujący tekst: [code=text]Ala ma dwa koty. Jej koty są bardzo ładne.[/code] mógłby zostać skompresowany do
Ala ma dwa koty. Jej [4,6] są bardzo ładne.”
No dobrze, kompresja kompresją, ale gdzie tu jest luka? Tekst po kompresji się zmniejszy, to jest pewne. Aby przeprowadzić atak, musimy mieć możliwość obserwacji ruchu sieciowego oraz wstrzyknięcia kodu javascript do przeglądarki ofiary. Dzięki temu w imieniu osoby, której dane chcemy przechwycić będziemy mogli wysyłać zapytania do serwera WWW. Obserwując rozmiar zaszyfrowanych pakietów, możemy odgadnąć interesujące nas dane. Jakkolwiek, żebyśmy padli ofiarą tego ataku, ktoś rzeczywiście musiałby nas obrać za cel.
W tym miejscu wspomnę o najnowszym osiągnięciu techniki – ataku HEIST, przedstawionym na ostatniej konferencji Blackhat. W skrócie, działa tak samo jak atak BREACH. Wszakże, dzięki zastosowaniu pewnych technik, nie wymaga ataku Man In the Middle. Dzięki temu wystarczy, że przekonamy ofiarę do wejścia na zainfekowaną stronę. Na szczęście, większość obecnych stron WWW nie wspiera kompresji przy użyciu protokołu HTTPS. Dzięki temu pole działania domniemanego cyberprzestępcy jest bardzo ograniczone.
SSLstrip
SSLstrip – narzędzie najczęściej używane przez tzw. „script kiddles” (dla niewtajemniczonych, są to osoby, które nie muszą znać zasady działania danego ataku, aby go wykorzystać. Dostają gotowe narzędzia, które mogą posłużyć do niecnych celów). Jak to narzędzie działa?
Wyobraźmy sobie następującą sytuację. Alicja próbuje połączyć się z Bobem. Bob mówi do Alicji: „Mogę szyfrować nasze dane, jeśli ty możesz je odczytać, to ustalmy bezpieczny kanał komunikacji”. Ewa, podsłuchująca ruch sieciowy, odczytuje informację Boba. Trochę ją modyfikuje i w imieniu Boba mówi do Alicji: „Hej, to ja, Bob. Niestety, w chwili obecnej nie mogę nic szyfrować. Porozumiemy się otwartym tekstem?”. Alicja nie ma innego wyboru. Musi użyć nieszyfrowanego protokołu http. Dzięki temu Ewa może bez większych problemów podsłuchiwać transmisję.
Niestety, ten rodzaj ataku także jest dzisiaj nieskuteczny. Dlaczego? Ponieważ każda przeglądarka wspiera HSTS. Na czym polega zasada działania tej technologii? Wróćmy do poprzedniego przykładu.
Bob mówi do Alicji: „Mogę szyfrować nasze dane, jeśli ty możesz je odczytać, to ustalmy bezpieczny kanał komunikacji”. Ewa, podsłuchująca ruch sieciowy, podobnie jak w poprzednim wypadku, odczytuje informację Boba. Trochę ją modyfikuje i w imieniu Boba mówi do Alicji: „Hej, to ja, Bob. Niestety, w chwili obecnej nie mogę nic szyfrować. Porozumiemy się otwartym tekstem?”. Alicja, wiedząc, że z Bobem zawsze łączyła się używając szyfrowania wie, że coś poszło nie tak. Przerywa komunikację z Bobem. Dzięki temu Ewa nie przejmie żadnych poufnych informacji.
Poodle attack
Poodle jest ostatnim atakiem, jakim zajmiemy się w tym artykule. Jeśli uważnie przeczytałeś treść poprzednich rozdziałów, z pewnością pamiętasz co mówiliśmy o SSLv2 oraz SSLv3. Są to stare protokoły, pełne różnych luk w zabezpieczeniach. Powstaje więc pytanie, dlaczego nie zmusić stron do użycia właśnie jednego z tych protokołów? Właśnie na tym bazuje Poodle. Metodą podobną jak SSlstrip zmusza serwer i klienta, aby użyli starego protokołu szyfrowania. Niestety, również ten atak obecnie jest niepraktyczny, gdyż duży odsetek stron WWW nie wspiera renegocjacji połączenia. Spora część serwerów nie udostępnia także leciwego SSLv3.
Podsumowanie
Tak więc, zielona kłódeczka jeszcze długo pozostanie pewnym zabezpieczeniem. Oczywiście pod warunkiem, że wszystkie urzędy certyfikacji będą spełniały swą rolę należycie i nie będą podatne na wpływy pewnych grup. W takim wypadku wystarczy zachować standardowe procedury bezpieczeństwa – nie wchodzić na podejrzane strony oraz aktualizować na bieżąco oprogramowanie. Może nie lubimy, gdy ktoś nam wciska aktualizacje na siłę (Windows 10), ale jest to jedna z niewielu metod, które mogą przyczynić się do większego bezpieczeństwa nieświadomych zagrożeń użytkowników Internetu.
