forward secrecy

Forward secrecy (także perfect forward secrecy, PFS) to właściwość protokołu uzgadniania kluczy, dzięki której późniejsze ujawnienie długoterminowego klucza serwera nie pozwala odszyfrować wcześniej nagranych rozmów. RFC 9325 opisuje ją jako obronę przed atakującym, który zapisuje zaszyfrowany ruch w sytuacji, gdy klucze sesji są chronione wyłącznie długoterminowymi kluczami stron ^[2]. W protokole TLS 1.3 każdy mechanizm wymiany kluczy oparty na kluczu publicznym zapewnia forward secrecy ^[1].

Jak działa

Połączenie szyfrowane używa dwóch rodzajów kluczy. Klucz długoterminowy serwera, związany z jego certyfikatem, służy do potwierdzenia tożsamości. Klucze sesji, którymi faktycznie szyfruje się dane, powstają przy każdym połączeniu.

Bez forward secrecy klucz sesji był przesyłany zaszyfrowany kluczem publicznym serwera. Tak działa tzw. statyczna wymiana RSA (RSA key transport). Kto później zdobędzie klucz prywatny serwera, odszyfruje nim klucze sesji z nagranego ruchu, a potem sam ruch. RFC 9325 odradza takie zestawy szyfrów właśnie dlatego, że nie zapewniają forward secrecy ^[2].

Z forward secrecy klucz sesji wynika z efemerycznej wymiany Diffiego-Hellmana na liczbach (DHE) albo na krzywych eliptycznych (ECDHE). To zastosowanie kryptografii asymetrycznej, w którym obie strony tworzą jednorazowe pary kluczy. NIST jako okres użycia efemerycznego klucza uzgadniania podaje jedną transakcję uzgadniania klucza ^[3]. Klucz długoterminowy tylko podpisuje parametry wymiany, więc potwierdza tożsamość, ale nie chroni samego klucza sesji. Po zakończeniu połączenia klucze efemeryczne się usuwa i nie ma z czego odtworzyć sesji.

RYS. 1Nagranie ruchu i późniejszy wyciek klucza

Odmiany

W TLS 1.2 forward secrecy zależy od zestawu szyfrów wybranego przez serwer. TLS 1.3 usunął statyczne zestawy RSA i Diffiego-Hellmana ^[1]. Nadal ma jednak trzy tryby wymiany kluczy ^[1], a nie każdy z nich daje tę samą ochronę.

RFC 8446 zaznacza, że dane wysyłane w trybie 0-RTT nie mają forward secrecy, bo są szyfrowane wyłącznie kluczami wyprowadzonymi z oferowanego klucza współdzielonego (PSK) ^[1].

W WordPressie

Forward secrecy nie jest ustawieniem WordPressa. Zależy od serwera WWW, który zestawia połączenie TLS: Apache, nginx, serwera pośredniczącego (reverse proxy) albo sieci CDN przed witryną. Na hostingu współdzielonym konfiguracją zarządza dostawca; właściciel strony może ją tylko sprawdzić i w razie braków zgłosić.

Dla witryny ma to znaczenie przy danych, które powinny pozostać poufne długo: hasła administratorów, tokeny sesji z ciasteczek, dane klientów sklepu. CERT Polska zaleca dopuszczenie wyłącznie TLS 1.2 i TLS 1.3 oraz wyłączenie starszych protokołów ^[7]. Wśród słabości konfiguracji wymienia zbyt krótkie parametry wymiany klucza Diffiego-Hellmana ^[7]. Dla systemów federalnych USA NIST wymagał obsługi TLS 1.3 od 1 stycznia 2024 roku ^[6], a w tej wersji wszystkie wymiany oparte na kluczu publicznym mają forward secrecy ^[1].

Przykładowy fragment konfiguracji nginx, który ogranicza protokoły do wersji zalecanych przez CERT Polska:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Znaczenie

Forward secrecy chroni przed scenariuszem „nagraj teraz, odszyfruj później”. Ma znaczenie wszędzie tam, gdzie ktoś może zapisać ruch: w publicznych sieciach Wi-Fi, u operatora albo w węźle pośredniczącym.

Właściwość ta ma też granice. Nie chroni przed aktywnym atakiem man-in-the-middle (MITM) w czasie rzeczywistym, bo dotyczy tylko ruchu już nagranego. Nie chroni też przed wyciekiem klucza pojedynczej sesji ani przed przejęciem samego serwera, który ma dostęp do odszyfrowanych danych. Opis błędu Heartbleed odsyła do zastrzeżenia, że wyciek biletów sesji (session tickets) może tę ochronę osłabić ^[4]. Forward secrecy nie zastępuje więc rotacji kluczy ani ochrony klucza prywatnego.

Jak się bronić

Właściciel strony nie włącza forward secrecy jednym przełącznikiem. Może natomiast wymagać od serwera albo od dostawcy hostingu konfiguracji, która ją zapewnia.

• Dopuścić wyłącznie TLS 1.2 i TLS 1.3, a wyłączyć SSL 2.0, SSL 3.0, TLS 1.0 i TLS 1.1 ^[7].
• W TLS 1.2 preferować zestawy z wymianą ECDHE albo DHE i nie negocjować statycznej wymiany RSA ^[2].
• Wyłączyć szyfry RC4 i 3DES, szyfry eksportowe oraz zestawy NULL i aNULL, a stosować m.in. AES-GCM i ChaCha20-Poly1305 ^[7].
• Nie używać zbyt krótkich parametrów wymiany Diffiego-Hellmana ^[7].
• Trzymać klucz prywatny certyfikatu wyłącznie na serwerze, który go używa ^[7].

Historia i przykłady

Najczęściej przywoływanym przykładem jest błąd Heartbleed w OpenSSL, oznaczony CVE-2014-0160 i ujawniony 7 kwietnia 2014 roku ^[4]. Podatne były wersje od 1.0.1 do 1.0.1f, a poprawkę przyniosła wersja 1.0.1g ^[4]. Błąd pozwalał odczytywać pamięć serwera, w tym klucze prywatne certyfikatów ^[5]. Autorzy opisu podkreślali, że wykradzione klucze pozwalają odszyfrować przeszły i przyszły ruch chronionych usług ^[4]. Forward secrecy powinna chronić przeszłą komunikację przed takim odszyfrowaniem, ale w 2014 roku była rzadko włączona ^[4].

Sekurak w artykule o Heartbleed przytaczał definicję forward secrecy i podawał, że OpenSSL wspierał mechanizmy PFS od wersji 1.0 ^[5]. Według tego samego tekstu w kwietniu 2014 roku tylko 6,3% witryn z TLS używało zestawów szyfrów z forward secrecy wobec przeglądarek ^[5]. Kolejne standardy zmieniły ten stan: RFC 9325 z 2022 roku wymaga, by implementacje obsługiwały i preferowały zestawy z forward secrecy ^[2], a TLS 1.3 w ogóle nie ma już statycznej wymiany RSA ^[1].