0Pricing
Security+ Academy · Lekcja

Uzgadnianie TLS 1.3 i wznowienie 0-RTT

Prześledź krok po kroku uzgadnianie TLS 1.3, poznaj sposób, w jaki domyślnie zapewnia forward secrecy, i oceń kompromisy bezpieczeństwa związane ze wznowieniem sesji 0-RTT.

Uzgadnianie TLS 1.3 i wznowienie 0-RTT to bezpłatna lekcja Security+ Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Security+ Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Security+ Academy zawiera 4 lekcji w sumie.

Dlaczego potrzebny był TLS 1.3

TLS 1.3, wydany w 2018 roku (RFC 8446), został zaprojektowany w celu usunięcia słabości narastających w TLS 1.2 przez dekadę rzeczywistych ataków. Wcześniejsze wersje umożliwiały negocjowanie słabych zestawów szyfrów, obsługiwały kryptografię klasy eksportowej i wymagały wielu podróży w obie strony, zanim można było rozpocząć przesyłanie danych. TLS 1.3 usuwa wszystkie przestarzałe algorytmy i upraszcza uzgadnianie połączenia do jednej podróży w obie strony w typowym przypadku, znacznie zwiększając zarówno bezpieczeństwo, jak i wydajność.

Przegląd uzgadniania połączenia: jedna podróż w obie strony

W TLS 1.3 klient i serwer kończą uzgadnianie połączenia w ramach 1-RTT (jednej podróży w obie strony). Klient wysyła komunikat ClientHello zawierający obsługiwane zestawy szyfrów oraz udział klucza (z wykorzystaniem Diffie-Hellmana). Serwer odpowiada komunikatem ServerHello, własnym udziałem klucza, certyfikatem i pierwszym zaszyfrowanym fragmentem danych aplikacji — wszystko w ramach jednej transmisji. Następnie klient weryfikuje certyfikat i wysyła komunikat Finished, po czym strony wymieniają dane aplikacji.

# Trace TLS 1.3 handshake with openssl
openssl s_client -connect example.com:443 -tls1_3 -msg 2>&1 | grep -E 'ClientHello|ServerHello|Finished'

Wymiana kluczy: wyłącznie efemeryczny Diffie-Hellman

TLS 1.3 wymaga efemerycznej wymiany kluczy — całkowicie usunięto z niego wymianę kluczy RSA. Każda wymiana kluczy musi korzystać z ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) lub DHE (Diffie-Hellman Ephemeral). Słowo „efemeryczny” oznacza, że dla każdej sesji generowana jest nowa para kluczy. Stanowi to podstawę doskonałego utajnienia przekazywania (perfect forward secrecy): przejęcie długoterminowego klucza prywatnego serwera nie umożliwia odszyfrowania wcześniejszych sesji, ponieważ każda sesja korzystała z unikatowego klucza tymczasowego.

Wyjaśnienie doskonałego utajnienia przekazywania

Perfect Forward Secrecy (PFS) gwarantuje, że nawet jeśli atakujący zarejestruje dziś cały zaszyfrowany ruch, a w przyszłości zdobędzie klucz prywatny serwera, nadal nie będzie mógł odszyfrować starych sesji. W TLS 1.2 z wymianą kluczy RSA klucz prywatny serwera mógł odszyfrować sekret główny wstępny (pre-master secret) z dowolnej wcześniejszej sesji — byłaby to katastrofalna awaria zabezpieczeń. Efemeryczne klucze DH w TLS 1.3 oznaczają, że każda sesja wyprowadza własne klucze, a klucze efemeryczne są usuwane po użyciu.

Uproszczenie zestawów szyfrów

TLS 1.2 obsługiwał ponad 300 zestawów szyfrów, z których wiele było słabych lub złamanych. TLS 1.3 ogranicza ich liczbę do zaledwie pięciu zestawów szyfrów, z których wszystkie wykorzystują AEAD (Authenticated Encryption with Associated Data): 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. Eliminuje to całe kategorie ataków, takie jak BEAST, POODLE i FREAK, które wykorzystywały słabości negocjowania szyfrów.

# Check supported TLS 1.3 cipher suites on a server
nmap --script ssl-enum-ciphers -p 443 example.com

Wznawianie 0-RTT: szybkość a bezpieczeństwo

Wznawianie 0-RTT (Zero Round Trip Time) to opcjonalna funkcja TLS 1.3, która umożliwia klientowi wysłanie danych aplikacji już w pierwszym komunikacie, przed zakończeniem uzgadniania połączenia. Działa dzięki użyciu klucza wstępnie współdzielonego (Pre-Shared Key, PSK) z poprzedniej sesji. Chociaż 0-RTT znacznie zmniejsza opóźnienia — co ma kluczowe znaczenie w przypadku interfejsów API o dużym natężeniu ruchu — wprowadza istotny kompromis: dane wczesne nie są chronione przed atakami typu replay.

Ryzyko ataku typu replay w 0-RTT

W przypadku ataku typu replay na dane 0-RTT atakujący, który przechwyci komunikat z danymi wczesnymi, może wysłać go ponownie do serwera, potencjalnie powodując dwukrotne wykonanie tej samej czynności (np. płatności lub zmiany stanu). Specyfikacja TLS 1.3 wyraźnie ostrzega, że dane wczesne 0-RTT mogą zawierać wyłącznie operacje idempotentne — takie, które dają ten sam wynik niezależnie od liczby wykonań, jak żądanie GET. Operacje nieidempotentne (POST, DELETE) nigdy nie powinny korzystać z 0-RTT.

