Jak TLS naprawdę zabezpiecza połączenie HTTPS?

Ludzie mówią "HTTPS oznacza szyfrowanie" i tyle, ale interesująca część to jak dwaj nieznajomi w internecie uzgodniają wspólny sekret bez osobistego spotkania, przez sieć pełną ludzi, którzy mogą słuchać. To robi TLS, a mechanizm warto rozumieć, jeśli zajmujesz się siecią, web dev lub bezpieczeństwem.

Handshake krok po kroku

Kiedy Twoja przeglądarka łączy się z https://example.com, mniej więcej tak się to odbywa (TLS 1.3, które większość stron teraz używa):

1. ClientHello — przeglądarka wysyła obsługiwane cipher suite'i, losowy nonce i przypuszczenie key share'u (używające czegoś takiego jak X25519 lub secp256r1) do wymiany kluczy.
2. ServerHello — serwer wybiera cipher suite, wysyła własny key share i zwraca certyfikat plus podpis dowodzący, że posiada klucz prywatny zgodny z tym certyfikatem.
3. Derywacja klucza — obie strony niezależnie obliczają ten sam wspólny sekret używając matematyki podobnej do Diffie-Hellman'a na swoich key share'ach. Żadna ze stron nigdy nie przesyła samego sekretu; jest on derywowany, nie wysyłany.
4. Finished messages — obie strony potwierdzają, że handshake nie został zmieniony, wysyłając MAC nad całą transkrypcją handshake'u.

Po tym wszystko jest szyfrowane kluczami symetrycznymi derywowanymi ze wspólnego sekretu, zwykle AES-128-GCM lub ChaCha20-Poly1305. TLS 1.3 zmniejszył to z dwuetapowego handshake'u TLS 1.2 do faktycznie jednego etapu, co jest rzeczywistą wygraną opóźnienia w skali.

Dlaczego certyfikat jest ważniejszy niż szyfrowanie

Szyfrowanie bez weryfikacji tożsamości jest bezużyteczne — każdy może ustanowić zaszyfrowany kanał, włączając atakującego prowadzącego man-in-the-middle. Certyfikat wiąże klucz publiczny z nazwą domeny i jest podpisany przez Certificate Authority (CA) taką jak Let's Encrypt czy DigiCine.

Twoja przeglądarka ufa stałej liście głównych CA wbudowanych w system operacyjny lub magazyn zaufania przeglądarki. Certyfikat serwera łańcuchuje się przez certyfikaty pośrednie do jednego z tych głównych. Jeśli łańcuch się nie waliduje, lub domena w certyfikacie nie pasuje do tej, którą zażądałeś, dostajesz czerwoną stronę ostrzeżenia. Ten model łańcucha zaufania to rzeczywista granica bezpieczeństwa — jeśli ktoś ukradnie klucz podpisujący CA, może stworzyć ważne certyfikaty dla dowolnej domeny, dlatego kompromisy CA są traktowane jako poważne incydenty.

Co tu robią crypto symetryczne vs asymetryczne

Crypto asymetryczne (RSA lub krzywa eliptyczna) jest wolne i kosztowne, więc TLS używa jej tylko podczas handshake'u — do autentykacji serwera i pomocy w ustaleniu wspólnego sekretu. Gdy to się skończy, wszystkie rzeczywiste dane (HTML, JSON, cokolwiek) są szyfrowane szybkimi cipher'ami symetrycznymi. To podejście hybrydowe to ten sam wzorzec, który zobaczysz w SSH, PGP i większości rzeczywistych systemów crypto: asymetryczne do tożsamości i wymiany kluczy, symetryczne do dużych danych.

Forward secrecy to powiązany szczegół wart poznania: ponieważ wspólny sekret pochodzi z efemeralnych Diffie-Hellman key share'ów generowanych świeżo na sesję, nawet jeśli ktoś nagra Twój ruch i później ukradnie klucz prywatny serwera, nie może odszyfrować starych sesji. Ta właściwość nie istniała w starszych wymianach kluczy tylko z RSA.

Sprawdzenie samodzielnie

Nie musisz na ślepo ufać zielonej ikonce kłódki. Uruchom:

openssl s_client -connect example.com:443 -tls1_3

To pokazuje ci wynegocjowany cipher suite, łańcuch certyfikatów i czy handshake rzeczywiście się ukończył. Aby szybko zobaczyć co widzi przeglądarka, curl -v https://example.com wypisuje wersję TLS i szczegóły certyfikatu przed odpowiedzią HTTP.

Możesz też odszyfrować własny ruch w Wireshark jeśli wyeksportujesz zmienną środowiskową SSLKEYLOGFILE zanim uruchomisz Chrome lub Firefox — naprawdę przydatne do debugowania problemów TLS zamiast zgadywania.

Gdzie to rzeczywiście psuje się w praktyce

Więkość rzeczywistych porażek HTTPS nie to są przełamania kryptograficzne, to operacyjne: wygasłe certyfikaty, źle skonfigurowane łańcuchy pośrednie, klienci utknięci na starych wersjach TLS, lub mixed content (strona HTTPS ładująca zasób HTTP). Rzeczywiste ataki na poziomie protokołu contra nowoczesny TLS 1.3 są rzadkie, bo specyfikacja zamknęła większość padding oracle i downgrade tricków, które dręczyły SSL 3.0 i wczesny TLS. Słabe punkty teraz to zwykle endpoints — skompromitowana CA, ukradziony klucz prywatny, lub użytkownik klikający ostrzeżenie o certyfikacie, które nie powinien.

Jeśli chcesz pójść dalej, segmenty networking i cryptography Korra Studio obejmują bazową matematykę Diffie-Hellman'a i analizę protokołu na poziomie pakietów bardziej szczegółowo.