Historia protokołu TLS – od SSL 1.0 do TLS 1.3

Protokół TLS powstał jako bezpośredni następca wadliwego SSL, a jego historia to ciągła walka z lukami kryptograficznymi. Rozwój od wersji SSL 1.0 z 1994 roku aż do nowoczesnego TLS 1.3 polegał na systematycznym wycinaniu przestarzałych szyfrów i skracaniu czasu nawiązywania połączenia. To jest bez mała najczystsza definicja ewolucji w bezpieczeństwie sieciowym. Mamy tu do czynienia z protokołem, który utrzymuje w tajemnicy ruch w całym internecie.

Prawda jest zresztą absolutnie taka, że zmiana nazwy z SSL na TLS to była czysta polityka między Microsoftem a Netscape u schyłku lat dziewięćdziesiątych. Chociaż prawdę mówiąc brakuje nam twardych logów z tamtych spotkań IETF, więc wydaje się to po prostu najbardziej logiczną hipotezą na podstawie dostępnych notatek z grup roboczych. Zmieniliśmy te zasady na robocie i dzisiaj nikt już nie używa starych wersji. Wdrażanie dzisiaj SSL 3.0 to jest po prostu rynkowe samobójstwo i totalny syf, który prosi się o wyciek danych prosto z serwera. A my musimy z tym żyć i łatać systemy.

Jak w ogóle powstał protokół SSL i dlaczego Netscape musiał go stworzyć?

Netscape zrobił to z przymusu. W 1994 roku internet przesyłał wszystko jawnym tekstem. Wyobraźcie sobie przesyłanie numerów kart kredytowych bez żadnej osłony. Każdy węzeł po drodze widział pakiety. Taher Elgamal i jego zespół w Netscape Communications usiedli do pracy, żeby wymyślić warstwę pośrednią między TCP a HTTP. Tak powstał pomysł na Secure Sockets Layer. Koncepcja opierała się na wykorzystaniu kryptografii asymetrycznej do wymiany kluczy, a następnie przejściu na szybki szyfr symetryczny do kodowania samej transmisji. Działało to w teorii. W praktyce pierwsza implementacja była całkowicie dziurawa.

Zastosowano wtedy algorytmy z rodziny RC4. Szybkie, tanie obliczeniowo, idealne dla ówczesnych procesorów. Problem polegał na braku spójności w mechanizmach uwierzytelniania. Protokół miał chronić przed podsłuchem, ale kompletnie ignorował kwestię modyfikacji danych w locie przez aktywnego napastnika. Brakowało silnego uwierzytelniania wiadomości. Więc projekt upadł zanim wstał z kolan.

Dlaczego wersja SSL 1.0 nigdy nie ujrzała światła dziennego?

Wersja 1.0 nigdy nie opuściła laboratoriów Netscape. Została zniszczona na etapie wewnętrznych audytów bezpieczeństwa. Znaleziono w niej krytyczne błędy projektowe pozwalające na banalny atak typu replay. Atakujący mógł po prostu przechwycić zaszyfrowaną sesję i wysłać ją ponownie do serwera, a serwer posłusznie by ją zaakceptował, wykonując na przykład podwójny przelew bankowy. To dyskwalifikowało kod z użycia komercyjnego.

• Pierwszy problem dotyczył absolutnego braku sekwencjonowania pakietów w sposób kryptograficznie bezpieczny, co sprawiało, że każdy człowiek z dostępem do sniffera sieciowego mógł bez problemu zrzucić ruch na dysk, poczekać na odpowiedni moment, a następnie wstrzyknąć te same zera i jedynki prosto w gniazdo TCP serwera docelowego, wywołując powtórzenie akcji bez znajomości klucza sesyjnego.
• Drugi to słaba kryptografia.

Dlatego od razu przeskoczono do SSL 2.0, wydanego w 1995 roku wraz z przeglądarką Netscape Navigator 1.1. Ale i ta wersja miała wady. Używała tego samego klucza do uwierzytelniania wiadomości i szyfrowania. To łamie podstawowe zasady projektowania systemów kryptograficznych. Microsoft szybko zauważył te luki i wypuścił własny, konkurencyjny standard o nazwie PCT (Private Communication Technology). Rozpoczęła się wojna na standardy. Netscape musiał działać szybko.

W którym momencie SSL 3.0 przestał wystarczać i dlaczego IETF wkroczyło do gry?

