TLS 1.3: 0-RTT, wczesne dane i wznawianie sesji

TLS 1.3 (RFC 8446, 2018) przeprojektował uzgadnianie TLS, aby zmniejszyć opóźnienia i usunąć przestarzałe elementy. Pełne uzgadnianie TLS 1.3 kończy się w 1-RTT: klient wysyła ClientHello z obsługiwanymi key_shares (efemerycznymi kluczami publicznymi ECDH) już w pierwszej wiadomości; serwer odpowiada komunikatami ServerHello, własnym key_share, zaszyfrowanymi rozszerzeniami, certyfikatem i Finished — wszystko w jednej odpowiedzi. Klient wysyła Finished i może natychmiast rozpocząć przesyłanie danych aplikacyjnych. W porównaniu z uzgadnianiem TLS 1.2 trwającym 2-RTT skraca to o połowę czas nawiązywania nowych połączeń.

TLS 1.3 używa HKDF (funkcji wyprowadzania klucza opartej na HMAC) oraz uporządkowanego schematu wyprowadzania kluczy. Po wymianie kluczy ECDHE współdzielony sekret zasila hierarchię: Extract(early_secret, DHE) -> handshake_secret, a następnie Extract(handshake_secret, 0) -> master_secret. Na ich podstawie HKDF-Expand-Label wyprowadza oddzielne klucze dla ruchu uzgadniania klienta i serwera, ruchu aplikacyjnego oraz wznowienia sesji. Wyraźne rozdzielenie gwarantuje, że przejęcie kluczy z jednego poziomu nie wpłynie na pozostałe — to istotne ulepszenie w porównaniu z bardziej doraźnym wyprowadzaniem kluczy opartym na PRF w TLS 1.2.

Wznowienie sesji TLS 1.3 wykorzystuje klucze wstępnie współdzielone (PSK) wyprowadzone z poprzednich sesji. Po zakończeniu uzgadniania serwer wysyła komunikat NewSessionTicket zawierający tożsamość PSK oraz wartość biletu (zaszyfrowany obiekt przechowujący sekret wznowienia). Przy ponownym połączeniu klient umieszcza tożsamość PSK w ClientHello. Jeśli serwer ją rozpozna, obie strony wyprowadzają nowy klucz sesji z PSK oraz świeżego ECDHE, uzyskując wznowienie w 1-RTT z zachowaniem utajnienia przekazywania. Bilet ma konfigurowalny czas życia (zwykle 24 godziny) i powinien być szyfrowany rotowanym kluczem po stronie serwera.

TLS 1.3 umożliwia przesyłanie wczesnych danych 0-RTT we wznawianych sesjach. Klient używa PSK z poprzedniej sesji do zaszyfrowania danych aplikacyjnych wysyłanych w pierwszej wiadomości — zanim serwer wyśle jakiekolwiek potwierdzenie. Eliminuje to jedno okrążenie dla połączeń z wcześniej odwiedzanymi serwerami, zapewniając niemal zerowe opóźnienie przy ponownych połączeniach. Serwer ogłasza obsługę 0-RTT w NewSessionTicket za pomocą rozszerzenia early_data z wartością max_early_data_size. Serwer musi dysponować mechanizmem akceptowania lub odrzucania danych 0-RTT i sygnalizuje ich akceptację w EncryptedExtensions.

Dane 0-RTT mają fundamentalne ograniczenie bezpieczeństwa: są podatne na ataki powtórzeniowe. Atakujący znajdujący się na ścieżce komunikacji, który przechwyci pierwszą wiadomość, może przesłać ją ponownie do serwera, powodując ponowne przetworzenie przez serwer tych samych wczesnych danych. Jest to nieuniknione — serwer nie wysłał jeszcze żadnej wiadomości, więc nie wprowadził własnej świeżości. Możliwe mechanizmy ograniczające ryzyko: (1) Bilety jednorazowego użytku (serwer unieważnia bilet po pierwszym użyciu, korzystając z rozproszonej pamięci podręcznej, takiej jak memcached/Redis). (2) Bilety ograniczone czasowo (odrzucanie 0-RTT po krótkim czasie, np. 5 sekundach). (3) Idempotencja na poziomie aplikacji (zezwalanie na 0-RTT wyłącznie dla bezpiecznych operacji równoważnych żądaniom GET).

Najbardziej niezawodnym mechanizmem ochrony danych 0-RTT przed powtórzeniami są bilety sesji jednorazowego użytku. Serwer utrzymuje magazyn „wykorzystanych biletów” (w środowiskach wieloserwerowych jest to rozproszona pamięć podręczna). Gdy nadejdą dane 0-RTT, serwer sprawdza, czy dany bilet był już użyty — jeśli tak, odrzuca wczesne dane i przechodzi na 1-RTT. Jeśli nie, oznacza bilet jako wykorzystany i przetwarza wczesne dane. Aby zapewnić poprawność działania, wszystkie serwery w klastrze muszą współdzielić pamięć podręczną wykorzystanych biletów. Redis z krótkimi wartościami TTL, odpowiadającymi czasowi życia biletu, jest częstą implementacją. Bez tego mechanizmu 0-RTT jest niebezpieczne dla operacji nieidempotentnych, takich jak płatności.

