TLS

TLS (Transport Layer Security) to protokół, który zabezpiecza połączenie między klientem a serwerem przed podsłuchem, modyfikacją i fałszowaniem wiadomości ^[1]. Jest podstawą HTTPS, a także szyfrowanej poczty i wielu innych usług. Strona serwera jest w TLS zawsze uwierzytelniana, strona klienta opcjonalnie ^[1]. Nazwa SSL oznacza starsze, wycofane wersje protokołu, choć potocznie bywa używana dla całej rodziny; stąd określenie certyfikat SSL/TLS.

Jak działa

RFC 8446, które w sierpniu 2018 roku opisało wersję 1.3, wymienia trzy właściwości bezpiecznego kanału ^[1]:

• uwierzytelnienie — klient wie, z jakim serwerem rozmawia;
• poufność — dane są widoczne tylko dla obu końców połączenia, zob. szyfrowanie;
• integralność — atakujący nie zmieni przesyłanych danych bez wykrycia.

Protokół składa się z dwóch części. Protokół uzgadniania (handshake) uwierzytelnia strony, negocjuje parametry kryptograficzne i ustala wspólne klucze. Protokół rekordów chroni potem właściwy ruch tymi kluczami ^[1]. Uwierzytelnienie serwera opiera się na certyfikacie wystawionym przez urząd certyfikacji (CA) w ramach infrastruktury klucza publicznego (PKI) i na kryptografii asymetrycznej.

Uproszczony przebieg uzgadniania w TLS 1.3 pokazuje schemat poniżej. W tej wersji wszystkie komunikaty uzgadniania po ServerHello są już szyfrowane ^[1].

RYS. 1Uzgadnianie połączenia w TLS 1.3 (uproszczone)

Wersje

Wycofanie wersji 1.0 i 1.1 RFC 8996 uzasadnia przestarzałymi zestawami szyfrów, brakiem szyfrowania uwierzytelnionego (AEAD) i oparciem integralności uzgadniania na SHA-1 ^[2]. SSL 3.0 wycofano z powodu podstawowych słabości kryptograficznych; RFC 7568 przywołuje atak POODLE na dopełnienie w trybie CBC ^[3]. NIST w wytycznych SP 800-52 Rev. 2 z sierpnia 2019 roku wymaga obsługi TLS 1.2 przez rządowe serwery i klientów oraz obsługi TLS 1.3 od 1 stycznia 2024 roku ^[4].

TLS 1.3 usunął statyczną wymianę kluczy RSA i Diffiego-Hellmana. Każda wymiana kluczy oparta na kluczu publicznym zapewnia w nim forward secrecy ^[1]: wyciek klucza prywatnego serwera nie odszyfruje wcześniej nagranych sesji. Wersja 1.3 usunęła też przestarzałe algorytmy i dodała tryb 0-RTT, skracający nawiązywanie połączenia ^[1].

W WordPressie

TLS konfiguruje się na serwerze WWW albo u dostawcy hostingu, nie w samym WordPressie. Dokumentacja WordPressa stwierdza, że jest on w pełni zgodny z HTTPS, gdy na serwerze zainstalowano certyfikat TLS/SSL dostępny dla serwera WWW ^[5].

Wymuszenie HTTPS w panelu. Stała FORCE_SSL_ADMIN ustawiona na true w pliku wp-config.php wymusza, by wszystkie logowania i wszystkie sesje panelu odbywały się przez szyfrowane połączenie ^[5]. Dawna stała FORCE_SSL_LOGIN jest przestarzała od wersji 4.0 ^[5]. Ustawienia tego pliku omawia hasło utwardzanie pliku wp-config.php.

define( 'FORCE_SSL_ADMIN', true );

Serwer pośredniczący. Gdy TLS kończy się na reverse proxy albo w CDN, WordPress nie widzi szyfrowanego połączenia bezpośrednio. Dokumentacja opisuje, jak przekazać tę informację w nagłówkach, aby uniknąć pętli przekierowań ^[5].

