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

Współczesna infrastruktura internetowa opiera się na bezpiecznej transmisji danych między klientami a serwerami, a fundamentem tego bezpieczeństwa są algorytmy szyfrujące wdrożone w protokołach SSL/TLS. Protokoły te wykorzystują kombinację algorytmów symetrycznych, asymetrycznych, funkcji haszujących oraz nowoczesnych trybów szyfrowania, aby zapewnić poufność, autentyczność i integralność transmitowanych informacji. SSL/TLS łączy szyfrowanie asymetryczne i symetryczne w celu ustanowienia bezpiecznego połączenia, gdzie asymetryczne algorytmy służą do wymiany kluczy, a symetryczne do szyfrowania danych.

Treść (pokaż)

Ta wielowarstwowa architektura kryptograficzna ewoluowała od SSL do obecnych wersji TLS 1.3, eliminując przestarzałe metody i wprowadzając bezpieczniejsze, wydajniejsze algorytmy.

Architektura kryptograficzna SSL/TLS i rola algorytmów szyfrujących

SSL/TLS to standardowe protokoły kryptograficzne zaprojektowane w celu zabezpieczenia komunikacji internetowej przez zapewnienie poufności i integralności transmisji danych. Protokół operuje w warstwie transportowej i umożliwia szyfrowanie protokołów warstwy aplikacji, takich jak HTTP, POP3 czy IMAP.

Podczas nawiązywania połączenia SSL/TLS klient i serwer przeprowadzają handshake, w którym ustalają parametry bezpieczeństwa, w tym zestaw szyfrów, wersję protokołu i klucze sesji.

Najważniejsze komponenty architektury kryptograficznej SSL/TLS są następujące:

wymiana kluczy – mechanizm uzgodnienia wspólnego sekretu (np. ECDHE),
uwierzytelnianie – potwierdzenie tożsamości za pomocą certyfikatu i podpisu (np. RSA, ECDSA),
szyfrowanie – ochrona poufności danych (np. AES-GCM, ChaCha20-Poly1305),
funkcje haszujące/KDF – integralność, HMAC/HKDF i pochodne kluczy.

Kluczową koncepcją jest pojęcie zestawu szyfrów (cipher suite), czyli kombinacji algorytmów używanych do wymiany kluczy, uwierzytelniania, szyfrowania i funkcji skrótu. Aby ułatwić dobór i weryfikację, zestaw szyfrów składa się z elementów:

wymiana kluczy – np. RSA, DHE, ECDHE;
uwierzytelnianie – np. RSA, ECDSA, EdDSA;
szyfrowanie – np. AES-128/256-GCM, ChaCha20-Poly1305;
funkcja skrótu – np. SHA-256, SHA-384.

Przykład zapisu: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 oznacza ECDHE (wymiana kluczy), RSA (uwierzytelnianie), AES-256-GCM (szyfrowanie) i SHA-384 (funkcje pochodne).

Algorytmy szyfrowania symetrycznego w SSL/TLS

Algorytmy symetryczne stanowią podstawę szyfrowania danych po ustanowieniu kanału. Używają tego samego klucza do szyfrowania i deszyfrowania, dzięki czemu są bardzo wydajne i skalują się do dużych wolumenów ruchu. Problem bezpiecznej wymiany klucza rozwiązuje część asymetryczna handshake’u.

Advanced Encryption Standard, powszechnie znany jako AES, jest najbardziej rozpowszechnionym i zalecanym algorytmem szyfrowania symetrycznego w nowoczesnych implementacjach SSL/TLS. To szyfr blokowy operujący na blokach 128-bitowych, z długościami klucza 128/192/256 bitów (odpowiednio 10/12/14 rund). AES pozostaje uznawany za bezpieczny i jest regularnie audytowany przez społeczność kryptograficzną.

Triple Data Encryption Standard (3DES/TDEA) był istotny historycznie, lecz ma ograniczenia (blok 64-bitowy, ryzyko kolizji przy dużych wolumenach). NIST wyznaczył 3DES do wycofania w 2017 r. i zakazał nowego użycia od końca 2023 r. – w nowoczesnym TLS jest eliminowany.

