Ogólne

SSL (i jego następca, TLS ) to protokół, który działa bezpośrednio na TCP (chociaż istnieją również implementacje dla protokołów opartych na datagramach, takich jak UDP). W ten sposób protokoły na wyższych warstwach (takich jak HTTP) mogą pozostać niezmienione, podczas gdy s do momentu zapewnienia bezpiecznego połączenia. Pod warstwą SSL protokół HTTP jest identyczny z HTTPS.

Przy prawidłowym korzystaniu z SSL / TLS osoba atakująca może zobaczyć na kablu tylko, z jakim adresem IP i portem jesteś połączony, z grubsza ilością wysyłanych danych i jakie szyfrowanie i kompresja są używane. Może również zakończyć połączenie, ale obie strony będą wiedzieć, że połączenie zostało przerwane przez osobę trzecią.

W typowym użyciu osoba atakująca będzie również w stanie dowiedzieć się, z którą nazwą hosta się łączysz (ale nie reszta adresu URL): chociaż sam HTTPS nie ujawnia nazwy hosta, twoja przeglądarka zazwyczaj musi najpierw wysłać żądanie DNS, aby dowiedzieć się, na jaki adres IP ma wysłać żądanie.

Wysoki -poziom opisu protokołu

Po zbudowaniu połączenia TCP, uzgadnianie SSL jest uruchamiane przez klienta. Klient (który może być przeglądarką lub dowolnym innym programem, takim jak Windows Update lub PuTTY) wysyła szereg specyfikacji:

• która wersja SSL / TLS jest uruchomiona,
• czego ciphersuites chce użyć i
• czego metody kompresji , których chce użyć.

Serwer identyfikuje najwyższą wersję SSL / TLS obsługiwaną zarówno przez niego, jak i przez klienta, wybiera zestaw szyfrów z jednej z opcji klienta (jeśli taką obsługuje) i opcjonalnie wybiera metodę kompresji.

Po wykonaniu podstawowej konfiguracji serwer wysyła swój certyfikat. Ten certyfikat musi być zaufany przez samego klienta lub stronę, której ufa klient. Na przykład, jeśli klient ufa GeoTrust, może zaufać certyfikatowi z Google.com, ponieważ GeoTrust podpisany kryptograficznie certyfikat Google.

Po zweryfikowaniu certyfikatu i upewnieniu się, że ten serwer naprawdę jest tym, za kogo się podaje (a nie człowiekiem w środku), następuje wymiana klucza. Może to być klucz publiczny, a ” PreMasterSecret ” lub po prostu nic, w zależności od wybranego zestawu szyfrów. Zarówno serwer, jak i klient mogą teraz obliczyć klucz dla szyfrowanie symetryczne ^{dlaczego PKE?} . Klient informuje serwer, że od teraz cała komunikacja będzie szyfrowana, i wysyła zaszyfrowaną i uwierzytelnioną wiadomość na serwer.

Serwer sprawdza, czy adres MAC (używany do uwierzytelniania) jest poprawny i czy wiadomość może być poprawnie odszyfrowana. Następnie zwraca wiadomość, którą klient weryfikuje tak jak dobrze.

Uścisk dłoni jest teraz zakończony, a dwa hosty mogą się bezpiecznie komunikować. Aby uzyskać więcej informacji, zobacz technet.microsoft.com/en-us/library/cc785811 i en.wikipedia .org / wiki / Secure_Sockets_Layer .

Aby zamknąć połączenie, używany jest „alert” close_notify. Jeśli atakujący spróbuje zakończyć połączenie poprzez zakończenie połączenia TCP (wstrzyknięcie pakietu FIN), obie strony będą wiedzieć, że połączenie zostało nieprawidłowo zakończone. Jednak połączenie nie może zostać naruszone w ten sposób, a jedynie przerwane.

Więcej szczegółów

Dlaczego możesz zaufać Google.com, ufając GeoTrust?

Witryna chce bezpiecznie komunikować się z Tobą. Aby udowodnić swoją tożsamość i upewnić się, że nie jest to osoba atakująca, musisz mieć „s klucz publiczny serwera. Jednak prawie nie można przechowywać wszystkich kluczy ze wszystkich witryn na świecie baza danych byłaby ogromna, a aktualizacje musiałyby być uruchamiane co godzinę!

Rozwiązaniem tego problemu są urzędy certyfikacji lub w skrócie CA.Po zainstalowaniu systemu operacyjnego lub przeglądarki prawdopodobnie została dołączona lista zaufanych urzędów certyfikacji. Ta lista może być dowolnie modyfikowana; możesz usunąć, komu nie ufasz, dodać innych, a nawet stworzyć własny CA (chociaż będziesz jedyną osobą, która ufa temu CA, więc nie jest to zbyt użyteczne dla publicznych witryn internetowych). Na tej liście urzędów certyfikacji przechowywany jest również klucz publiczny urzędu certyfikacji.

Gdy serwer Google wysyła Ci swój certyfikat, wspomina również, że jest podpisany przez firmę GeoTrust. Jeśli ufasz GeoTrust, możesz zweryfikować (używając klucza publicznego GeoTrust), że GeoTrust naprawdę podpisał certyfikat serwera. Aby samodzielnie podpisać certyfikat, potrzebujesz klucza prywatnego, który jest znany tylko firmie GeoTrust. W ten sposób osoba atakująca nie może samodzielnie podpisać certyfikatu i błędnie twierdzi, że jest Google.com. Gdy certyfikat zostanie zmodyfikowany choćby o jeden bit, znak będzie nieprawidłowy i klient go odrzuci.

Więc jeśli znam klucz publiczny, serwer może udowodnić swoją tożsamość?

Tak. Zazwyczaj klucz publiczny jest szyfrowany, a klucz prywatny odszyfrowuje. Zaszyfruj wiadomość za pomocą klucza publicznego serwera, wyślij ją, a jeśli serwer może powtórzyć oryginalną wiadomość, to właśnie udowodnił, że uzyskał klucz prywatny bez ujawniania klucza.

Dlatego właśnie jest tak ważne, aby móc zaufać kluczowi publicznemu: każdy może wygenerować parę kluczy prywatny / publiczny, także osoba atakująca. Nie chcesz używać klucza publicznego atakującego!

Jeśli jeśli jeden z zaufanych urzędów certyfikacji zostanie naruszony, osoba atakująca może użyć skradzionego klucza prywatnego do podpisania certyfikatu dowolnej witryny sieci Web. Gdy osoba atakująca może wysłać do klienta sfałszowany certyfikat podpisany przez niego kluczem prywatnym z zaufanego urzędu certyfikacji, klient nie wie, że klucz publiczny jest sfałszowany, podpisany skradzionym kluczem prywatnym.

Jednak urząd certyfikacji może sprawić, że będę ufał każdemu serwerowi, jakiego zechce!

Tak, i właśnie tu przychodzi zaufanie Musisz zaufać urzędowi certyfikacji, aby nie wystawiał certyfikatów tak, jak im się podoba. Jeśli jednak organizacje takie jak Microsoft, Apple i Mozilla ufają urzędowi certyfikacji, musi on przeprowadzać audyty; inna organizacja sprawdza je okresowo, aby upewnić się, że wszystko działa zgodnie z regułami.

Certyfikat jest wystawiany wtedy i tylko wtedy, gdy rejestrujący może udowodnić, że jest właścicielem domeny, dla której wystawiono certyfikat.

Co to jest adres MAC do uwierzytelniania wiadomości?

Każda wiadomość jest podpisana tak zwanym kodem uwierzytelniania wiadomości lub MAC w skrócie. Jeśli uzgodnimy klucz i szyfr, możesz zweryfikować, czy moja wiadomość pochodzi ode mnie, a ja mogę sprawdzić, czy Twoja wiadomość pochodzi od Ciebie.

