Jakie algorytmy szyfrujące są używane w SSL/TLS?

Algorytmy szyfrujące używane w SSL/TLS dzielą się na asymetryczne do bezpiecznej wymiany kluczy (takie jak RSA, ECC, Diffie-Hellman) oraz symetryczne do błyskawicznego zabezpieczania samej transmisji danych (głównie AES i ChaCha20). Cały ten proces autoryzacji i ochrony uzupełniają kryptograficzne funkcje skrótu, najczęściej z rodziny SHA-256 lub SHA-384, które dają gwarancję, że nikt nie zmodyfikował pakietów w locie między przeglądarką a serwerem.

Prawda jest zresztą absolutnie taka, że większość ludzi konfigurujących serwery WWW traktuje protokoły kryptograficzne jak czarną magię. Odpalają domyślne ustawienia w Nginx, kopiują gotowy blok kodu ze Stack Overflow i idą na kawę. A potem przychodzi audyt bezpieczeństwa. Okazuje się, że serwer wpuszcza ruch na starych, dziurawych szyfrach z epoki kamienia łupanego. Wdrożenia kryptografii wymagają twardego stąpania po ziemi. Zrozumienie, co dokładnie dzieje się pod maską podczas nawiązywania połączenia, to podstawa. Inaczej po prostu prosimy się o wyciek danych.

Jak dokładnie działa podział ról między algorytmami w TLS?

Protokół TLS (Transport Layer Security), który dawno temu zastąpił przestarzały SSL, nie opiera się na jednym magicznym algorytmie. To zbiór narzędzi. Działa to w oparciu o specyficzny podział obowiązków. Mamy tu do czynienia z dwiema zupełnie różnymi fazami połączenia. Najpierw trzeba dogadać się z obcym serwerem w niezaufanym środowisku, a potem szybko przesyłać megabajty danych.

Faza pierwsza to tak zwany handshake. Używamy tu kryptografii asymetrycznej. Mamy klucz publiczny i prywatny. Klucz publiczny jest dostępny dla każdego, kto pobierze certyfikat ze strony. Służy do zaszyfrowania małej paczki danych. Tę paczkę potrafi odszyfrować wyłącznie właściciel serwera, bo tylko on ma klucz prywatny. Asymetria ma jednak potężną wadę. Jest potwornie wolna. Zajechałaby procesory po obu stronach w kilka sekund, gdybyśmy próbowali tak szyfrować strumień wideo na YouTube.

Dlatego asymetria służy tylko do jednego. Do bezpiecznego wygenerowania i wymiany wspólnego, jednorazowego klucza sesji. Kiedy obie strony mają już ten sam klucz, przechodzą na kryptografię symetryczną. To faza druga. Szybka, brutalna matematyka, która mieli pakiety w locie z ogromną prędkością.

Zmieniliśmy te zasady na robocie w zeszłym kwartale. Wymusiliśmy na load balancerach całkowite odcięcie starych wariantów RSA na rzecz krzywych eliptycznych. Wynik? Spadek obciążenia procesorów o bez mała trzydzieści procent. To jest konkret.

Dlaczego RSA traci na znaczeniu na rzecz ECC?

RSA to dziadek kryptografii. Opiera się na problemie faktoryzacji wielkich liczb pierwszych. Działa, ale wymaga ogromnych kluczy. Standardem na dzisiaj jest klucz o długości 2048 bitów, a paranoicy generują 4096 bitów. Przetwarzanie takich kobył kosztuje czas i prąd.

ECC (Elliptic Curve Cryptography) robi to samo o wiele mądrzej. Zamiast mnożyć liczby pierwsze, wykorzystuje właściwości algebraiczne krzywych eliptycznych nad ciałami skończonymi. Brzmi to jak bełkot matematyczny. W praktyce oznacza tyle, że klucz ECC o długości 256 bitów daje taki sam poziom bezpieczeństwa co RSA 3072 bity. Jest lżejszy. Szybszy. Idealny dla urządzeń mobilnych, które mają małe baterie i słabe procesory.