Wznowienie sesji TLS 1.3 za pomocą PSK bez DHE nie zapewnia utajnienia przekazywania dla wznowionej sesji — jeśli PSK zostanie później przejęty, cały ruch wznowionych sesji będzie można odszyfrować. Aby zachować utajnienie przekazywania, TLS 1.3 obsługuje PSK-with-DHE: ClientHello zawiera zarówno tożsamość PSK, jak i nowy key_share. Serwer łączy PSK z wynikiem ECDHE, aby wyprowadzić klucze sesji. Nawet jeśli PSK zostanie przejęty, udział ECDHE gwarantuje ochronę wcześniejszego ruchu. RFC 8446 zaleca PSK-with-DHE we wszystkich przypadkach wznawiania, w których wymagane jest utajnienie przekazywania.

TLS 1.2 miał ponad 300 kombinacji zestawów szyfrów, z których wiele było niebezpiecznych. TLS 1.3 ogranicza tę liczbę do 5 zestawów szyfrów, z których wszystkie wykorzystują AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 oraz TLS_AES_128_CCM_8_SHA256. Wymiana kluczy i uwierzytelnianie są uzgadniane oddzielnie za pomocą rozszerzeń supported_groups i signature_algorithms. Rozdzielenie to eliminuje kombinatoryczną złożoność TLS 1.2 i gwarantuje, że każde połączenie TLS 1.3 korzysta z uwierzytelnionego szyfrowania.

W praktyce 0-RTT jest najbardziej użyteczne w połączeniach HTTP/2, gdy klient ponawia żądanie GET (bezpieczne i idempotentne) do wcześniej odwiedzanego serwera. Przeglądarki ostrożnie wdrażają 0-RTT: Chrome włącza je dla bezpiecznych metod HTTP, a żądania POST nigdy nie są wysyłane jako dane 0-RTT. HTTP/3 działający przez QUIC natywnie integruje TLS 1.3 — 0-RTT w QUIC ponownie wykorzystuje mechanizm TLS 1.3. W QUIC 0-RTT przywraca również parametry transportowe (kontrolę przepływu i limity strumieni) z poprzedniej sesji, dodatkowo zmniejszając narzut konfiguracji, nie tylko na poziomie TLS.

TLS 1.3 zawiera mechanizmy zapobiegające atakom polegającym na obniżeniu wersji. Pole losowe ServerHello zawiera wartość sygnalizacyjną, gdy uzgadniany jest TLS 1.3: ostatnie 8 bajtów przyjmuje stałą wartość (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 w przypadku powrotu awaryjnego do TLS 1.2). Klienci obsługujący TLS 1.3 sprawdzają tę wartość, gdy serwer uzgadnia TLS 1.2, wykrywając aktywne próby obniżenia wersji. Ponadto hasz transkryptu Finished obejmuje całe uzgadnianie, w tym negocjację wersji, dzięki czemu każda ingerencja jest wykrywalna. SCSV (Signaling Cipher Suite Values), takie jak TLS_FALLBACK_SCSV, zapewniają osobny sygnał obniżenia wersji dla starszych wersji TLS.

Wdrożenie TLS 1.3 wymaga uwzględnienia kilku szczegółów operacyjnych. Klucze szyfrujące bilety sesji muszą być rotowane (zwykle co 24 godziny) i synchronizowane w klastrach serwerów, aby umożliwić wznowienie sesji na dowolnym serwerze. Stare klucze deszyfrujące bilety należy zachować przez cały czas życia biletu, aby uniknąć nieuzasadnionych niepowodzeń uzgadniania. OCSP stapling ma większe znaczenie w TLS 1.3, ponieważ pozwala uniknąć jednego dodatkowego okrążenia potrzebnego do sprawdzenia stanu certyfikatu. Load balancery muszą przekazywać ClientHello TLS 1.3 bez modyfikacji — niektóre starsze urządzenia pośredniczące uszkadzają nieznane rozszerzenia, co wymaga użycia trybów zgodności.

Dlaczego wczesne dane 0-RTT są podatne na ataki powtórzeniowe w TLS 1.3?

TLS 1.3 zapewnia pełne uzgadnianie w 1-RTT oraz wznawianie sesji w 0-RTT za pomocą biletów sesji PSK. Wyprowadzanie kluczy wykorzystuje HKDF i uporządkowany schemat, który tworzy oddzielne klucze dla każdej warstwy ruchu. Wczesne dane 0-RTT eliminują jedno okrążenie, ale są podatne na powtórzenia — ryzyko to ograniczają bilety jednorazowego użytku oraz ograniczenie 0-RTT do operacji idempotentnych. PSK-with-DHE zachowuje utajnienie przekazywania przy wznawianiu sesji. TLS 1.3 ogranicza zestawy szyfrów do 5 opcji AEAD, eliminując starsze, niebezpieczne kombinacje. Zapobieganie obniżeniu wersji wykorzystuje wartości sygnalizacyjne w polu losowym serwera.