SSL 3.0 pojawił się w 1996 roku i całkowicie przepisał architekturę warstwy transportowej. Zaprojektowali go Paul Kocher i Phil Karlton. Wprowadzono oddzielne klucze dla szyfrowania i uwierzytelniania (MAC – Message Authentication Code). Dodano wsparcie dla negocjacji certyfikatów X.509 w łańcuchach zaufania. To zadziałało. Wersja 3.0 stała się standardem de facto dla całego wczesnego e-commerce. Przetrwała na rynku przez kilkanaście lat.

Ale własność intelektualna protokołu należała do jednej firmy. Internet Engineering Task Force (IETF) uznało, że główny protokół bezpieczeństwa w sieci nie może być kontrolowany przez korporację. W 1999 roku powołano grupę roboczą i wydano dokument RFC 2246. Tak narodził się Transport Layer Security w wersji 1.0. Zmiany techniczne w stosunku do SSL 3.0 były minimalne. Zmieniono sposób wyliczania skrótów MAC i zmodyfikowano proces generowania klucza głównego (Master Secret). To był po prostu SSL 3.1 pod nową nazwą. IETF zamknęło temat własności.

Czym właściwie różni się TLS 1.0 od starego SSL?

Różnica leży w detalach matematycznych. TLS 1.0 używa funkcji HMAC (Hash-based Message Authentication Code) zamiast niestandardowego algorytmu MAC z SSL 3.0. Funkcja pseudolosowa (PRF) w TLS 1.0 łączy wyniki z MD5 i SHA-1, co w tamtym czasie dawało odporność na kolizje, gdyby jedna z funkcji skrótu została złamana. W SSL 3.0 proces ten był mniej rygorystyczny. Oprócz tego, TLS 1.0 nie pozwala na powrót do starszych, słabszych wersji protokołu z taką łatwością jak SSL, co miało zapobiegać atakom typu downgrade.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek, analizując stare logi z serwerów Apache. Kiedy klient próbuje negocjować TLS 1.0, a serwer wymaga nowszej wersji, sypią się błędy handshake failure. I bardzo dobrze. TLS 1.0 jest dzisiaj martwy. Został oficjalnie wycofany i zakazany przez standardy takie jak PCI DSS. Zbyt wiele wektorów ataku uderzało w jego implementację CBC (Cipher Block Chaining).

Jakie luki bezpieczeństwa wymusiły przejście na TLS 1.2?

Lata 2011-2014 to prawdziwa rzeźnia starszych protokołów. Atak BEAST (Browser Exploit Against SSL/TLS) w 2011 roku udowodnił, że przewidywalne wektory inicjujące (IV) w trybie CBC pozwalają na deszyfrowanie ciasteczek sesyjnych. Badacze Juliano Rizzo i Thai Duong pokazali to na żywo. Nagle okazało się, że szyfrowanie można złamać w kilka minut. Wymagało to wstrzykiwania kodu JavaScript do przeglądarki ofiary, ale działało bezbłędnie.

Potem przyszedł CRIME. Atak uderzył w mechanizm kompresji TLS. Poprzez dodawanie własnych danych do żądania HTTP i obserwowanie rozmiaru zaszyfrowanego pakietu, napastnik zgadywał zawartość tajnych ciasteczek. Rozwiązanie? Wyłączyć kompresję na poziomie TLS. Po prostu uciąć funkcję w konfiguracji. Serwer wysyła certyfikat. Klient weryfikuje podpis. Koniec.

Ja wam powiem z własnego doświadczenia na produkcji. Siedzisz w serwerowni pod Warszawą, jest druga w nocy, klima wyje jak opętana, a ty musisz ręcznie przepinać load balancery, bo nagle jakiś badacz z Google opublikował exploit na padding w CBC. Wycinasz te przestarzałe cipher suites z konfiguracji Nginx, a rano dzwoni klient z awanturą, że jego stary terminal płatniczy z 2008 roku przestał gadać z API. I weź tu człowieku tłumacz, że to dla jego bezpieczeństwa, bo mu zaraz ruch zeshiffują. Taka jest brutalna prawda o utrzymywaniu systemów. Nie ma litości dla długu technologicznego.

Ataki POODLE i BEAST, czyli jak hakerzy łamali szyfrowanie w locie?

