Qualys SSL Labs to jedna z wielu witryn pozwalających na przetestowanie przeglądarki pod kątem zgodności ze standardami sieciowymi oraz podatności na dobrze znane luki w zabezpieczeniach.

10 lat po opublikowaniu standardu TLS 1.2 organizacja Internet Engineering Task Force (IETF), zajmująca się ustanawianiem standardów technicznych i organizacyjnych dla funkcjonowania sieci komputerowych i internetu, przyjęła następną dużą aktualizację protokołu TLS oznaczoną numerem 1.3. Najnowsza wersja standardu usuwa wiele podatności protokołu na dobrze znane wektory ataku oraz wprowadza mechanizmy, które, w połączeniu ze standardem HTTP/2, zapewniają oczekiwaną wydajność współczesnych stron i aplikacji webowych. Standard został opublikowany w dokumencie IETF RFC 8446.

W kierunku TLS 1.3

Należy przyjąć, że proces powszechnej akceptacji TLS 1.3 zajmie kilka najbliższych lat, a aktualnie stosowany TLS 1.2 będzie sukcesywnie wypierany. Zanim to się stanie, z rynku muszą definitywnie zniknąć przestarzałe wersje protokołu. W październiku 2018 r. twórcy czterech największych przeglądarek internetowych: Google (Chrome), Mozilla (Firefox), Apple (Safari) i Microsoft (Edge i Internet Explorer 11) zapowiedzieli, że w pierwszej połowie 2020 r. zaprzestaną wspierania TLS 1.0 oraz TLS 1.1 w swoich produktach. Branża spodziewa się, że również IETF uzna w najbliższym czasie oba standardy za przestarzałe, a kolejne aktualizacje usuwające wykrywane luki nie będą już publikowane.

Taki krok nie powinien dziwić – TLS 1.0 w styczniu 2019 r. będzie miał już 20 lat, a poziom adaptacji TLS 1.2 jest już na tyle wysoki, że wycofanie przestarzałych technologii z użycia nie spowoduje żadnych perturbacji dla użytkowników. Google podaje, że zaledwie 0,5% połączeń HTTP realizowanych jest z wykorzystaniem TLS 1.0 lub 1.1. W przypadku platformy Apple odsetek ten wynosi raptem 0,36%. W rezultacie 99,6% bezpiecznych połączeń w Safari obsługiwanych jest przez TLS 1.2.

Wektory ataku

TLS 1.3 ma być odpowiedzią na problemy z bezpieczeństwem komunikacji w internecie, które w różnych wariantach powracały na przestrzeni ostatniej dekady. Lista wektorów ataku na TLS jest dobrze znana i wynika z niedoskonałości samego protokołu, zastosowania prymitywnych jak na dzisiejsze czasy mechanizmów kryptograficznych, błędów w implementacji protokołu w oprogramowaniu, niewłaściwej współpracy TLS z innymi protokołami internetowymi, a w końcu ze złej konfiguracji bibliotek na serwerach.

Wiele sposobów na obnażenie słabości starszych wersji TLS związanych jest z wykorzystaniem mechanizmów obniżenia wersji używanego protokołu (downgrades protocol), renegocjacji połączenia (connection renegotiation) i wznawiania sesji (session resumption). Ataki typu 3Shake, TLS Renego, POODLE, Logjam czy FREAK czerpią z niedoskonałości protokołu TLS/SSL. Standardowy schemat ataku typu man-in-the-middle polega na przejęciu komunikacji od klienta, obniżeniu zabezpieczeń używanych w komunikacji (z reguły do najsłabszego SSL 3.0), a następnie próbie wykorzystania istniejącej luki w którymś z algorytmów używanych w trakcie wymiany kluczy szyfrowania transmisji czy weryfikacji integralności przesyłanych pakietów. Implementacja TLS 1.3 zabrania użycia mechanizmów obniżenia wersji protokołu oraz renegocjacji połączeń, eliminując tym samym niedoskonałości wcześniejszych wersji TLS.

W specyfikacji TLS 1.3 usunięto wszystkie symetryczne algorytmy szyfrowania (np. MD5, SHA1, SHA-224), które zostały uznane za przestarzałe. W rezultacie do użycia dopuszczono tylko algorytmy zgodne z AEAD (Authenticated Encryption with Additional Data). Porzucono również obsługę certyfikatów DSA.

Wcześniejsze wersje TLS do zapewnienia integralności przesyłanych komunikatów, a więc tego, czy dane nie zostały zmienione podczas przesyłania, wykorzystywały schemat MAC-then-encrypt (MtE). Schemat ten korzysta z uznanej za błędną logiki, która zakłada wyliczenie wartości MAC z tekstu jawnego i dopiero jego zaszyfrowanie. W rezultacie sprawdzenie integralności wymaga najpierw odszyfrowania stenogramu. TLS 1.3 w tym obszarze wymusza użycie mechanizmów uwierzytelniania szyfrowania z dodatkowymi danymi (wspomniane algorytmy AEAD), dzięki czemu szyfrowanie i podpisanie komunikatu, a później odszyfrowywanie i weryfikacja integralności odbywają się w tym samym czasie.

Nowy zestaw szyfrów

Najnowszy standard wprowadza nowy zestaw szyfrów (cipher suites) specyficznych dla TLS 1.3 i niezgodnych z poprzednimi wersjami protokołu. Zestawy te definiowane są w odmienny sposób niż dotychczas, co wymaga użycia oddzielnych konfiguracji szyfrów dla TLS 1.3 i poprzednich wersji tego standardu. Wszystko z uwagi na to, że nowa architektura zakłada oddzielenie definicji szyfrów i funkcji haszujących od metod uwierzytelnienia stron i wymiany kluczy. W rezultacie definicja zestawu szyfrów nie zawiera informacji o typie certyfikatu (np. RSA, ECDSA itd.) ani używanym mechanizmie wymiany kluczy (np. DHE, ECDHE).

[...]

Autor zawodowo zajmuje się informatyką. Publikuje w magazynach komputerowych i serwisach internetowych.