Często na wdrożeniach widzę, jak administratorzy uparcie trzymają się certyfikatów RSA. Boją się kompatybilności. Zmuszanie starych klientów do nowoczesnych krzywych eliptycznych kończy się tym, że po prostu NIC nie działa u połowy użytkowników na starych Androidach. Ale prawda jest taka, że rynek dawno poszedł do przodu. Jeżeli ktoś używa przeglądarki, która nie rozumie ECDSA, to ma znacznie większe problemy z bezpieczeństwem niż brak dostępu do twojej strony.

Do tego dochodzi kwestia Perfect Forward Secrecy (PFS). To mechanizm, który gwarantuje, że nawet jeśli ktoś ukradnie z serwera klucz prywatny za pięć lat, nie odszyfruje dzisiejszego ruchu. Kiedyś używało się do tego zwykłego algorytmu Diffie-Hellman. Dzisiaj standardem jest wariant oparty na krzywych eliptycznych, czyli ECDHE (Elliptic-Curve Diffie-Hellman Ephemeral). Słowo „Ephemeral” oznacza, że klucze do wymiany są jednorazowe. Znikają po zamknięciu sesji. Bezpowrotnie.

Jakie algorytmy symetryczne chronią nasze dane po nawiązaniu połączenia?

Kiedy przeglądarka i serwer mają już uzgodniony wspólny klucz, wjeżdża ciężki sprzęt. Kryptografia symetryczna. Tutaj liczy się tylko jedno. Przepustowość.

Obecnie na rynku liczą się właściwie tylko dwa algorytmy. Cała reszta wyleciała do kosza lub dogorywa w systemach typu legacy, o których nikt nie chce głośno mówić na spotkaniach zarządu.

• Rozwiązanie pierwszego wyboru to AES (Advanced Encryption Standard). Zazwyczaj w wariancie AES-128 lub AES-256. Dodatkowo musi działać w trybie uwierzytelnionym, najczęściej jako AES-GCM (Galois/Counter Mode). Tryb GCM jest genialny, bo pozwala na zrównoleglenie obliczeń. Procesor może szyfrować wiele bloków danych w tym samym czasie. AES ma jeszcze jedną gigantyczną przewagę. Większość współczesnych procesorów (od serwerowych Xeonów po układy w smartfonach) ma wbudowane instrukcje sprzętowe AES-NI. Szyfrowanie odbywa się na poziomie krzemu. To idzie jak burza.
• Alternatywą jest ChaCha20 połączony z funkcją uwierzytelniającą Poly1305. Google wcisnęło to do standardu TLS kilka lat temu z myślą o tanich smartfonach z Androidem. Dlaczego? Bo tanie procesory ARM nie miały sprzętowej akceleracji dla AES. Próba szyfrowania AES-em na takim telefonie pożerała baterię w mgnieniu oka. ChaCha20 to szyfr strumieniowy. Składa się z prostych operacji matematycznych (dodawanie, rotacja bitów, XOR). Działa błyskawicznie w oprogramowaniu, bez dedykowanego sprzętu.

Co wybrać: AES-GCM czy ChaCha20-Poly1305?

Zarządzanie Cipher Suites na serwerze WWW to pole do popisu. Dobrym pomysłem jest ustawienie priorytetów tak, aby serwer wybierał AES-GCM, gdy sprzęt klienta to wspiera, a spadał do ChaCha20 dla starszych lub tańszych urządzeń mobilnych. Cloudflare stosuje tę sztuczkę od lat.

Pamiętam, jak optymalizowaliśmy ruch w jednym z polskich e-commerce’ów w okolicach warszawskiego Mokotowa. Firma narzekała, że w godzinach szczytu load balancery dostają zadyszki. Zajrzeliśmy w konfigurację. Ktoś wymusił AES-256-CBC z przestarzałym hashowaniem HMAC. Szyfr blokowy w trybie CBC wymaga szyfrowania pakietów jeden po drugim. Nie da się tego zrównoleglić. Zmiana konfiguracji na AES-128-GCM zajęła nam trzy minuty w pliku konfiguracyjnym Nginx. Zużycie procesora na maszynach brzegowych spadło o połowę natychmiast po restarcie usługi. Takie to proste.

W jaki sposób funkcje skrótu gwarantują, że nikt nie zmodyfikował pakietów?

