Jak działa protokół TLS Handshake? Wyjaśnienie krok po kroku

Protokół TLS (Transport Layer Security) handshake stanowi kluczowy mechanizm inicjujący bezpieczną komunikację między klientem a serwerem, umożliwiając wymianę danych szyfrowanych poprzez ustalenie wspólnych kluczy sesji i weryfikację tożsamości stron.

Proces handshake’u to sekwencja wiadomości, w której negocjowane są algorytmy szyfrowania, weryfikowane certyfikaty i generowane tajne klucze sesji do szyfrowania całej komunikacji. Historia sięga lat 90., gdy Netscape stworzył SSL – ewoluujący do TLS 1.3, który przyniósł skok wydajności i bezpieczeństwa. W tym tekście objaśniamy mechanizm TLS handshake – od podstaw po praktyczne optymalizacje.

Fundament i cel protokołu TLS

TLS to protokół kryptograficzny zapewniający prywatność, autentyczność i integralność danych przesyłanych w internecie. Najczęściej szyfruje komunikację między przeglądarką a serwerem WWW.

Działa dzięki połączeniu kryptografii asymetrycznej (klucz publiczny/prywatny) i symetrycznej (wspólny klucz sesji), co zapewnia kompromis wydajność–bezpieczeństwo. Handshake rozpoczyna się po ustanowieniu połączenia TCP, po czym strony wymieniają wiadomości ustalające parametry bezpieczeństwa.

Główne etapy procesu wyglądają następująco:

• negocjacja parametrów (wersja protokołu, zestawy szyfrów, rozszerzenia),
• uwierzytelnianie stron (najczęściej serwera poprzez certyfikat),
• wymiana kluczy (ustalenie wspólnego sekretu bez jego przesyłania),
• weryfikacja, że obie strony obliczyły te same klucze sesji.

TLS chroni dane przed przechwyceniem, nieautoryzowanym dostępem i modyfikacją, a także przed atakami typu man-in-the-middle.

Każdego dnia miliardy użytkowników korzystają z HTTPS chronionego przez TLS – często nie zdając sobie sprawy z toczących się w tle złożonych operacji kryptograficznych.

Architektura i warstwy protokołu TLS

TLS działa między warstwą aplikacji a transportową modelu TCP/IP, zapewniając szyfrowanie przezroczyste dla protokołów aplikacyjnych (HTTP, SMTP, IMAP). Aplikacje korzystają z bezpiecznego kanału bez konieczności zmian w kodzie.

Sam TLS składa się z dwóch podprotokołów: handshake (uwierzytelnianie i wymiana kluczy) oraz record (szyfrowanie i integralność danych po ustanowieniu połączenia).

TLS 1.2 handshake – tradycyjne podejście z wymianą RSA

Specyfikacja RFC 5246 definiuje handshake TLS 1.2. Z algorytmem wymiany kluczy RSA wymaga on zwykle dwóch pełnych RTT. Poniżej zarys przebiegu:

• ClientHello – klient wysyła obsługiwane wersje TLS, listę zestawów szyfrów i losową wartość Client Random;
• ServerHello i Certificate – serwer wybiera wersję i szyfr, dołącza Server Random i swój certyfikat z kluczem publicznym; kończy fazę negocjacji wiadomością ServerHelloDone;
• Weryfikacja certyfikatu – klient sprawdza ważność, zgodność domeny i podpis wystawcy (CA) w łańcuchu zaufania;
• ClientKeyExchange – klient generuje 48‑bajtowy pre‑master secret, szyfruje kluczem publicznym serwera i wysyła do odszyfrowania prywatnym kluczem serwera;
• Wyprowadzenie kluczy – obie strony obliczają master secret (48 B) z użyciem PRF i wartości: pre‑master, Client Random, Server Random; następnie wyprowadzają klucze sesji i wektory IV;
• ChangeCipherSpec i Finished (klient) – klient przełącza się na szyfrowanie i wysyła pierwszą zaszyfrowaną wiadomość Finished (skrót dotychczasowego handshake’u);
• ChangeCipherSpec i Finished (serwer) – serwer weryfikuje Finished, przełącza się na szyfrowanie i odsyła własną Finished.

Po wymianie wiadomości Finished obie strony mogą bezpiecznie przesyłać dane aplikacyjne.

Algorytm wymiany kluczy RSA – mechanika kryptograficzna