POODLE (Padding Oracle On Downgraded Legacy Encryption) z 2014 roku to był gwóźdź do trumny dla SSL 3.0. Błąd polegał na tym, że SSL 3.0 nie weryfikował zawartości bajtów wypełnienia (padding) przed sprawdzeniem sumy kontrolnej MAC. Atakujący zmuszał przeglądarkę do obniżenia wersji protokołu (downgrade attack) do SSL 3.0, a następnie modyfikował zaszyfrowane bloki. Jeśli serwer odrzucił pakiet z błędem MAC, atakujący wiedział, że zgadł źle. Jeśli serwer odrzucił pakiet z błędem paddingu, atakujący zgadł dobrze jeden bajt jawnopostaciowy. Średnio 256 zapytań wystarczyło na odszyfrowanie jednego bajtu ciasteczka sesyjnego.

Wydanie TLS 1.2 (RFC 5246) w 2008 roku posprzątało ten bałagan. Usunięto na twardo powiązanie z MD5 i SHA-1 w funkcjach pseudolosowych. Wprowadzono wsparcie dla nowoczesnych trybów szyfrowania uwierzytelnionego AEAD (Authenticated Encryption with Associated Data), takich jak AES-GCM (Galois/Counter Mode). AEAD szyfruje i autentykuje dane w jednej operacji matematycznej, co całkowicie eliminuje klasę ataków typu padding oracle. Przejście na TLS 1.2 stało się wymogiem prawnym dla instytucji finansowych.

Co zmienia TLS 1.3 i dlaczego usunięto w nim tyle starych funkcji?

TLS 1.3, zdefiniowany w dokumencie RFC 8446 z 2018 roku, to nie jest kolejna aktualizacja. To całkowite zburzenie starego domu i zbudowanie go od nowa na czystej działce. IETF pracowało nad nim cztery lata i wypuściło aż 28 wersji roboczych (draftów). Główny cel to skrócenie czasu negocjacji połączenia (handshake) oraz bezwzględne wycięcie starych, łatwych do złamania algorytmów kryptograficznych.

Z protokołu wyleciały algorytmy takie jak RC4, DES, 3DES, AES-CBC, MD5, SHA-1 oraz statyczna wymiana kluczy RSA. Dlaczego RSA musiało odejść? Bo nie zapewnia utajniania z wyprzedzeniem (Perfect Forward Secrecy – PFS). W statycznym RSA, jeśli ktoś zapisuje twój zaszyfrowany ruch sieciowy przez pięć lat, a potem kradnie klucz prywatny serwera, może odszyfrować całą historię wstecz. W TLS 1.3 wymiana kluczy opiera się wyłącznie na protokołach efemerycznych: Ephemeral Diffie-Hellman (DHE) i jego wariancie opartym na krzywych eliptycznych (ECDHE). Dla każdej sesji generowany jest nowy, unikalny klucz. Kradzież klucza serwera nic nie daje napastnikowi.

To jest potężna zmiana u podstaw. Wyrzucenie bagażu lat dziewięćdziesiątych pozwoliło na znaczne uproszczenie maszyny stanów protokołu. Mniej kodu oznacza mniejszą powierzchnię ataku. Deweloperzy bibliotek takich jak OpenSSL czy BoringSSL odetchnęli z ulgą.

Jak działa 0-RTT i dlaczego przyspiesza ładowanie stron internetowych?

Skrócenie opóźnień sieciowych to obsesja współczesnego internetu. W starym TLS 1.2, zanim klient mógł wysłać pierwsze żądanie HTTP (np. GET /index.html), musiał wykonać dwa pełne cykle komunikacyjne z serwerem (2-RTT). Klient wysyłał ClientHello, serwer odpowiadał ServerHello i certyfikatem, klient wysyłał klucz sesyjny, serwer potwierdzał gotowość. To trwało cenne milisekundy.

• W TLS 1.3 domyślny handshake zredukowano do 1-RTT. Klient od razu w pierwszym pakiecie wysyła swoje parametry kryptograficzne i udziały klucza Diffie-Hellmana dla najpopularniejszych krzywych (np. X25519). Serwer wybiera krzywą, generuje swój udział, wylicza klucz sesyjny i od razu wysyła zaszyfrowaną odpowiedź.
• Dla powracających klientów wprowadzono tryb Zero Round Trip Time Resumption (0-RTT).
• Klient wysyła żądanie HTTP GET zaszyfrowane za pomocą klucza wyprowadzonego z poprzedniej sesji (tzw. PSK – Pre-Shared Key) w tym samym pakiecie co ClientHello. Zyskujemy natychmiastowe ładowanie danych.
• Jest jeden problem: dane w 0-RTT są podatne na ataki replay. Serwery muszą wdrażać mechanizmy chroniące przed ponownym przetworzeniem tego samego żądania (np. poprzez ścisłe limity czasowe biletów sesyjnych lub zapisywanie użytych identyfikatorów). U nas na wdrożeniach wyłączamy 0-RTT dla endpointów modyfikujących stan bazy danych (POST/PUT). Działa to tylko dla bezpiecznych żądań GET.