Klucze wstępnie współdzielone i wznawianie sesji

Po pomyślnym zakończeniu pełnego uzgadniania TLS 1.3 serwer wysyła komunikat NewSessionTicket zawierający PSK (Pre-Shared Key), który klient przechowuje. Przy ponownym połączeniu klient umieszcza ten PSK w komunikacie ClientHello, korzystając z rozszerzenia pre_shared_key. Serwer rozpoznaje klucz i albo zatwierdza dane 0-RTT, albo przechodzi do wznawiania 1-RTT. Bilety PSK mają ograniczony czas ważności i powinny być często wymieniane, aby ograniczyć okres ich narażenia.

Szyfrowane uzgadnianie połączenia: ukrywanie metadanych

Istotnym ulepszeniem w TLS 1.3 jest to, że większość uzgadniania połączenia jest szyfrowana, w tym certyfikat serwera. W TLS 1.2 certyfikat serwera był przesyłany jawnym tekstem, co umożliwiało obserwatorowi sieciowemu ustalenie, z jaką domeną łączył się klient. TLS 1.3 szyfruje certyfikat i większość kolejnych komunikatów uzgadniania połączenia, ograniczając ilość metadanych dostępnych dla biernych obserwatorów. Encrypted Client Hello (ECH) to rozwijane rozszerzenie, które ukrywa nawet pole SNI (Server Name Indication).

Usunięte funkcje: co wyeliminowano z TLS 1.3

TLS 1.3 usunął wiele starszych funkcji, które stały się zagrożeniami: wymianę kluczy RSA (brak utajnienia przekazywania), zestawy szyfrów w trybie CBC (podatne na ataki z użyciem wyroczni wypełnienia), RC4 (całkowicie złamany szyfr strumieniowy), kryptografię klasy eksportowej (przyczynę ataków FREAK i Logjam), MD5 i SHA-1 w podpisach cyfrowych, kompresję (przyczynę ataku CRIME) oraz renegocjację (przyczynę wielu ataków). Dzięki ich usunięciu TLS 1.3 ma znacznie mniejszą powierzchnię ataku.

Konfigurowanie serwerów na potrzeby TLS 1.3

Prawidłowe wdrożenie TLS 1.3 wymaga skonfigurowania serwera internetowego tak, aby preferował ten protokół, przy jednoczesnym wyłączeniu TLS 1.0 i 1.1. Większość nowoczesnych serwerów internetowych (Nginx, Apache, IIS) natywnie obsługuje TLS 1.3. Należy również upewnić się, że włączono OCSP Stapling, aby dostarczać informacje o unieważnieniu certyfikatu bez konieczności kontaktowania się klienta z urzędem certyfikacji, oraz że nagłówki HSTS zapobiegają atakom obniżającym protokół do HTTP. Do weryfikacji konfiguracji i sprawdzenia, czy uzyskuje ocenę A+, należy użyć narzędzi takich jak SSL Labs.

# Nginx TLS 1.3 configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security 'max-age=63072000' always;

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji dowiedziałeś się, że: TLS 1.3 kończy uzgadnianie połączenia w ramach 1-RTT, wykorzystując wyłącznie efemeryczną wymianę kluczy DH w celu zapewnienia doskonałego utajnienia przekazywania; wznawianie 0-RTT umożliwia szybsze ponowne połączenie dzięki PSK, ale jest podatne na ataki typu replay i powinno obsługiwać wyłącznie operacje idempotentne; a TLS 1.3 usuwa wszystkie słabe starsze funkcje — wymianę kluczy RSA, szyfry CBC, RC4, kryptografię eksportową i kompresję — znacznie zmniejszając powierzchnię ataku. Następnie omówimy algorytmy szyfrowania uwierzytelnionego, takie jak AES-GCM.

Często zadawane pytania

Czy lekcja „Uzgadnianie TLS 1.3 i wznowienie 0-RTT” jest bezpłatna?

Tak — pełny tekst „Uzgadnianie TLS 1.3 i wznowienie 0-RTT” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Security+ Academy, przejdź na CoddyKit PRO. Kurs Security+ Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Uzgadnianie TLS 1.3 i wznowienie 0-RTT”?

Prześledź krok po kroku uzgadnianie TLS 1.3, poznaj sposób, w jaki domyślnie zapewnia forward secrecy, i oceń kompromisy bezpieczeństwa związane ze wznowieniem sesji 0-RTT. Ćwiczysz Security+ Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Security+ Academy?

Nie wymagamy żadnego doświadczenia. Security+ Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Uzgadnianie TLS 1.3 i wznowienie 0-RTT”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Security+ Academy?

Tak. Każda lekcja Security+ Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Uzgadnianie TLS 1.3 i wznowienie 0-RTT
  2. Szyfrowanie uwierzytelnione: AES-GCM i ChaCha20-Poly1305
  3. Funkcje wyprowadzania klucza: PBKDF2, bcrypt i Argon2
  4. Kryptografia postkwantowa: CRYSTALS-Kyber i Dilithium
← Powrót do Security+ Academy