Na przykład za pomocą klucza ” poprawna zszywka baterii konia ” i wiadomość ” przykład „, Mogę obliczyć adres MAC ” 58393 „. Kiedy wyślę ci tę wiadomość z adresem MAC (znasz już klucz), możesz wykonać te same obliczenia i dopasować obliczony adres MAC do adresu MAC, który wysłałem.

Atakujący może zmodyfikować wiadomość ale nie zna klucza. Nie może obliczyć prawidłowego adresu MAC i będziesz wiedział, że wiadomość nie jest autentyczna.

Dołączając numer sekwencyjny podczas obliczania adresu MAC, możesz wyeliminować powtórkę ataki . SSL to robi.

Powiedziałeś, że klient wysyła klucz, który jest następnie używany do konfiguracji szyfrowanie symetryczne. Co powstrzymuje atakującego przed użyciem go?

Klucz publiczny serwera to robi. Ponieważ sprawdziliśmy, że klucz publiczny naprawdę należy do serwera i nikogo innego, może zaszyfrować klucz za pomocą klucza publicznego. Gdy serwer go otrzyma, może go odszyfrować za pomocą klucza prywatnego. Gdy ktoś go otrzyma, nie może go odszyfrować.

Dlatego też rozmiar klucza ma znaczenie: Im większy klucz publiczny i prywatny, tym trudniej jest złamać klucz wysyłany przez klienta do serwera.

Jak złamać SSL

Podsumowując :

• Spróbuj, jeśli użytkownik ignoruje ostrzeżenia dotyczące certyfikatów;
• Aplikacja może ładować dane z niezaszyfrowany kanał (np. HTTP), przy którym można manipulować;
• Niezabezpieczona strona logowania, która przesyła do HTTPS, może zostać zmodyfikowana tak, aby była przesyłana do HTTP;
• Niezałatane aplikacje mogą być podatny na exploity takie jak BEAST i CRIME;
• Użycie innych metod suc h jako atak fizyczny;
• Wykorzystaj kanały boczne , takie jak długość wiadomości i czas formułowane podczas tworzenia wiadomości;
• Poczekaj na ataki kwantowe .

Zobacz też: Schemat z wieloma wektorami ataku na SSL autorstwa Ivana Ristic ^(png)

W szczegółach:

Nie ma prostej i bezpośredniej sposób; SSL jest bezpieczny, jeśli jest wykonany poprawnie. Atakujący może jednak spróbować, jeśli użytkownik zignoruje ostrzeżenia o certyfikatach , co spowoduje natychmiastowe złamanie zabezpieczeń. Gdy użytkownik to robi, atakujący nie potrzebuje klucza prywatnego z urzędu certyfikacji, aby sfałszować certyfikat, wystarczy, że wyśle własny certyfikat.

Innym sposobem może być błąd w aplikacji (po stronie serwera lub klienta). Prostym przykładem są strony internetowe: jeśli jeden z zasobów używanych przez witrynę (np. obraz lub skrypt) jest ładowany przez HTTP, nie można już zagwarantować poufności. Nawet jeśli przeglądarki nie wysyłaj nagłówka HTTP Referer podczas żądania niezabezpieczonych zasobów z bezpiecznej strony ( źródło ), ktoś podsłuchujący ruch może odgadnąć, gdzie „ponownie odwiedzający z; na przykład, jeśli wiedzą, że obrazy X, Y i Z są używane na jednej stronie, mogą odgadnąć, że odwiedzasz tę stronę, gdy zobaczy, że przeglądarka żąda tych trzech obrazów jednocześnie. Dodatkowo podczas ładowania JavaScript cała strona może zostać przejęta. Atakujący może wykonać dowolny skrypt na stronie, modyfikując na przykład, do kogo trafi transakcja bankowa.

Kiedy to się stanie (zasób jest ładowany przez HTTP), przeglądarka wyświetla ostrzeżenie o mieszanej treści: Chrome , Firefox , Internet Explorer 9

Inną sztuczką związaną z HTTP jest to, że strona logowania nie jest zabezpieczona i przechodzi do strony https. ” Świetnie, ” deweloper prawdopodobnie pomyślał, ” teraz oszczędzam obciążenie serwera i hasło jest nadal przesyłane w postaci zaszyfrowanej! ” Problem dotyczy sslstrip , narzędzia, które modyfikuje niezabezpieczoną stronę logowania, przesyła się gdzieś, aby osoba atakująca mogła ją przeczytać.

W ciągu ostatnich kilku lat miały miejsce różne ataki, takie jak luka w renegocjacji TLS , sslsniff , BEAST , a ostatnio PRZESTĘPCZOŚĆ . Wszystkie popularne przeglądarki są jednak chronione przed wszystkimi tymi atakami, więc te luki nie stanowią żadnego zagrożenia, jeśli używasz aktualnej przeglądarki.

Wreszcie, możesz skorzystać z innych metod, aby uzyskać informacje, których uzyskanie przez SSL nie pozwala. Jeśli już widzisz i możesz manipulować połączeniem użytkownika, zastąpienie jednego z jego / jej pobrań .exe keyloggerem lub po prostu fizycznym zaatakowaniem tej osoby może nie być trudne, ale kryptografia może być raczej bezpieczna, ale ludzie a błąd ludzki jest nadal słabym czynnikiem. Według tego artykułu firmy Verizon , 10% przypadków naruszenia bezpieczeństwa danych dotyczyło ataków fizycznych (patrz strona 3), więc „ z pewnością jest to coś, o czym warto pamiętać.

Komentarze

• Chciałbym trochę dokładniej wyjaśnić ” klucz jest wymieniany ” na klucz symetryczny. Jak to się dzieje, że ktoś z snifferem pakietów nie może uzyskać dostępu.
• @Yehosef Dobre pytanie! Zapomniałem to wyjaśnić w swojej odpowiedzi. Rozglądając się po okolicy, okazuje się, że w rzeczywistości jest pytanie poświęcone temu: security.stackexchange.com/q/6290/10863
• @ Iwazaru Wszystkie CA robią to od pierwszego dnia. Celem certyfikatu jest dostarczenie klucza publicznego dla danej domeny, a celem jego podpisania, aby udowodnić, że naprawdę jest to właściwy klucz dla domeny. Niech ' s Encrypt robi dokładnie to, co powinno: weryfikuje własność domeny i podpisuje certyfikat (kluczem), jeśli możesz to udowodnić. Teraz każdy, kto ufa Let ' s Encrypt, czyli praktycznie każda przeglądarka, będzie ufał temu certyfikatowi.
• Eee, nie. TLS jest rzeczywiście właśnie zaimplementowany na szczycie TCP.
• Znaleziono ten graficzny proces uzgadniania SSL , bardzo przejrzysty.

Ponieważ ogólna koncepcja SSL została już omówiona w kilku innych pytaniach (np. ten i tamten ), tym razem przejdę do szczegółów. Szczegóły są ważne. Ta odpowiedź będzie nieco rozwlekła.

Historia

SSL jest protokół z długą historią i kilkoma wersjami.Pierwsze prototypy pochodziły z Netscape, kiedy tworzyli pierwsze wersje swojej flagowej przeglądarki, Netscape Navigator (ta przeglądarka zabiła Mosaic we wczesnych czasach wojen przeglądarek, które wciąż szaleją, aczkolwiek z nowymi konkurentami). Wersja 1 nigdy nie została upubliczniona, więc nie wiemy, jak wyglądała. Wersja SSL 2 jest opisana w wersji roboczej, którą można przeczytać tam ; ma wiele słabych punktów, niektóre z nich są raczej poważne, więc jest przestarzały, a nowsze implementacje SSL / TLS go nie obsługują (podczas gdy starsze są domyślnie dezaktywowane). Nie będę więcej mówić o SSL w wersji 2, z wyjątkiem sporadycznych odniesień.