Czas nawiązywania połączenia spadł o bez mała prawie pięćdziesiąt procent w stosunku do starych wdrożeń. Szybkość to pieniądz na rynku e-commerce. Każda urwana milisekunda poprawia wskaźniki konwersji koszyka. Aplikacje mobilne działające na słabych łączach 3G lub brzegach sieci LTE zyskały na tym najwięcej. Wgrywasz łatkę na Nginx, restartujesz usługę i nagle wykresy opóźnień lecą w dół. Czysta inżynieria bez zbędnego gadania.

Czy wdrożenie TLS 1.3 na serwerze to dzisiaj absolutny wymóg?

Tak. I nie ma tutaj pola do negocjacji. Najwięksi gracze na rynku wymusili to na administratorach. Przeglądarki Google Chrome, Mozilla Firefox i Apple Safari w 2020 roku oficjalnie usunęły wsparcie dla TLS 1.0 i 1.1. Próba wejścia na serwer skonfigurowany pod stare protokoły kończy się wielkim ostrzeżeniem o błędzie prywatności, którego zwykły użytkownik nie potrafi obejść. Ruch sieciowy spada do zera.

Wymogi prawne i standardy branżowe nie pozostawiają złudzeń. Rada ds. Standardów Bezpieczeństwa Branży Kart Płatniczych (PCI SSC) dawno określiła TLS 1.2 jako absolutne minimum. Ale audytorzy bezpieczeństwa podczas testów penetracyjnych od razu zgłaszają brak TLS 1.3 jako średnie lub niskie ryzyko w raportach. Dostawcy chmurowi tacy jak Cloudflare czy AWS udostępniają TLS 1.3 domyślnie dla każdej nowej podpiętej domeny. Nie musisz nawet wiedzieć jak to działa pod spodem. Po prostu zaznaczasz checkbox w panelu.

My w zespole wycinamy stary kod bez skrupułów. Zostawiamy TLS 1.2 jako fallback dla starych systemów Android lub zapomnianych urządzeń IoT, ale wymuszamy silne szyfry AES-GCM. Starsze implementacje CBC lądują w koszu. To jest bez mała najgorsza opcja z wszystkich. Wdrażasz stary szyfr. Czekasz. I nagle cała baza leży po jednym skrypcie odpalonym przez znudzonego studenta z drugiego końca świata. Administrowanie bezpieczeństwem to nie jest miejsce na sentymenty wobec technologii z ubiegłej dekady.

Pamiętajcie, że weryfikacja certyfikatów i konfiguracja szyfrów to proces. Z narzędziami takimi jak SSL Labs od Qualys każdy może sprawdzić ocenę swojego serwera w piętnaście sekund. Dostajesz ocenę A+ tylko wtedy, gdy poprawnie obsłużysz TLS 1.3, wdrożysz HSTS (HTTP Strict Transport Security) i pozbędziesz się archaicznych wektorów wymiany klucza. Jeśli wasz serwer dostaje ocenę C, to macie poważny problem na produkcji.

Zrób to sam i przetestuj własne serwery. Odpal terminal, wpisz openssl s_client -connect twojadomena.pl:443 -tls1_3 i zobacz, czy połączenie zostanie nawiązane poprawnie. Jeśli nie, masz przed sobą długą noc w konfiguracji Apache lub Nginx. Pokaż logi z udanego handshake’u zespołowi i zamknij temat długu technicznego raz na zawsze.

Bibliografia

1. Internet Engineering Task Force (IETF) – https://www.ietf.org
2. Cloudflare Research – https://research.cloudflare.com
3. Qualys SSL Labs – https://www.ssllabs.com
4. Mozilla Developer Network (MDN) – https://developer.mozilla.org
5. National Institute of Standards and Technology (NIST) – https://www.nist.gov