Od SSL do TLS
SSL 2.0 i SSL 3.0 są historycznymi poprzednikami TLS i nie powinny być włączane. TLS 1.0 i 1.1 również utraciły zastosowanie w nowoczesnych wdrożeniach. TLS 1.2 pozostaje obsługiwany ze względu na zgodność, natomiast TLS 1.3 jest nowszym protokołem z przebudowanym uzgadnianiem i harmonogramem kluczy.
Numer wersji nie jest jedynym kryterium. Bezpieczeństwo TLS 1.2 zależy od zestawu szyfrów, wymiany kluczy, algorytmu podpisu i konfiguracji implementacji.
Warstwa rekordów
Warstwa rekordów dzieli dane protokołu wyższego poziomu na fragmenty i chroni je kluczami ruchu. TLS 1.3 używa algorytmów AEAD, które zapewniają szyfrowanie i uwierzytelnienie danych w jednej konstrukcji.
Numer sekwencyjny rekordu uczestniczy w tworzeniu wartości nonce i kontroli kolejności. Powtórne użycie tej samej pary klucza i nonce może naruszyć bezpieczeństwo AEAD. Implementacja musi więc przestrzegać limitów użycia klucza i procedur aktualizacji.
Negocjacja parametrów TLS 1.3
ClientHello zawiera obsługiwane wersje, zestawy szyfrów, grupy wymiany kluczy, algorytmy podpisu i rozszerzenia. Pole key_share może od razu przenosić udział klienta w wymianie ECDHE.
ServerHello wybiera wersję, zestaw szyfrów i udział klucza serwera. Jeżeli klient nie podał udziału dla wymaganej grupy, serwer może wysłać HelloRetryRequest. Po ServerHello dalsze komunikaty uzgadniania są chronione kluczami handshake.
Uwierzytelnienie serwera
Serwer przesyła łańcuch certyfikatów oraz CertificateVerify. Podpis w CertificateVerify obejmuje skrót transkryptu uzgadniania i potwierdza posiadanie klucza prywatnego odpowiadającego certyfikatowi.
Klient sprawdza podpis, zaufanie do wystawcy, okres ważności, przeznaczenie klucza i nazwę usługi. TLS może również uwierzytelnić klienta certyfikatem, jeżeli serwer wyśle CertificateRequest.
Przebieg pełnego uzgadniania
- Klient wysyła ClientHello z parametrami i udziałem klucza.
- Serwer odpowiada ServerHello i obie strony wyprowadzają sekrety handshake.
- Serwer przekazuje EncryptedExtensions, certyfikat i CertificateVerify.
- Finished serwera uwierzytelnia dotychczasowy transkrypt.
- Klient weryfikuje serwer i odsyła własny Finished.
- Strony używają niezależnych kluczy ruchu aplikacyjnego.
Wyprowadzanie kluczy i poufność przyszła
TLS 1.3 wykorzystuje HKDF do wyprowadzania oddzielnych sekretów dla kolejnych etapów. Klucze handshake, dane aplikacyjne i wartości potrzebne do wznowienia mają odrębne konteksty.
Wymiana efemeryczna ECDHE zapewnia . Warunek zakłada usunięcie efemerycznych sekretów i brak ich przejęcia podczas sesji.
Wznowienie sesji i 0-RTT
NewSessionTicket dostarcza klientowi dane potrzebne do późniejszego wznowienia opartego na PSK. Nowe połączenie może ograniczyć liczbę operacji kryptograficznych i zachować świeże klucze przez połączenie PSK z ECDHE.
Tryb 0-RTT pozwala przesłać dane aplikacji przed zakończeniem nowego uzgadniania. Dane wczesne nie mają pełnej ochrony przed powtórzeniem. Serwer i aplikacja muszą odrzucać lub bezpiecznie obsługiwać ponowne wykonanie operacji zmieniających stan.
Alerty i zamknięcie połączenia
Błąd protokołu może spowodować wysłanie alertu i zakończenie połączenia. Alert fatalny wymaga natychmiastowego przerwania transmisji. Nie wszystkie awarie pozwalają bezpiecznie wysłać informację o przyczynie.
Komunikat close_notify sygnalizuje kontrolowane zamknięcie kierunku transmisji TLS. Aplikacja, która ignoruje brak poprawnego zamknięcia, może błędnie zaakceptować ucięty strumień jako kompletną wiadomość.
Wymagania bezpiecznego wdrożenia
- Wyłączenie SSL, TLS 1.0 i TLS 1.1.
- Preferowanie TLS 1.3 i bezpiecznych zestawów TLS 1.2.
- Ochrona klucza prywatnego i ograniczenie dostępu do niego.
- Prawidłowa walidacja certyfikatów i nazw.
- Bezpieczny generator losowy oraz aktualna biblioteka kryptograficzna.
- Kontrola użycia 0-RTT zgodnie z semantyką operacji.
- Monitorowanie błędów negocjacji bez zapisywania sekretów sesji.
Granice ochrony TLS
TLS chroni kanał między punktami, które kończą połączenie. Dane są jawne przed zaszyfrowaniem i po odszyfrowaniu. Protokół nie naprawia błędów autoryzacji, podatności parsera, przejętego punktu końcowego ani niewłaściwego przechowywania danych.