SSL w wersji 3 (który będę nazywać „SSLv3”) był ulepszonym protokołem, który nadal działa i jest szeroko obsługiwany. Chociaż nadal jest własnością Netscape Communications (lub kogokolwiek, kto jest jej obecnie właścicielem), protokół został opublikowany jako „historyczny dokument RFC” ( RFC 6101 ). W międzyczasie protokół został ustandaryzowany z nową nazwą w celu uniknięcia problemów prawnych; nowa nazwa to TLS .

Do tej pory stworzono trzy wersje TLS, każda z dedykowany RFC: TLS 1.0 , TLS 1.1 i TLS 1.2 . Są wewnętrznie bardzo podobne do siebie i SSLv3, do tego stopnia, że implementacja może z łatwością obsługiwać SSLv3 i wszystkie trzy wersje TLS, przy czym co najmniej 95% kodu jest wspólne. Jednak wewnętrznie wszystkie wersje są oznaczone numerem wersji w formacie major.minor ; SSLv3 to wtedy 3.0, podczas gdy wersje TLS to odpowiednio 3.1, 3.2 i 3.3. Nic więc dziwnego, że protokół TLS 1.0 jest czasami nazywany SSL 3.1 (i też nie jest błędny). SSL 3.0 i TLS 1.0 różnią się tylko kilkoma szczegółami. Protokoły TLS 1.1 i 1.2 nie są jeszcze szeroko obsługiwane, chociaż istnieje do tego bodziec ze względu na możliwe słabości (patrz poniżej „atak BEAST”). SSLv3 i TLS 1.0 są obsługiwane „wszędzie” (nawet IE 6.0 je zna).

Kontekst

SSL ma na celu zapewnienie bezpiecznego dwukierunkowego tunelu dla dowolnych danych. Rozważmy TCP , dobrze znany protokół do przesyłania danych przez Internet. TCP działa na „pakietach” IP i zapewnia dwukierunkowy tunel dla bajtów; działa dla wartości każdego bajtu i wysyła je do dwóch strumieni, które mogą działać jednocześnie. TCP radzi sobie z ciężką pracą polegającą na dzieleniu danych na pakiety, potwierdzaniu ich, ponownym składaniu ich z powrotem we właściwej kolejności, usuwaniu duplikatów i ponownym wysyłaniu utraconych pakietów. Z punktu widzenia aplikacji korzystającej z TCP są tylko dwa strumienie, a pakiety są niewidoczne; w szczególności strumienie nie są dzielone na „wiadomości” (aplikacja musi przyjąć własne reguły kodowania, jeśli chce mieć wiadomości, i właśnie to HTTP ).

TCP jest niezawodny w przypadku wystąpienia „wypadków”, tj. Błędów transmisji spowodowanych niestabilnym sprzętem, przeciążeniem sieci, ludźmi ze smartfonami, którzy wychodzą poza zasięg danej stacji bazowej i inne niezłośliwe zdarzenia. Jednak osoba o złych intencjach („atakujący”) z pewnym dostępem do nośnika transportowego może odczytać wszystkie przesłane dane i / lub celowo je zmienić, a protokół TCP nie chroni przed tym. SSL.

SSL zakłada , że działa na protokole podobnym do TCP, który zapewnia niezawodny strumień; SSL nie realizuje ponownej emisji utraconych pakietów i tym podobnych. Atakujący jest powinien być w stanie całkowicie zakłócić komunikację w nieunikniony sposób (na przykład może przeciąć kable), więc zadaniem SSL jest:

• wykrywać zmiany (atakujący nie może mieć możliwości zmiany danych po cichu );
• zapewnić poufność danych ( atakujący nie może uzyskać wiedzy o wymienianych danych).

SSL spełnia te cele w dużym (ale nie absolutnym) stopniu.

Rekordy

SSL jest warstwowy, a dolna warstwa to protokół zapisu . Wszelkie dane wysyłane w tunelu SSL są dzielone na rekordy . Przez kabel (podstawowe gniazdo TCP lub nośnik podobny do TCP) rekord wygląda następująco:

HH V1:V2 L1:L2 dane

gdzie:

• HH to pojedynczy bajt, który określa typ danych w rekordzie.Zdefiniowano cztery typy: change_cipher_spec (20), alert (21), handshake (22) i application_data ( 23).
• V1: V2 to wersja protokołu, ponad dwa bajty. Dla wszystkich obecnie zdefiniowanych wersji V1 ma wartość 0x03, a V2 ma wartość 0x00 dla SSLv3, 0x01 dla TLS 1.0, 0x02 dla TLS 1.1 i 0x03 dla TLS 1.2.
• L1: L2 to długość data, w bajtach (konwencja big-endian to używane: długość 256 * L1 + L2). Całkowita długość data nie może przekraczać 18432 bajtów, ale w praktyce nie może nawet osiągnąć tej wartości.

Tak więc rekord ma pięć bajtowy nagłówek, po którym następuje maksymalnie 18 kB danych. data to miejsce, w którym stosowane jest szyfrowanie symetryczne i sprawdzanie integralności. Kiedy rekord jest emitowany, zarówno nadawca, jak i odbiorca powinni uzgodnić, które algorytmy kryptograficzne są obecnie stosowane i z którymi kluczami; zgodę tę uzyskuje się za pomocą protokołu uzgadniania, opisanego w następnej sekcji. Kompresja, jeśli w ogóle, jest również stosowana w tym momencie.

Ze szczegółami budowanie rekordu wygląda następująco:

• Początkowo jest kilka bajtów do przesłania ; są to dane aplikacji lub innego rodzaju bajty. Ten ładunek składa się co najwyżej z 16384 bajtów, ale prawdopodobnie mniej (ładunek o długości 0 jest legalny, ale okazuje się, że Internet Explorer 6.0 nie lubi tego w ogóle ) .
• Ładunek jest następnie kompresowany za pomocą dowolnego algorytmu kompresji, który jest aktualnie uzgodniony. Kompresja jest stanowa i dlatego może zależeć od zawartości poprzednich rekordów. W praktyce kompresja ma wartość „null” (brak kompresji) lub „Deflate” ( RFC 3749 ), przy czym ten ostatni jest obecnie uprzejmie, ale stanowczo pokazany jako wyjście door w kontekście internetowym, z powodu niedawnego ataku CRIME . Kompresja ma na celu skrócenie danych, ale w niektórych niekorzystnych sytuacjach musi je koniecznie nieco rozszerzyć (ze względu na zasadę szufladki ). SSL umożliwia rozszerzenie do maksymalnie 1024 bajtów. Oczywiście kompresja zerowa nigdy się nie rozszerza (ale też nigdy nie skraca); Deflate rozszerzy się o maksymalnie 10 bajtów, jeśli implementacja jest dobra.
• Skompresowany ładunek jest następnie chroniony przed zmianami i szyfrowany. Jeśli bieżące algorytmy szyfrowania i integralności mają wartość „null”, wówczas ten krok nie jest wykonywany. W przeciwnym razie dodawany jest MAC , a następnie dopełnienie (w zależności od algorytmu szyfrowania), a wynik jest szyfrowany. Te kroki ponownie wywołują pewne rozszerzenie, które standard SSL ogranicza do 1024 dodatkowych bajtów (w połączeniu z maksymalnym rozszerzeniem z kroku kompresji prowadzi nas to do 18432 bajtów, do których musimy dodać 5-bajtowy nagłówek).