RSA to klasyczna kryptografia asymetryczna oparta na trudności faktoryzacji dużych liczb. Klucz publiczny służy do szyfrowania, a odszyfrowanie jest możliwe wyłącznie kluczem prywatnym.

Brak Perfect Forward Secrecy (PFS) w RSA do wymiany kluczy oznacza, że kompromitacja klucza prywatnego serwera w przyszłości pozwala odszyfrować historyczne sesje. Dlatego współczesne wdrożenia preferują efemeryczne metody DH/ECDH.

Diffie–Hellman ephemeral (DHE) – wymiana kluczy z tajnością do przodu

DHE generuje nową, tymczasową parę kluczy dla każdej sesji. Obie strony wyliczają wspólny sekret z własnego klucza prywatnego i publicznego klucza drugiej strony, nie ujawniając kluczy prywatnych.

W TLS 1.2 serwer wysyła podpisane parametry Diffie–Hellmana i swój publiczny klucz DH, a klient odsyła swój publiczny klucz DH w ClientKeyExchange. Podpis zapewnia autentyczność parametrów.

Elliptic Curve Diffie–Hellman ephemeral (ECDHE) – nowoczesny standard

ECDHE operuje na krzywych eliptycznych, zapewniając porównywalne bezpieczeństwo przy krótszych kluczach i mniejszych opóźnieniach. Przykładowo, ECDHE 256‑bit ≈ RSA 2048‑bit.

E aktywnie stosowany w TLS 1.2 i obowiązkowy w TLS 1.3, ECDHE stał się domyślnym mechanizmem wymiany kluczy w nowoczesnych wdrożeniach.

Kompleksowa analiza handshake’u TLS 1.3

TLS 1.3 (RFC 8446) radykalnie upraszcza proces, redukując liczbę RTT z dwóch do jednego. Klient dołącza key share (ECDHE) już w pierwszym ClientHello, co pozwala serwerowi natychmiast obliczyć wspólny sekret.

Serwer odpowiada ServerHello, a następnie wysyła już szyfrowane: EncryptedExtensions, Certificate, CertificateVerify i Finished. Klient weryfikuje te wiadomości i odsyła własne Finished.

Cały handshake wymaga jednego RTT, co znacząco obniża opóźnienia, zwłaszcza na łączach mobilnych i dalekich trasach sieciowych.

Dla szybkiego porównania kluczowych różnic między TLS 1.2 i TLS 1.3:

Cecha	TLS 1.2	TLS 1.3
RTT podczas pełnego handshake’u	2 RTT	1 RTT
Wymiana kluczy	RSA, DHE, ECDHE	tylko ECDHE (PFS obowiązkowe)
Lista szyfrów	obszerna, zawiera tryby niespójne	zredukowana do bezpiecznych AEAD
0‑RTT	brak	dostępne (z ryzykiem replay)
Szyfrowanie wiadomości handshake	po ChangeCipherSpec	większość od razu po ServerHello
Negocjacja wersji	w polu wersji rekordu	w rozszerzeniach ClientHello

Weryfikacja certyfikatów i łańcuch zaufania

Certyfikat serwera zawiera nazwę domeny, wystawcę (CA), okres ważności, klucz publiczny i podpis cyfrowy CA. Klient musi zweryfikować kilka elementów:

• ważność certyfikatu (daty od–do oraz poprawność podpisu),
• zgodność nazwy domeny (CN/SAN) z odwiedzaną domeną,
• status odwołania w CRL lub OCSP.

Weryfikacja podpisu CA wykorzystuje klucz publiczny z magazynu zaufanych rootów (root store). Klient buduje łańcuch: root → intermediate → end‑entity. Jeśli łańcuch jest kompletny i zaufany – certyfikat zostaje zaakceptowany.

Zestawy szyfrów – koreografia algorytmów kryptograficznych

Zestaw szyfrów (cipher suite) definiuje poniższe komponenty połączenia:

• algorytm wymiany kluczy (np. ecdhe),
• algorytm uwierzytelniania (np. ecdsa lub rsa),
• algorytm szyfrowania (np. aes‑gcm),
• funkcję skrótu (np. sha‑256).

Przykład: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 oznacza ECDHE (wymiana kluczy), ECDSA (uwierzytelnianie), AES‑256‑GCM (szyfrowanie) i SHA‑384 (MAC).

W TLS 1.3 listę zredukowano do bezpiecznych opcji, eliminując przestarzałe algorytmy oraz RSA do wymiany kluczy. PFS i AEAD są wymagane.