RC4 – popularny niegdyś szyfr strumieniowy – wykazuje poważne słabości (odchylenia w strumieniu klucza). Badania umożliwiły praktyczne ataki, jak RC4-NOMORE. RFC 7465 zakazuje użycia RC4 w TLS, a jego obsługa jest wyłączona w przeglądarkach i serwerach.

Camellia to szyfr symetryczny o bezpieczeństwie porównywalnym z AES (klucze 128/192/256 bitów), zatwierdzony przez IETF i ISO/IEC. Jest jednak rzadziej używany, głównie jako alternatywa w wybranych jurysdykcjach.

ChaCha20-Poly1305 to nowoczesny algorytm AEAD łączący szyfr strumieniowy ChaCha20 i MAC Poly1305. Używa klucza 256-bitowego i nonce 96-bitowego, generuje znacznik 128-bitowy. Zapewnia świetną wydajność na CPU bez AES-NI, często przewyższając AES-GCM na urządzeniach mobilnych.

Data Encryption Standard (DES) z 56-bitowym kluczem jest dziś całkowicie wycofany z powodu łatwości ataku brute force.

Algorytmy wymiany kluczy i asymetryczne w SSL/TLS

Algorytmy asymetryczne odpowiadają za bezpieczne uzgodnienie sekretów i uwierzytelnianie serwera (i opcjonalnie klienta). Poniżej najczęściej stosowane mechanizmy i ich rola:

RSA – klasyczny algorytm oparty na faktoryzacji; używany do podpisów i (historycznie) wymiany kluczy; brak PFS w tradycyjnej wymianie RSA powoduje odchodzenie od tej metody;
Diffie–Hellman (DH/DHE) – uzgadnianie klucza przez kanał publiczny; wariant DHE zapewnia efemeryczność i PFS; zalecane grupy ≥ 2048 bitów;
ECDH/ECDHE – wersja na krzywych eliptycznych; ECDHE zapewnia PFS i wysoką wydajność przy mniejszych kluczach (np. ECC 256 ≈ RSA 3072); standard w TLS 1.3;
ECDSA – podpisy cyfrowe na krzywych eliptycznych; mniejsze klucze i dobra wydajność, powszechnie łączony z ECDHE;
EdDSA (Ed25519/Ed448) – nowoczesne, szybkie i odporne na błędy implementacyjne podpisy; deterministyczne, wspierane w TLS 1.3.

Funkcje haszujące i algorytmy uwierzytelniania w SSL/TLS

Funkcje haszujące zapewniają integralność i autentyczność komunikatów oraz służą do pochodnych kluczy. Niewielka zmiana wejścia powinna całkowicie zmieniać skrót, co utrudnia manipulację danymi.

MD5 generuje 128-bitowy skrót, ale jest podatny na szybkie kolizje. RFC 6151 zaleca jego wycofanie; w TLS 1.3 niedozwolony.

SHA-1 (160 bitów) również uznano za niebezpieczny (praktyczne kolizje od 2017 r.). SHA-1 jest zabroniony w TLS 1.3.

SHA-256 (rodzina SHA-2) to domyślny wybór w TLS 1.2 i 1.3, także dla HKDF. Uważany za bezpieczny produkcyjnie.

SHA-384/512 – dłuższe skróty; SHA-384 bywa preferowany w zestawach „high security”, SHA-512 zapewnia najwyższy margines bezpieczeństwa.

SHA-3 oparty na konstrukcji „sponge” nie jest podatny na ataki rozszerzenia długości; rzadziej stosowany w TLS, ale obecny w nowych standardach.

HMAC to uwierzytelnianie wiadomości na bazie funkcji skrótu i tajnego klucza; w TLS 1.2 używany głównie z CBC. W nowoczesnym TLS rolę HMAC przejęły tryby AEAD.

Zestawy szyfrów i kombinacje algorytmów w SSL/TLS