MAC to zwykle HMAC z jedną ze zwykłych funkcji skrótu (głównie MD5, SHA-1 lub SHA-256) (z SSLv3 nie jest to „prawdziwy” HMAC, ale coś bardzo podobnego i, zgodnie z naszą najlepszą wiedzą, równie bezpiecznego jak HMAC). Szyfrowanie będzie wykorzystywać szyfr blokowy w trybie CBC lub szyfr strumieniowy RC4 . Należy zauważyć, że teoretycznie można zastosować inne rodzaje trybów lub algorytmów, na przykład jeden z tych sprytnych trybów, które łączą szyfrowanie i sprawdzanie integralności; istnieje nawet trochę specyfikacji RFC do tego . W praktyce jednak wdrożone implementacje jeszcze o tym nie wiedzą, więc robią to HMAC i CBC. Co najważniejsze, MAC jest najpierw obliczany i dołączany do danych, a wynik jest szyfrowany. To jest kod MAC-następnie-zaszyfrowany i tak naprawdę nie jest zbyt dobrym pomysłem . MAC jest obliczany na podstawie konkatenacji (skompresowanego) ładunku i numeru sekwencyjnego, więc pracowity napastnik nie może wymieniać rekordów.

Uścisk dłoni

handshake to protokół, który jest odtwarzany w ramach protokołu nagrywania. Jego celem jest ustalenie algorytmów i kluczy, które mają być używane do zapisów. Składa się z wiadomości . Każdy komunikat uzgadniania rozpoczyna się czterobajtowym nagłówkiem, jednym bajtem opisującym typ komunikatu, a następnie trzema bajtami określającymi długość komunikatu (konwencja big-endian). Kolejne komunikaty handshake są następnie wysyłane z rekordami oznaczonymi typem „handshake” (pierwszy bajt nagłówka każdego rekordu ma wartość 22).

Zwróć uwagę na warstwy: komunikaty handshake, zakończone czterema bajtowe nagłówki, są następnie wysyłane jako rekordy, a każdy rekord także ma swój własny nagłówek. Ponadto w ramach tego samego rekordu można wysłać kilka komunikatów handshake, a dana wiadomość handshake może zostać podzielona na kilka rekordów.Z punktu widzenia modułu budującego komunikaty handshake, „rekordy” są po prostu strumieniem, w którym można przesyłać bajty; nie jest świadomy faktycznego podziału tego strumienia na rekordy.

Pełne uzgadnianie

Początkowo klient i serwer „zgadzają się” na szyfrowanie zerowe bez kompresji MAC i zerowej. Oznacza to, że rekord, który wyślą jako pierwszy, zostanie wysłany jako zwykły tekst i nie będzie chroniony.

Pierwsza wiadomość uzgadniania to ClientHello. Jest to wiadomość, w której klient deklaruje zamiar wykonania SSL. Zauważ, że „klient” to symboliczna rola; to znaczy „strona, która mówi pierwsza”. Tak się składa, że w kontekście HTTPS, którym jest HTTP-w-SSL-w-TCP, wszystkie trzy warstwy mają pojęcia „klient” i „serwer” i wszystkie się zgadzają (klient TCP jest również klientem SSL i klient HTTP), ale to swego rodzaju zbieg okoliczności.

Wiadomość ClientHello zawiera:

• maksymalny protokół wersja, którą klient chce obsługiwać;
• „losowy klient” (32 bajty, z których 28 ma być wygenerowanych za pomocą silnego kryptograficznie generatora liczb);
• identyfikator sesji „(w przypadku, gdy klient chce wznowić sesję w skróconym uzgadnianiu, patrz poniżej);
• lista” zestawów szyfrów „, o których wie klient, uporządkowana według preferencji klienta;
• lista algorytmów kompresji, które zna klient, uporządkowana według preferencji klienta;
• kilka opcjonalnych rozszerzeń.

A zestaw szyfrów to 16-bitowy symboliczny identyfikator zestawu elementów kryptograficznych c algorytmy. Na przykład zestaw szyfrów TLS_RSA_WITH_AES_128_CBC_SHA ma wartość 0x002F i oznacza, że „rekordy używają szyfrowania HMAC / SHA-1 i AES z 128-bitowym kluczem, a wymiana kluczy odbywa się poprzez szyfrowanie losowy klucz z „publicznym kluczem RSA” serwera.

Serwer odpowiada na ClientHello ServerHello który zawiera:

• wersję protokołu, którego będą używać klient i serwer;
• „serwer losowy” (32 bajty, z 28 losowe bajty);
• identyfikator sesji dla tego połączenia;
• zestaw szyfrów, który będzie używany;
• algorytm kompresji, który będzie używany;
• opcjonalnie, niektóre rozszerzenia.

Pełny uścisk dłoni wygląda następująco:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Ten schemat został bezwstydnie skopiowany z RFC.)

Widzimy ClientHello i ServerHello. Następnie serwer wysyła kilka innych wiadomości, które zależą od zestawu szyfrów i kilku innych parametrów rs:

• Certyfikat: certyfikat serwera, który zawiera jego klucz publiczny. Więcej na ten temat poniżej. Ta wiadomość jest prawie zawsze wysyłana, chyba że zestaw szyfrów wymaga uzgadniania bez certyfikatu.
• ServerKeyExchange: kilka dodatkowych wartości do wymiany kluczy, jeśli to, co jest w certyfikacie, nie jest wystarczające. W szczególności zestawy szyfrów „DHE” używają efemerycznej wymiany kluczy Diffie-Hellman , która wymaga tej wiadomości.
• CertificateRequest: wiadomość z żądaniem, aby klient również zidentyfikował się za pomocą własnego certyfikatu. Ta wiadomość zawiera listę nazw kotwic zaufania (tzw. „Certyfikatów głównych”), których serwer użyje do weryfikacji certyfikatu klienta.
• ServerHelloDone: komunikat znacznika (o długości zero), który mówi, że serwer jest skończony, a klient powinien teraz rozmawiać.

Klient musi wtedy odpowiedzieć z:

• Certyfikat: certyfikat klienta, jeśli serwer zażądał jednego. Istnieją drobne różnice między wersjami (w przypadku SSLv3 klient musi pominąć tę wiadomość, jeśli nie ma certyfikatu; w przypadku protokołu TLS 1.0+ w tej samej sytuacji musi wysłać Certificate wiadomość z pustą listą certyfikatów).
• ClientKeyExchange: część klienta rzeczywistej wymiany kluczy (np. jakaś losowa wartość zaszyfrowana kluczem RSA serwera).
• CertificateVerify: a podpis cyfrowy obliczany przez klienta na podstawie wszystkich poprzednich komunikatów uzgadniania. Ta wiadomość jest wysyłana, gdy serwer zażądał certyfikatu klienta, a klient zastosował się. W ten sposób klient udowadnia serwerowi, że naprawdę „jest właścicielem” klucza publicznego zakodowanego w przesłanym certyfikacie.

Następnie klient wysyła ChangeCipherSpec , który nie jest komunikatem uzgadniania: ma swój własny typ rekordu, więc zostanie wysłany jako własny rekord.Jego zawartość jest czysto symboliczna (pojedynczy bajt wartości 1). Ten komunikat oznacza punkt, w którym klient przełącza się na nowo wynegocjowany zestaw szyfrów i klucze. Kolejne rekordy z klienta zostaną następnie zaszyfrowane.

Wiadomość Finished jest obliczoną kryptograficzną sumą kontrolną nad wszystkimi poprzednimi komunikatami uzgadniania (zarówno z klienta, jak i serwera). Ponieważ jest emitowany po ChangeCipherSpec, jest również objęty kontrolą integralności i szyfrowaniem. Kiedy serwer odbiera tę wiadomość i weryfikuje jej zawartość, uzyskuje dowód, że rzeczywiście przez cały czas rozmawiał z tym samym klientem. Ta wiadomość chroni uzgadnianie przed zmianami (atakujący nie może modyfikować wiadomości uzgadniania i nadal poprawnie odbiera wiadomość Finished).