Funkcje pseudolosowe i wyprowadzanie kluczy

W TLS 1.2 funkcja PRF (oparta zwykle o HMAC‑SHA‑256) przekształca pre‑master secret w master secret, a następnie wyprowadza klucze sesji.

W TLS 1.3 stosuje się HKDF z fazą ekstrakcji i ekspansji, co zapewnia lepszą separację materiału kluczowego i podnosi bezpieczeństwo.

Zaawansowane mechanizmy – wznowienie sesji i 0‑RTT

Wznowienie ogranicza koszt pełnego handshake’u. Session IDs przechowują stan po stronie serwera pod identyfikatorem, co utrudnia skalowanie horyzontalne.

Session Tickets (RFC 5077) przenoszą zaszyfrowany stan na klienta (wiadomość NewSessionTicket), ułatwiając działanie w klastrach – każdy serwer z kluczem do biletów może odtworzyć parametry sesji.

W TLS 1.3 dodano 0‑RTT, które pozwala klientowi wysłać zaszyfrowane dane aplikacyjne już z ClientHello. Dane 0‑RTT są podatne na replay, dlatego należy stosować je wyłącznie do operacji idempotentnych i wdrożyć mechanizmy ograniczające ponowne odtworzenia.

Ataki na TLS handshake i downgrade attacks

Ataki degradacji (downgrade) wymuszają użycie słabszej wersji lub algorytmów. Przykład: POODLE (Padding Oracle on Downgraded Legacy Encryption), wykorzystujący zejście do SSL 3.0.

TLS 1.3 zmienia negocjację wersji (w rozszerzeniach ClientHello), co utrudnia manipulacje. SSL 3.0, TLS 1.0 i TLS 1.1 należy wyłączyć; TLS 1.2 i TLS 1.3 pozostają zalecane.

W obronie pomagają HSTS i mechanizmy wykrywania degradacji, np. TLS_FALLBACK_SCSV.

Rola integralności i message authentication codes

Samo szyfrowanie nie gwarantuje integralności – potrzebny jest MAC (najczęściej HMAC). Dzięki temu odbiorca wykryje modyfikacje danych.

W TLS 1.3 stosuje się wyłącznie algorytmy AEAD (np. AES‑GCM, ChaCha20‑Poly1305), które łączą poufność i integralność w jednym prymitywie.

Wpływ wydajności i latencji handshake’u

Handshake wprowadza dodatkowe RTT i koszty kryptograficzne. W TLS 1.2 z 2 RTT opóźnienie bywa odczuwalne (mobilnie, na długich trasach).

TLS 1.3 oszczędza setki milisekund, redukując handshake do 1 RTT. Wznowienia i 0‑RTT skracają czas jeszcze bardziej. Pomagają też Session Resumption, Session Tickets i topologie CDN.

Synteza procesu handshake’u

TLS handshake jednocześnie ustanawia wspólny sekret bez jego przesyłania, uwierzytelnia serwer, uzgadnia algorytmy kryptograficzne i weryfikuje poprawność kluczy. Ewolucja od TLS 1.2 do TLS 1.3 pokazuje, jak projektowe uproszczenia i eliminacja słabych elementów podnoszą bezpieczeństwo i wydajność.

Rekomendacje i dobre praktyki dla implementacji

Poniższa lista ułatwia szybką konfigurację bezpiecznego i wydajnego TLS:

• Wersje protokołu – wspieraj wyłącznie TLS 1.2 i TLS 1.3; wyłącz SSL 3.0, TLS 1.0 i TLS 1.1;
• Zestawy szyfrów – preferuj ECDHE (PFS) z AEAD (np. AES‑GCM, ChaCha20‑Poly1305), wyłącz słabe i eksportowe algorytmy;
• Certyfikaty – stosuj co najmniej RSA 2048‑bit lub ECDSA 256‑bit, monitoruj daty i automatyzuj odnowienia;
• HSTS – włącz HTTP Strict Transport Security, aby wymusić HTTPS i ograniczyć ryzyko degradacji;
• Wznowienie – włącz Session Resumption i Session Tickets dla lepszej wydajności; używaj 0‑RTT wyłącznie do operacji idempotentnych;
• Konfiguracja i monitoring – regularnie skanuj konfigurację (np. skanery TLS), śledź zalecenia IETF/CERT i aktualizuj biblioteki kryptograficzne.