Liczba dostępnych zestawów szyfrów w TLS 1.2 jest duża (setki kombinacji o różnym poziomie bezpieczeństwa). TLS 1.3 znacząco ogranicza zestaw do pięciu pozycji, wszystkie w trybie AEAD:

TLS_AES_128_GCM_SHA256 – nowoczesny, szeroko wspierany, korzystna wydajność;
TLS_AES_256_GCM_SHA384 – silniejszy skrót i klucz, preferowany dla środowisk o podwyższonych wymaganiach;
TLS_CHACHA20_POLY1305_SHA256 – świetny wybór na CPU bez AES-NI i w urządzeniach mobilnych;
TLS_AES_128_CCM_SHA256 – alternatywa AEAD, popularna w IoT;
TLS_AES_128_CCM_8_SHA256 – wariant z krótszym tagiem, specyficzne zastosowania.

Podczas handshake klient wysyła listę obsługiwanych zestawów szyfrów w preferowanej kolejności, a serwer wybiera wspólną pozycję. Jeśli brak zgodności, handshake nie powiedzie się i połączenie zostanie przerwane.

Tryby szyfrowania blokowego i szyfrowanie uwierzytelnione

Tryby szyfrowania określają, jak szyfr blokowy działa na danych dłuższych niż pojedynczy blok. Poniżej najważniejsze tryby i ich właściwości:

Electronic Codebook (ECB) – najprostszy, ale niebezpieczny (ujawnia wzorce); w nowoczesnym TLS nieużywany;
Cipher Block Chaining (CBC) – maskuje wzorce, lecz podatny przy błędach IV i dopełnienia; usunięty w TLS 1.3;
Galois/Counter Mode (GCM) – AEAD łączący CTR i MAC w GF(2¹²⁸); bardzo szybki z akceleracją AES, z limitami użycia klucza;
Counter with CBC-MAC (CCM) – alternatywny tryb AEAD, często w IoT, zwykle gorsza równoległość niż GCM;
ChaCha20-Poly1305 – tryb AEAD efektywny bez AES-NI, świetny na platformach mobilnych;
AES-GCM-SIV – wariant GCM zwiększający odporność na powtórne użycie nonce dzięki syntetycznemu IV.

Ewolucja algorytmów przez wersje SSL/TLS

Protokoły SSL/TLS przeszły znaczną ewolucję: każda nowa wersja wzmacniała bezpieczeństwo, dodając lepsze algorytmy i eliminując podatne metody. TLS 1.3 to skok jakościowy: AEAD-only, uproszczony handshake (1-RTT) i opcjonalne 0-RTT.

Wersja	Wymiana kluczy	Szyfrowanie	Haszowanie	Tryby	Notatki
SSL 3.0	RSA, DH	DES, 3DES, RC4	MD5, SHA-1	CBC, ECB	Całkowicie zdeprecjonowany
TLS 1.0/1.1	RSA, DHE	3DES, AES, RC4	MD5, SHA-1	CBC	Przestarzały, wsparcie wyeliminowane
TLS 1.2	RSA, DHE, ECDHE	AES, 3DES, RC4, Camellia	SHA-1, SHA-256, SHA-384	CBC, GCM, CCM	Wciąż bezpieczny, ale TLS 1.3 preferowany
TLS 1.3	ECDHE (wymagane)	AES-GCM, ChaCha20-Poly1305, AES-CCM	SHA-256, SHA-384	AEAD (wymagane)	Nowoczesny, bezpieczny, szybki

Funkcje pochodne kluczy i generowanie kluczy sesji

Funkcje pochodne kluczy (KDF) generują klucze sesji, kody uwierzytelniania i inne materiały kryptograficzne z sekretów uzgodnionych podczas handshake.

W TLS 1.2 i starszych stosowano PRF oparte na HMAC, które z sekretu i danych inicjujących (losowości klienta i serwera) generowało potrzebny materiał kluczowy.

TLS 1.3 wprowadził HKDF (HMAC-based Key Derivation Function), który rozdziela proces na dwie fazy: Extract (redukcja surowego sekretu do PRK) i Expand (rozszerzenie PRK do wymaganej ilości materiału). To modularne podejście upraszcza analizę i zwiększa bezpieczeństwo.