Przejście na HTTPS. WordPress 5.7 dodał wykrywanie, czy środowisko obsługuje HTTPS, i przełączenie adresów witryny jednym kliknięciem w Zdrowiu witryny ^[6]. Funkcja wp_replace_insecure_home_url() zamienia w locie zapisane w treści adresy http:// na https:// ^[6], co ogranicza problem mixed content. Funkcja wp_is_using_https() zwraca prawdę, gdy adres witryny i adres WordPressa używają HTTPS ^[6].

Zagrożenia i skutki

Bez TLS dane logowania, ciasteczka sesji i treść formularzy przechodzą przez sieć jawnym tekstem. Atakujący w tej samej sieci może je odczytać albo zmienić; to scenariusz man-in-the-middle (MITM).

Sam protokół nie wystarcza, jeśli zawodzi jego implementacja. Przykładem jest Heartbleed, czyli CVE-2014-0160 — błąd w obsłudze rozszerzenia heartbeat w bibliotece OpenSSL ^[7]. Podatne były wersje od 1.0.1 do 1.0.1f, a poprawkę przyniosła 1.0.1g ^[7]. Błąd pozwalał odczytać fragmenty pamięci serwera, w tym klucze prywatne certyfikatów, nazwy użytkowników i hasła ^[7]. Według opisu błędu, oznaczonego identyfikatorem CVE, naprawa wymagała nie tylko łatki, lecz także unieważnienia przejętych kluczy i wydania nowych ^[7].

Opis Heartbleed zwraca uwagę na jeszcze jeden skutek: nawet po łatce i wymianie kluczy ruch nagrany wcześniej przez atakującego nadal można odszyfrować ^[7]. Przed takim scenariuszem chroni właśnie forward secrecy, obowiązkowe w TLS 1.3 ^[1].

Trzeba też pamiętać o zasięgu ochrony. TLS zabezpiecza dane w drodze między przeglądarką a serwerem albo serwerem pośredniczącym. Nie szyfruje danych zapisanych w bazie ani plików na serwerze i nie jest tym samym, co szyfrowanie end-to-end (E2EE).

Ryzykiem jest też pozostawienie włączonych starych wersji. RFC 8996 wskazuje, że oparcie uzgadniania TLS 1.0 i 1.1 na SHA-1 umożliwia ataki na obniżenie wersji ^[2].

Dobre praktyki

• Wyłączyć SSL 2.0, SSL 3.0, TLS 1.0 i TLS 1.1; RFC 8996 i RFC 7568 zabraniają ich negocjowania ^{[2] [3]}.
• Włączyć TLS 1.2 i TLS 1.3, zgodnie z kierunkiem wytycznych NIST ^[4].
• Przekierować cały ruch HTTP na HTTPS i rozważyć nagłówek HSTS, który każe przeglądarce łączyć się wyłącznie przez HTTPS.
• W WordPressie ustawić FORCE_SSL_ADMIN ^[5] i sprawdzić stan HTTPS w Zdrowiu witryny ^[6].
• Aktualizować bibliotekę TLS serwera; Heartbleed pokazał, że błąd implementacji może ujawnić klucz prywatny ^[7].
• Pilnować ważności certyfikatu i odnawiać go automatycznie.

Historia i przykłady

• 2011: wycofanie SSL 2.0 w RFC 6176 ^[2].
• 7 kwietnia 2014: ujawnienie Heartbleed (CVE-2014-0160) ^[7].
• Czerwiec 2015: RFC 7568 wycofuje SSL 3.0 ^[3].
• Sierpień 2018: publikacja TLS 1.3 w RFC 8446 ^[1].
• Luty 2021: zapowiedź ułatwień w przejściu na HTTPS w WordPressie 5.7 ^[6].
• Marzec 2021: RFC 8996 wycofuje TLS 1.0 i TLS 1.1 ^[2].