Serwer w końcu odpowiada własnym ChangeCipherSpec, a następnie Finished. W tym momencie uzgadnianie jest zakończone, a klient i serwer mogą wymieniać dane aplikacji (w zaszyfrowanych rekordach oznaczonych jako takie).

Do zapamiętania: klient sugeruje , ale serwer wybiera . Zestaw szyfrów jest w rękach serwera. Grzeczne serwery mają podążać za preferencjami klienta (jeśli to możliwe), ale mogą zrobić inaczej, a niektóre faktycznie (np. W ramach ochrony przed BEAST).

Skrócony uścisk dłoni

W pełnym uzgadnianiu serwer wysyła do klienta „identyfikator sesji” (tj. Wiązkę do 32 bajtów). Później klient może wrócić i wysłać ten sam identyfikator sesji jako część swojego ClientHello. Oznacza to, że klient nadal pamięta zestaw szyfrów i klucze z poprzedniego uzgadniania i chciałby ponownie użyć tych parametrów. Jeśli serwer również pamięta zestaw szyfrów i klucze, kopiuje ten konkretny identyfikator sesji do swojego ServerHello, a następnie postępuje zgodnie z skrócony uścisk dłoni :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Skrócony uzgadnianie jest krótszy: mniej wiadomości, nie asymetryczny biznes kryptograficzny i, co najważniejsze, zmniejszone opóźnienie . Przeglądarki internetowe i serwery robią to bardzo często. Typowa przeglądarka internetowa otwiera połączenie SSL z pełnym uzgadnianiem, a następnie wykonuje skrócone uzgadnianie dla wszystkich innych połączeń z tym samym serwerem: inne połączenia, które otwiera równolegle, a także kolejne połączenia z tym samym serwerem. Rzeczywiście, typowe serwery internetowe zamykają połączenia po 15 sekundach bezczynności, ale będą pamiętać sesje (zestaw szyfrów i klucze) o wiele dłużej (prawdopodobnie przez godziny lub nawet dni).

Wymiana kluczy

Istnieje kilka algorytmów wymiany kluczy, których może używać SSL. Jest to określone przez zestaw szyfrów; każdy algorytm wymiany kluczy działa z niektórymi rodzajami kluczy publicznych serwera. Najpopularniejsze algorytmy wymiany kluczy to:

• RSA: klucz serwera jest typu RSA. Klient generuje losową wartość („ pre-master secret ”o długości 48 bajtów, z których 46 jest losowych) i szyfruje je kluczem publicznym serwera. Nie ma ServerKeyExchange.
• DHE_RSA: klucz serwera jest typu RSA, ale używany tylko do sygnatura. Rzeczywista wymiana kluczy wykorzystuje Diffie-Hellman. Serwer wysyła wiadomość ServerKeyExchange zawierającą parametry DH (moduł, generator) i nowo wygenerowany klucz publiczny DH; ponadto serwer podpisuje tę wiadomość. Klient odpowie ClientKeyExchange wiadomością, która zawiera również nowo wygenerowany klucz publiczny DH. DH zwraca „pre-główny sekret „.
• DHE_DSS: jak DHE_RSA, ale serwer ma klucz DSS (znany jest też„ DSS ” jako „DSA” ). DSS to algorytm oparty wyłącznie na sygnaturach.

Rzadziej używane algorytmy wymiany kluczy obejmują:

• DH: klucz serwera jest typu Diffie-Hellman (mówimy o certyfikacie , który zawiera Klawisz DH). To było kiedyś „popularne” w sposób administracyjny (rząd federalny Stanów Zjednoczonych nakazał jego stosowanie), kiedy patent RSA był nadal aktywny (było to w poprzednim stuleciu). Pomimo biurokratycznych nacisków nigdy nie był on tak szeroko stosowany jak RSA.
• DH_anon: podobnie jak pakiety DHE, ale bez podpisu z serwera. To jest zestaw szyfrów bez certyfikatu. Z założenia jest podatny na ataki typu Man-in-the-Middle , więc bardzo rzadko jest w ogóle uruchamiany.
• PSK: klucz współdzielony mechanizmy szyfrowania. Symetryczna wymiana kluczy w oparciu o wcześniej ustalony wspólny sekret.
• SRP: zastosowanie protokołu SRP , który jest Password Authenticated Key Exchange . Klient i serwer uwierzytelniają się nawzajem w odniesieniu do wspólnego hasła, które może być hasłem o niskiej entropii (podczas gdy PSK wymaga wspólnego hasła o wysokiej entropii). Bardzo fajnie. Nie jest jeszcze szeroko obsługiwany.
• Tymczasowy klucz RSA: taki jak DHE, ale z nowo wygenerowaną parą kluczy RSA. Ponieważ generowanie kluczy RSA jest drogie, nie jest to popularna opcja i została określona tylko jako część zestawów szyfrów „eksportowych”, które były zgodne z przepisami eksportowymi USA dotyczącymi kryptografii sprzed 2000 roku (tj. Klucze RSA o maksymalnej długości 512 bitów). Obecnie nikt tego nie robi.
• Warianty algorytmów DH* z krzywymi eliptycznymi . Bardzo modne. Powinno stać się powszechne w przyszłości.

Certyfikaty i uwierzytelnianie

Certyfikaty cyfrowe to naczynia dla kluczy asymetrycznych. Mają na celu rozwiązanie problemu dystrybucji kluczy. Mianowicie, klient chce użyć klucza publicznego serwera. Atakujący będzie próbował zmusić klienta do użycia klucza publicznego atakującego . Dlatego klient musi mieć możliwość upewnienia się, że używa właściwego klucza.

SSL powinien używać X.509 . To jest standard dla certyfikatów. Każdy certyfikat jest podpisany przez urząd certyfikacji . Pomysł polega na tym, że klient z natury zna klucze publiczne kilku urzędów certyfikacji (są to „kotwice zaufania” lub „certyfikaty główne”). Za pomocą tych kluczy klient może zweryfikować podpis obliczony przez CA na certyfikacie wystawionym na serwer. Ten proces można rozszerzyć rekurencyjnie: CA może wystawić certyfikat dla innego CA (tj. podpisać strukturę certyfikatu zawierającą inną nazwę i klucz CA). Łańcuch certyfikatów zaczynający się od głównego urzędu certyfikacji i kończący się certyfikatem serwera, z certyfikatami pośredniego urzędu certyfikacji pomiędzy nimi, każdy certyfikat podpisany w odniesieniu do klucza publicznego zakodowanego w poprzednim certyfikacie, nazywany jest bez wyobraźni a łańcuch certyfikatów .

Zatem klient powinien wykonać następujące czynności:

• Pobrać łańcuch certyfikatów kończący się certyfikatem serwera. Wiadomość Certificate z serwera ma zawierać właśnie taki łańcuch.
• Validate łańcuch, czyli weryfikacja wszystkich podpisy i nazwy oraz różne bity X.509. Ponadto klient powinien sprawdzić stan odwołania wszystkich certyfikatów w łańcuchu, co jest skomplikowane i ciężkie (przeglądarki internetowe teraz robią to mniej więcej, ale jest nowością).
• Sprawdź, czy zamierzona nazwa serwera jest rzeczywiście zapisana w certyfikacie serwera. Ponieważ klient chce nie tylko używać zweryfikowanego klucza publicznego, chce również użyć klucza publicznego określonego serwera . Zobacz RFC 2818 , aby dowiedzieć się, jak to się robi w kontekście HTTPS .