Samo zaszyfrowanie danych nie wystarczy. Napastnik siedzący w tej samej sieci Wi-Fi w kawiarni nie odszyfruje twojego ruchu, ale może spróbować uszkodzić pakiety. Może zamienić losowe bity. Jeśli aplikacja bankowa dostanie taki uszkodzony ciąg znaków, może zachować się nieprzewidywalnie. Trzeba mieć pewność, że to, co wyszło z serwera, dotarło do przeglądarki w nienaruszonej formie.

Do tego służą funkcje skrótu (hash). W TLS używamy ich do budowy mechanizmów MAC (Message Authentication Code). W starych wersjach protokołu stosowano HMAC w połączeniu z SHA-256. Dziś, dzięki wspomnianym algorytmom AEAD (Authenticated Encryption with Associated Data) takim jak AES-GCM czy ChaCha20-Poly1305, uwierzytelnianie danych jest zintegrowane bezpośrednio z procesem szyfrowania.

SHA-256 wciąż jednak gra pierwsze skrzypce w samym procesie handshake’u i przy weryfikacji certyfikatów. Kiedy łączysz się ze stroną, serwer wysyła swój certyfikat podpisany przez urząd certyfikacji (CA). Przeglądarka musi sprawdzić ten podpis. Używa do tego właśnie funkcji SHA-256. Jeśli choć jeden znak w certyfikacie został zmieniony, wygenerowany hash będzie zupełnie inny. Algorytm odrzuci połączenie i wyrzuci na ekran wielki, czerwony błąd. I bardzo dobrze.

Stare funkcje takie jak MD5 i SHA-1 są od dawna martwe. MD5 to zresztą katastrofa. Hakerzy potrafią dzisiaj wygenerować kolizję MD5 w kilka sekund na zwykłym laptopie. Oznacza to, że mogą stworzyć dwa różne pliki, które dają taki sam skrót. Kto używa MD5 do czegokolwiek w systemach bezpieczeństwa, ten powinien zmienić branżę.

Jakie zmiany wprowadził protokół TLS 1.3 w kontekście kryptografii?

Wersja TLS 1.3, opublikowana w 2018 roku pod numerem RFC 8446, to była rzeź. Inżynierowie z IETF (Internet Engineering Task Force) dosłownie wzięli tasak i odcięli wszystko, co stanowiło balast historyczny. To nie była lekka ewolucja. To było zrównanie starego miasta z ziemią i postawienie go na nowo z betonu.

Zredukowano liczbę obsługiwanych pakietów szyfrujących (Cipher Suites) z kilkudziesięciu do zaledwie pięciu. Pięciu konkretnych, pancernych zestawów. Zniknęły potworki z lat 90. Zniknęło zjawisko negocjowania słabych szyfrów w ramach ataków downgrade (np. atak POODLE czy FREAK).

Z TLS 1.3 całkowicie wyleciał klasyczny algorytm wymiany kluczy RSA. Został zablokowany bezpowrotnie. Serwery muszą teraz używać mechanizmów zapewniających Perfect Forward Secrecy, czyli ECDHE lub DHE. Samo uwierzytelnianie serwera wciąż może bazować na certyfikacie RSA, ale klucz sesji musi być generowany efemerycznie. To całkowicie ucina możliwość pasywnego podsłuchiwania ruchu przez agencje wywiadowcze, które nagrywają zaszyfrowany ruch w nadziei, że kiedyś ukradną klucz główny.

Kolejna sprawa to prędkość. TLS 1.2 wymagał dwóch pełnych obiegów sieciowych (2-RTT) w fazie handshake’u, zanim poleciał pierwszy użyteczny bajt danych. TLS 1.3 redukuje to do 1-RTT. Klient od razu, w pierwszej wiadomości ClientHello, wysyła swoje parametry kryptograficzne i klucz publiczny do wymiany z serwerem. Zakłada z góry użycie krzywych eliptycznych. Jeśli serwer to obsługuje, dogadują się w ułamku sekundy. A dla wznawianych sesji wprowadzono mechanizm 0-RTT. Dane lecą natychmiast z pierwszym pakietem autoryzacyjnym. Z punktu widzenia opóźnień sieciowych, to absolutna przepaść.