Szyfrowanie uwierzytelnione i zaawansowane tryby AEAD

Szyfrowanie uwierzytelnione (AE/AEAD) łączy poufność i autentyczność w jednej operacji kryptograficznej, redukując złożoność i ryzyko błędów implementacyjnych.

Tryby AEAD rozwiązują typowe problemy kombinacji „szyfrowanie + HMAC”, integrując te funkcje w jednym kroku (np. GCM, CCM, ChaCha20-Poly1305, AES-GCM-SIV). TLS 1.3 wymaga, aby wszystkie zestawy szyfrów były AEAD.

W AEAD uwierzytelnia się także powiązane dane (AD), które nie są szyfrowane (np. nagłówki), ale muszą być chronione przed manipulacją.

Zagrożenia i podatności kryptograficzne

Poniżej zestawienie najważniejszych ataków na SSL/TLS i ich implikacji dla konfiguracji:

BEAST – atak na CBC w SSL 3.0 i TLS 1.0; mitigacja: jawny IV w TLS 1.1 oraz migracja do nowszych wersji;
POODLE – „padding oracle” wykorzystujący degradację do SSL 3.0; mitigacja: całkowite wyłączenie SSL 3.0 i CBC w starych wersjach;
BREACH – atak na kompresję HTTP nad TLS; mitigacja: wyłączenie kompresji w wrażliwych kontekstach, randomizacja sekretów;
Sweet32 – atak na szyfry z blokiem 64-bitowym (np. 3DES); mitigacja: wycofanie 3DES;
LogJam – atak na DH z małymi grupami; mitigacja: grupy ≥ 2048 bitów lub przejście na ECDHE;
D(HE)at – DoS wymuszający kosztowne obliczenia DHE; mitigacja: walidacja parametrów, limity i backoff.

Nowoczesne rekomendacje bezpieczeństwa i najlepsze praktyki

Dla nowych wdrożeń zalecany jest wyłącznie TLS 1.3 i następujące zestawy szyfrów:

TLS_AES_256_GCM_SHA384 – preferowany dla środowisk „high security”;
TLS_AES_128_GCM_SHA256 – szybki i szeroko wspierany;
TLS_CHACHA20_POLY1305_SHA256 – idealny dla urządzeń mobilnych i CPU bez AES-NI.

Dla kompatybilności ze starszymi klientami TLS 1.2 warto włączyć m.in.:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.

Należy całkowicie wyłączyć następujące algorytmy i konfiguracje:

RC4,
DES i 3DES,
MD5,
SHA-1 (dla podpisów),
zestawy NULL (bez szyfrowania),
zestawy EXPORT (ze słabymi kluczami),
wymianę kluczy RSA (na rzecz ECDHE),
CBC w nowych wdrożeniach.

Stosuj perfect forward secrecy (PFS) – obowiązkowe w TLS 1.3 i silnie zalecane w TLS 1.2 – aby kompromitacja klucza prywatnego serwera nie umożliwiała odszyfrowania przeszłych sesji.

Kryptografia post-kwantowa i przyszłość SSL/TLS

Komputery kwantowe zagrożą powszechnie używanym algorytmom asymetrycznym (RSA, ECC) poprzez algorytm Shora, dlatego rośnie znaczenie kryptografii post-kwantowej (PQC).

NIST (2022) wybrał CRYSTALS-Kyber (enkapsulacja kluczy) i CRYSTALS-Dilithium (podpisy cyfrowe) jako pierwsze standardy PQC. Trwają prace nad integracją PQC z TLS, w tym mechanizmami hybrydowymi (np. ECDHE+Kyber), łączącymi bezpieczeństwo klasyczne i post-kwantowe.

Wyzwania to m.in. większe obciążenie obliczeniowe, większe rozmiary kluczy i artefaktów, a także interoperacyjność w okresie przejściowym. IETF aktywnie standaryzuje rozszerzenia TLS 1.3 dla PQC.