Model certyfikacji z certyfikatami X.509 był często krytykowany, nie z przyczyn technicznych, ale raczej z powodów polityczno-ekonomicznych. Koncentruje on uprawnienia do walidacji w rękach kilku graczy , którzy niekoniecznie mają dobre intencje lub przynajmniej nie zawsze kompetentni . Od czasu do czasu publikowane są propozycje innych systemów (np. Convergence lub

Po długa prezentacja SSL w poprzedniej odpowiedzi , przejdźmy do zabawnych rzeczy, a mianowicie:

Ataki na SSL

Było wiele ataków na SSL, niektóre oparte na błędach implementacji, inne na prawdziwych słabościach protokołu.

Należy pamiętać, że chociaż SSL jest jednym z najczęściej atakowanych protokołów (ponieważ jest bardzo popularny: udana aplikacja SSL wygląda bardzo ładnie w skrócie artykułu badawczego), SSL jest również jednym z najczęściej naprawianych protokołów.Należy go uważać za niezawodny właśnie dlatego, że wszystkie znane sposoby ataku na protokoły transportowe zostały wypróbowane na SSL i tam, gdzie to konieczne, poprawiono SSL.

Przywracanie wersji

We wczesnych dniach SSLv3 SSLv2 był nadal szeroko stosowany, dlatego klienci często wysyłali zgodne z SSLv2 ClientHello wiadomości, które jedynie wskazywały, że SSLv3 również jest obsługiwany; serwer skorzystałby z podpowiedzi i odpowiedział w dialekcie SSLv3 + (szczegóły w załączniku E do RFC 2246 ). Ponieważ protokół SSLv2 miał słabe punkty, w najlepszym interesie atakującego było zorganizowanie, aby klient i serwer, obaj znający SSLv3, mimo wszystko rozmawiali ze sobą przy użyciu protokołu SSLv2. Nazywa się to atakiem wycofywania wersji . Koncepcja formalnie rozciąga się również na późniejsze wersje.

Dodano kluczyki w celu wykrycia prób wycofania. W przypadku wycofywania z powrotem do SSLv2 klient, który zna SSLv3 +, powinien zastosować specjalne wypełnienie dla kroku szyfrowania RSA (SSLv2 obsługuje tylko wymianę kluczy opartą na RSA): w PKCS # 1 , dane, które mają być zaszyfrowane, powinny być wypełnione pewną liczbą losowych bajtów; klient obsługujący SSLv3 powinien następnie ustawić każdy z ostatnich ośmiu bajtów wypełnienia na stałą wartość 0x03. Następnie serwer sprawdza te bajty; jeśli zostanie znalezionych osiem 0x03, najprawdopodobniej zostanie podjęta próba wycofania zmian, a serwer odrzuci próbę (klient obsługujący tylko SSLv2 ma prawdopodobieństwo tylko 255 ^-8 użycia takich bajtów uzupełniających z czystego braku szczęście, więc fałszywe alarmy pojawiają się w znikomym stopniu).

W przypadku wycofywania do starej wersji SSL / TLS, ale nie starszej niż SSLv3, dodano kolejny kludge: w pre-master secret 48 bajtów, które klient szyfruje kluczem RSA serwera, pierwsze dwa bajty nie są losowe, ale powinny odpowiadać „maksymalnej obsługiwanej wersji protokołu”, którą klient zapisał jako pierwszy w swoim ClientHello. Niestety, niektórzy klienci źle to zrozumieli, a ten kludge działa tylko z wymianą kluczy opartą na RSA, więc ochrona przed wycofywaniem jest tam bardzo ograniczona. Na szczęście SSLv3 + ma inną, znacznie silniejszą ochronę przed wycofywanie zmian, co oznacza, że komunikaty uzgadniania są mieszane razem podczas tworzenia wiadomości Finished. Ten pro chroni przed wycofywaniem, chyba że „stara wersja” byłaby na tyle słaba, że atakujący mógłby całkowicie złamać całe szyfrowanie przed zakończeniem samego uzgadniania. Tak się jeszcze nie stało (protokół SSLv3 jest nadal dość niezawodny).

Słabe zestawy szyfrów

Niektóre ze standardowych zestawów szyfrów są celowo w jakiś sposób słabe. Istnieją:

• niektóre zestawy szyfrów bez szyfrowania, tylko sprawdzanie integralności, np. TLS_RSA_WITH_NULL_SHA;
• niektóre zestawy szyfrów z 40-bitowym szyfrowaniem, na przykład TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (zestawy szyfrów zgodne z surowe przepisy eksportowe Stanów Zjednoczonych z ubiegłego wieku – przepisy te zostały w większości zniesione pod koniec ery Billa Clintona);
• niektóre zestawy szyfrów z szyfrowaniem 56-bitowym, takie jak TLS_RSA_WITH_DES_CBC_SHA. 56-bitowy DES można złamać za pomocą istniejącej technologii , ale jest to nadal trochę trudne dla amatora (nawet znudzonego studenta z dostępem do kilkuset maszyn uniwersyteckich ), więc zazwyczaj kwalifikuję 56-bitowy DES jako „średnią siłę”.

Otwiera to drogę do wariantu ataków typu rollback, w których atakujący zmusza klienta i serwer do uzgodnienia na słabym zestawie szyfrów, chodzi o to, że atakujący modyfikuje listę zestawów szyfrów ogłoszonych przez klienta. Jest to wykonalne dla atakującego, jeśli wybrany zestaw szyfrów jest tak słaby, że może go złamać, aby ponownie obliczyć pozornie poprawne Finished wiadomość. Właściwie adres MAC używany w SSLv3 + (nawet jeśli jest oparty na MD5) jest wystarczająco mocny, aby temu zapobiec. Więc nie martw się tutaj. Poza tym moim zdaniem każda prawdziwa słabość tutaj to sytuacja, gdy klient lub serwer w ogóle zgadza się na użycie słabego zestawu szyfrów.

Domyślnie nowoczesne przeglądarki internetowe nie pozwalają na użycie takich słabych mechanizmów szyfrowania.

Kradzież klucza prywatnego

Jeśli połączenie SSL wykorzystuje wymianę kluczy RSA, a atakujący przechowuje kopię zapisów, a następnie później (prawdopodobnie miesiące później, być może przez sprawdzenie wszystkich kopii zapasowych na odrzuconych dyskach twardych lub taśmach) uzyskuje kopię klucza prywatnego, a następnie może rozwikłać uścisk dłoni i odszyfrowanie danych.

Doskonałe utajnienie przekazywania dotyczy przeciwdziałania temu „później”. Otrzymujesz to za pomocą zestawów szyfrujących DHE. W przypadku zestawu szyfrów DHE rzeczywistym kluczem prywatnym, który może zostać użyty do rozwikłania uzgodnienia, jest efemeryczny klucz Diffie-Hellmana, a nie klucz prywatny RSA (lub DSS) serwera.Będąc efemerycznym, istniał tylko w pamięci RAM i nigdy nie był zapisywany na dysku twardym; jako taki powinien być znacznie bardziej odporny na ukrytą kradzież.

Więc lekcja jest taka: z reguły spróbuj użyć zestawu szyfrów DHE, jeśli to możliwe. Nadal powinieneś uważać na swoje kopie zapasowe i nie dopuścić do wycieku klucza prywatnego, ale przynajmniej pakiety DHE sprawiają, że taki wyciek jest nieco mniejszy, szczególnie jeśli dzieje się to po zakończeniu okresu życia klucza (tj. Odpowiedni certyfikat nie jest dłużej ważne).

Brak certyfikatu

Cała firma certyfikująca to bolesne miejsce w SSL.

Technicznie SSL jest całkiem niezależny od X.509. Łańcuchy certyfikatów są wymieniane jako nieprzezroczyste obiekty blob. W pewnym momencie klient musi użyć klucza publicznego serwera, ale może „poznać” ten klucz w dowolny sposób, jaki uzna za stosowny. W niektórych scenariuszach, w których można używać protokołu SSL, klient zna już serwer klucz publiczny (zakodowany na stałe w kodzie) i po prostu ignoruje certyfikat wysłany przez serwer. Niemniej jednak w typowym przypadku HTTPS klient przeprowadza weryfikację łańcucha certyfikatów serwera zgodnie z opisem w X.509 ( przeczytaj go kosztem zdrowia psychicznego; zostałeś ostrzeżony).

Daje to szereg wektorów ataku, na przykład:

• Walidacja oznacza sprawdzenie, że certyfikaty są nadal ważne w bieżącej dacie. W jaki sposób komputer kliencki zna aktualną datę? Za pomocą wewnętrznego zegara i być może rozmawiając z serwerami NTP (w dość niezabezpieczony sposób!). Klient może być wyłączony o kilka minut, godzin, dni, a nawet lat (widziałem to), a do pewnego stopnia potężny napastnik mógłby go wymusić, manipulując wiadomościami NTP. Pozwoliłoby to atakujący używa przestarzałych certyfikatów, które zostały unieważnione lata temu. Zwróć uwagę na zabawny fakt: „losowy klient” SSL i „losowy serwer” powinny zawierać 28 losowych bajtów oraz lokalną datę i godzinę (ponad 4 bajtów) .To włączenie czasu miała być częścią obejścia ataków czasowych. Nie znam żadnej implementacji, która naprawdę to sprawdza.

• Do około 2003 roku implementacja sprawdzania poprawności certyfikatu w przeglądarce Internet Explorer / Windows nie przetwarzała rozszerzenia „Basic Constraints” prawidłowo. Efektem netto było to, że każdy z certyfikatem 100 € mógł działać jako CA i wystawiać „certyfikaty” z dowolnie wybraną nazwą i kluczami.

• X .509 zawiera funkcję ograniczania szkód o nazwie odwołanie : chodzi o publikowanie listy wyrzuconych certyfikatów, które wyglądają dobrze, mówiąc kryptograficznie, ale nie powinny być zaufane (np. Ich klucz prywatny został skradziony lub zawierają błędna nazwa). Odwołanie działa tylko wtedy, gdy zaangażowane strony (tj. Przeglądarki) zgadzają się na pobranie gigantycznych list odwołań (które mogą mieć kilka megabajtów!) Lub kontakt z serwerami OCSP . Nowoczesne przeglądarki teraz to robią, ale trochę niechętnie, a wiele z nich i tak zgodzi się na połączenie, jeśli nie będą w stanie uzyskać informacji o statusie odwołania w odpowiednim czasie (ponieważ użytkownik nie jest cierpliwy). Ogólna sytuacja poprawia się z biegiem lat, ale dość powoli.

• Niektóre główne CA popełniły w przeszłości kilka błędów (np. Comodo i DigiNotar). Spowodowało to wystawienie fałszywych certyfikatów (nazwa to www.microsoft.com, ale klucza prywatnego w ogóle nie ma w rękach firmy Microsoft …). Te błędy zostały odkryte, a certyfikaty unieważniono, ale nadal rodzi to niewygodne pytania (np. Czy są inne CA, które miały takie problemy, ale ich nie ujawniły lub, co gorsza, nigdy ich nie zauważyły?).

X.509 to bardzo złożony zestaw algorytmów, technologii, specyfikacji i komitetów, i bardzo trudno jest go uzyskać dobrze. Próba zdekodowania certyfikatów X.509 „ręcznie” w niezabezpieczonym języku programowania, takim jak C, jest łatwym sposobem na uzyskanie przepełnienia bufora.

Bleichenbacher Attacks

Daniel Bleichenbacher znalazł w 1998 r. niezły atak na RSA. Podczas szyfrowania fragmentu danych za pomocą RSA (jak ma to miejsce w przypadku wiadomości ClientKeyExchange w SSL), dane, które mają być zaszyfrowane, muszą być uzupełnione w celu utworzyć sekwencję bajtów o takiej samej długości jak moduł RSA. Wypełnienie składa się głównie z losowych bajtów, ale jest trochę struktury (zwłaszcza, że pierwsze dwa bajty po wypełnieniu muszą mieć wartość 0x00 0x02).

Po odszyfrowaniu (więc na serwerze) wypełnienie musi zostać znalezione i usunięte. Zdarza się, że w tym czasie, gdy serwer odszyfrował, ale uzyskał niepoprawne wypełnienie (nie było tam bajtów 0x00 0x02), to zgłosił to komunikatem ostrzegawczym (zgodnie ze specyfikacją SSL), natomiast prawidłowe wypełnienie skutkowało serwer używa pozornie odszyfrowanej wartości i kontynuuje uzgadnianie.

Tego rodzaju rzeczy są znane jako wyrocznie wypełniające . Pozwala atakującemu na wysłanie dowolnej sekwencji bajtów, tak jakby to był zaszyfrowany klucz wstępny, i wiedzieć, czy odszyfrowanie tej sekwencji zapewni prawidłowe wypełnienie, czy nie. To tylko 1-bitowa informacja, ale wystarczy odzyskać klucz prywatny za pomocą kilku milionów żądań (z sprytnie spreparowanymi, „zaszyfrowanymi” ciągami).

Obejście: gdy odszyfrowanie skutkuje nieprawidłowym wypełnienie, serwer nadal używa losowego klucza wstępnego. Uzgadnianie zakończy się później niepowodzeniem, z wiadomościami Finished. Robią to wszystkie obecne implementacje SSL.

Wyrocznia dopełniająca kontratakuje

Innym obszarem, w którym znaleziono wyrocznię wypełniającą, jest samych rekordów. Weź pod uwagę szyfrowanie CBC i HMAC. Dane do zaszyfrowania są najpierw MAC, a następnie wynik jest szyfrowany. W przypadku szyfrowania CBC dane do zaszyfrowania muszą mieć długość będącą wielokrotnością rozmiaru bloku (8 bajtów dla 3DES, 16 bajtów dla AES). Stosowane jest więc pewne wypełnienie z pewną strukturą.

W tamtym czasie (atak został wykryty przez Vaudenay w 2002 r.), Kiedy implementacja SSL przetwarzała d, zwrócił odrębne komunikaty ostrzegawcze dla tych dwóch warunków:

• Po odszyfrowaniu nie znaleziono prawidłowej struktury wypełnienia.
• Podczas odszyfrowania, znaleziono prawidłowe wypełnienie, ale adres MAC został zweryfikowany i nie pasuje.

Jest to wyrocznia wypełniająca, której można użyć do odzyskania niektórych zaszyfrowanych danych. Wymaga aktywnego napastnika, ale nie jest to takie trudne. Vaudenay zaimplementował go i został rozszerzony na przypadek, w którym zmodyfikowana implementacja SSL zwróciła ten sam komunikat ostrzegawczy w obu przypadkach, ale powrót w drugim przypadku zajął więcej czasu, ze względu na czas potrzebny na ponowne obliczenie MAC (niezła demonstracja a atak czasowy ).

Ponieważ ludzie nigdy się nie uczą, implementacja SSL używanego w ASP.NET przez firmę Microsoft była wciąż niezałatane w 2010 (osiem lat później!), kiedy Rizzo i Duong ponownie zaimplementowali atak Vaudenay i stworzyli demonstrację, która odzyskała pliki cookie HTTP.

Zobacz ta strona , aby uzyskać wskazówki. Należy zauważyć, że gdyby SSL używał encrypt-then-MAC , można by uniknąć takich problemów (błędne rekordy byłyby odrzucane na poziomie MAC, zanim nawet biorąc pod uwagę odszyfrowanie).

BEAST

Atak BEAST ponownie Duong i Rizzo, i znowu jest to remake starszego ataku (autorstwa Philipa Rogawaya z 2002 roku). Aby zrozumieć pomysł, rozważ CBC . W tym trybie pracy każdy blok danych jest najpierw XORowany z wynikiem zaszyfrowania poprzedniego bloku; i to jest wynik XOR, który jest zaszyfrowany. Jest to zrobione w celu „randomizacji” bloków i uniknięcia przecieków, które można znaleźć w trybie ECB. Ponieważ pierwszy blok nie ma „poprzedni” blok, musi istnieć Wektor inicjalizacyjny (IV), który pełni rolę poprzedniego bloku dla pierwszego bloku.

Okazuje się, że jeśli napastnik może kontrolować część danych, które mają być zaszyfrowane, a także może przewidzieć IV, który zostanie użyty, to może przekształcić maszynę szyfrującą w kolejny deszyfrator oracle i użyć go do odzyskania innych zaszyfrowanych danych (których atakujący nie wybiera). Jednak w SSLv3 i TLS 1.0 atakujący może przewidzieć IV dla rekordu: jest to ostatni blok poprzedni rekord! Więc atakujący musi być w stanie wysłać pewne dane w strumieniu, aby „wypchnąć” dane celu, w punkcie, w którym implementacja zbudowała i wysłała poprzedni rekord (zazwyczaj gdy wartość 16 kB danych), ale nie zaczął budować następnego.

TLS 1.1+ jest przed tym chroniony, ponieważ w TLS 1.1 (i kolejnych wersjach) używany jest losowy IV dla każdego rekordu. W przypadku SSLv3 i TLS 1.0 obejściem jest wysyłanie rekordów o zerowej długości: to znaczy rekordów z ładunkiem o długości zero – ale z adresem MAC, dopełnieniem i szyfrowaniem, a adres MAC jest obliczany z tajnego klucza i według sekwencji liczba, więc odgrywa rolę generatora liczb losowych. Niestety IE 6.0 dławi się na rekordach o zerowej długości. Inne strategie obejmują podział 1 / n-1 (rekord n bajtów jest wysyłany jako dwa rekordy, jeden z pojedynczym bajtem danych, drugi z pozostałymi n-1 ).

Innym obejściem jest wymuszenie użycia zestawu szyfrów innego niż CBC, jeśli to możliwe – serwer wybiera zestaw szyfrów oparty na RC4, jeśli taki istnieje na liście zestawów szyfrów wysłanych przez klienta, nawet jeśli wolałby zestaw szyfrów oparty na CBC. To narzędzie może ci powiedzieć, czy dany serwer działa w ten sposób.(Uwaga: BEAST to atak na klienta , ale wybierając zestaw szyfrów RC4, serwer może chronić nieostrożnego klienta.)

Patrz ta strona dla kilku wskazówek. Chociaż TLS 1.1 pochodzi z 2006 roku, atak BEAST może zmusić dostawców przeglądarek do ostatecznej aktualizacji.

CRIME

Jak w przypadku każdej hollywoodzkiej serii, Duong i Rizzo opublikowali w 2012 roku kontynuację kontynuacji. CRIME wykorzystuje wyciek, o którym teoretyzowano wiele lat temu, ale został on wyraźnie pokazany w niedawno opublikowanej demonstracji. CRIME wykorzystuje kompresję w tej samej konfiguracji, co atak BEAST (atakujący może wysłać własne dane w połączeniu SSL, do którego wysyłane są również interesujące dane docelowe, takie jak plik cookie). Z grubsza rzecz biorąc, atakujący umieszcza w swoich danych potencjalną wartość ciągu docelowego, a jeśli pasuje, kompresja sprawia, że rekordy wynikowe są krótsze. Zobacz to pytanie , aby zapoznać się z analizą (przedpoznawczą).

Przestępczości można uniknąć, nie używając w ogóle kompresji na poziomie TLS, co jest co teraz robią przeglądarki. Internet Explorer i IIS nigdy nie zaimplementowały kompresji na poziomie TLS (choć raz niechlujstwo uratowało dzień); Firefox i Chrome zaimplementowały to i dezaktywowały tego lata (ostrzeżono ich Duong i Rizzo, którzy są dość odpowiedzialni za ich działania).

CRIME pokazuje, dlaczego napisałem, na początku mojego Wyjaśnienia dotyczące SSL :

SSL spełnia te cele w dużym (ale nie absolutnym) stopniu.

Rzeczywiście, szyfrowanie przecieka długość zaszyfrowanych danych. Nie ma znanego dobrego rozwiązania. Sama długość może ujawnić wiele rzeczy. Na przykład, obserwując za pomocą monitora sieci połączenie SSL, możemy zauważyć „dodatkowe uściski dłoni” w strumieniu (ponieważ pierwszy bajt każdego rekordu określa typ danych w rekordzie i nie jest on szyfrowany); dzięki długościom rekordów łatwo jest sprawdzić, czy klient dostarczył certyfikat, czy nie.

Pudel

( edit: ta sekcja została dodana 15.10.2014)

Atak „Pudel” wykorzystuje lukę charakterystyczną dla SSL 3.0 z zestawami szyfrów opartymi na CBC. Opiera się na często pomijanej funkcji SSL 3.0: większość bajtów uzupełniających jest ignorowana. W TLS 1.0 dopełnienie (bajty dodane do rekordu, aby długość była zgodna z szyfrowaniem CBC, które przetwarza tylko pełne bloki) jest w pełni określone; wszystkie bajty muszą mieć określoną wartość, a odbiorca to sprawdza. W SSL 3.0 zawartość bajtów uzupełniających jest ignorowana, co pozwala atakującemu na wprowadzenie zmian, które pozostają niezauważone. Zmiana dotyczy tylko danych nie mających zastosowania, ale może być używana jako wyrocznia deszyfrująca w sposób nieco podobny do BEAST.

Więcej szczegółów można przeczytać w tym odpowiedź .

Przyszłość

Ludzie nigdy się nie uczą. Istnieje duża presja, aby dodać sprytne rozszerzenia do SSL z wielu powodów, które zawsze wyglądają dobrze na początku, ale mogą powodować dodatkowe problemy.

Weźmy na przykład pod uwagę SSL FalseStart . Głównie chodzi o wysyłanie przez klienta danych aplikacji zaraz po wysłaniu wiadomości Finished (w pełnym uścisku dłoni), bez czekania na Finished wiadomość z serwera. Zmniejsza to opóźnienie, co jest dobre i oparte na dobrych intencjach. Jednak zmienia to sytuację bezpieczeństwa: zanim otrzyma wiadomość Finished z serwera, ta ostatnia jest uwierzytelniana tylko niejawnie (klient nie ma jeszcze dowodu, że zamierzony serwer był naprawdę zaangażowany w wszystko; po prostu wie, że cokolwiek wyśle, będzie możliwe do odczytania tylko przez właściwy serwer). Może to mieć wpływ; na przykład osoba atakująca może emulować serwer do tego momentu i wymusić np. na kliencie użycie zestawu szyfrów opartego na CBC lub kompresji TLS. Dlatego jeśli klient implementuje FalseStart, zmniejsza to skuteczność środków ochrony przed BEAST i CRIME, które w innym przypadku mogłyby być egzekwowane przez serwer.

(Google wyłączony FalseStart tej wiosny, najwyraźniej z powodu problemów ze zgodnością z niektórymi serwerami. W każdym razie „30% redukcja opóźnienia” wyglądała dziwnie, ponieważ FalseStart miałby pewien wpływ tylko na pełne uściski dłoni, a nie na skrócone, więc nie robię tego ” nie wierzę w te rzekome korzyści, a przynajmniej nie do takiej wielkości.)

Komentarze

• Ilość wysiłku włożona w dostarczenie dobrych informacji ta strona jest naprawdę szalona i niesamowicie godna podziwu. Bardzo ceniona.
• Zobacz także tools.ietf.org / html / rfc7457