Dlaczego całkowicie wycięto starsze szyfry?

Utrzymywanie wstecznej kompatybilności w kryptografii to proszenie się o kłopoty. Kod obsługujący stare szyfry strumieniowe (jak RC4) i tryby blokowe (CBC) był pełen luk. Był skomplikowany. Im więcej kodu, tym większa szansa na błąd programisty. Wyrzucenie RC4, 3DES, starych funkcji HMAC-MD5 i HMAC-SHA1 sprawiło, że biblioteki takie jak OpenSSL mogły wreszcie usunąć tysiące linii martwego, niebezpiecznego kodu.

(Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Próba przepchnięcia starej aplikacji napisanej w Javie 7 przez nowoczesny load balancer z wymuszonym TLS 1.3 kończy się błędem „handshake failure”. Zamiast pisać łatki do load balancera, trzeba zaktualizować środowisko Javy u klienta. Nie ma litości dla długu technologicznego).

Czy komputery kwantowe zniszczą obecne algorytmy szyfrujące w SSL?

To temat, który spędza sen z powiek analitykom od kilku lat. Algorytm Shora odpalony na wystarczająco mocnym komputerze kwantowym potrafi rozłożyć na łopatki RSA, ECDSA i Diffie-Hellmana. Asymetryczna matematyka, na której opiera się dzisiejszy internet, legnie w gruzach. Komputer kwantowy po prostu zgadnie klucz prywatny z klucza publicznego w czasie rzeczywistym.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższą dekadę. Nikt dzisiaj nie dysponuje sprzętem kwantowym o odpowiedniej liczbie stabilnych kubitów logicznych. Fizycy walczą z szumem i dekoherencją. Ale zagrożenie nosi nazwę „Harvest Now, Decrypt Later”. Ktoś może nagrywać twój dzisiejszy zaszyfrowany ruch i trzymać go na dyskach w piwnicy przez piętnaście lat, czekając, aż technologia kwantowa dogoni teorię.

Dlatego organizacje standaryzujące, takie jak NIST, już teraz wdrażają algorytmy PQC (Post-Quantum Cryptography). Algorytmy te opierają się na problemach matematycznych odpornych na komputery kwantowe. Na przykład na kratach (Lattice-based cryptography). W kontekście TLS trwają eksperymenty z hybrydowym podejściem. Przeglądarka i serwer negocjują klucz za pomocą tradycyjnego X25519 (krzywe eliptyczne) oraz kwantowo-odpornego algorytmu Kyber. Jeśli z matematyką Kybera jest coś nie tak i ktoś znajdzie w niej klasyczną lukę, chroni nas X25519. Jeśli za 10 lat odpalą komputer kwantowy łamiący X25519, chroni nas Kyber. Pragmtyczne podejście inżynierskie.

Z kolei kryptografia symetryczna, czyli nasz roboczy AES-256, jest relatywnie bezpieczna. Algorytm Grovera pozwala komputerom kwantowym na szybsze przeszukiwanie przestrzeni kluczy symetrycznych, co w praktyce zmniejsza siłę AES-256 do poziomu AES-128. A 128 bitów bezpieczeństwa kwantowego to wciąż mur nie do przebicia. Skupiamy się więc głównie na ratowaniu asymetrii.

Sprawdź konfigurację swojego serwera jeszcze dzisiaj. Odpal skaner SSL Labs od Qualys na swojej domenie. Jeśli widzisz ocenę niższą niż mocne A, to znaczy, że masz w konfiguracji Nginx lub Apache syf do posprzątania. Wywal obsługę TLS 1.0 i 1.1. Zablokuj szyfry CBC. Ustaw priorytet na krzywe eliptyczne i AES-GCM. Nie czekaj, aż ktoś wyciągnie ci z bazy dane klientów przez banalny błąd downgrade’u kryptograficznego z 2014 roku.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. CERT Polska – https://cert.pl
3. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
4. Internet Engineering Task Force – https://ietf.org
5. Narodowe Centrum Badań i Rozwoju – https://www.gov.pl/web/ncbr