HSTS (HTTP Strict Transport Security)

HSTS (HTTP Strict Transport Security) to mechanizm, przez który witryna deklaruje, że jest dostępna wyłącznie przez bezpieczne połączenia ^[1]. Serwer wysyła nagłówek odpowiedzi Strict-Transport-Security, a przeglądarka przez wskazany czas zamienia każdą próbę połączenia po HTTP na HTTPS, zanim wyśle żądanie ^[2]. CERT Polska opisuje HSTS jako nagłówek HTTP, którym serwer informuje przeglądarkę, że z domeną wolno łączyć się wyłącznie z wykorzystaniem HTTPS ^[4]. Mechanizm uzupełnia TLS: szyfrowanie działa tylko wtedy, gdy przeglądarka w ogóle z niego korzysta.

Jak działa

Przy pierwszej wizycie po HTTPS serwer dołącza do odpowiedzi nagłówek z czasem ważności. Przeglądarka zapamiętuje domenę jako hosta HSTS i odtąd nie wysyła do niej niezaszyfrowanych żądań ^[2]. Nagłówek nie wpływa na bieżącą odpowiedź, tylko na kolejne żądania ^[2].

Specyfikacja nakazuje przeglądarce ignorować nagłówek otrzymany przez niezaszyfrowane połączenie, żeby atakujący w sieci nie mógł wstrzyknąć fałszywej polityki ^[1]. Drugą ważną regułą jest twarda reakcja na błąd certyfikatu: przy nieudanej weryfikacji połączenie zostaje przerwane, a użytkownik nie ma możliwości kliknięcia „przejdź mimo to” ^[1].

RYS. 1HSTS przy kolejnej wizycie

Typowy zapis nagłówka podaje zarówno CERT Polska, jak i MDN ^{[4] [2]}:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Składniki

Nagłówek ma jedną dyrektywę obowiązkową i dwie opcjonalne.

Wartość 31536000 sekund to rok. MDN jako wariant do listy preload podaje dwa lata, czyli 63072000 sekund ^[2].

W WordPressie

WordPress przechowuje dwa adresy: adres witryny i adres WordPressa. Od wersji 5.7 funkcja wp_is_using_https() zwraca prawdę, gdy oba używają HTTPS, a ekran Zdrowie witryny ma przycisk przełączający oba adresy jednym kliknięciem ^[7]. Ta sama wersja dodała funkcję zamieniającą w treściach zapisane na sztywno adresy HTTP, żeby uniknąć ostrzeżeń mixed content ^[7]. Stała FORCE_SSL_ADMIN ustawiona w pliku wp-config.php wymusza logowanie i sesje panelu przez SSL ^[6].

Żaden z tych mechanizmów nie jest nagłówkiem HSTS. Przekierowanie z HTTP na HTTPS wykonuje serwer, a przed przekierowaniem przeglądarka i tak wysyła pierwsze żądanie otwartym tekstem. Nagłówek Strict-Transport-Security ustawia się zwykle w konfiguracji serwera WWW, w pliku .htaccess, w panelu hostingu albo na reverse proxy lub CDN stojącym przed stroną. MDN zaleca kolejność: na żądanie HTTP odpowiedzieć stałym przekierowaniem 301 na adres HTTPS bez nagłówka HSTS, a nagłówek wysłać dopiero w odpowiedzi szyfrowanej ^[2].

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Zagrożenia i skutki

Bez HSTS atakujący w tej samej sieci może przeprowadzić atak man-in-the-middle (MITM). Sekurak opisuje, jak narzędzia typu SSLStrip zmuszają przeglądarkę do komunikacji czystym tekstem, podczas gdy połączenie atakującego z serwerem pozostaje szyfrowane ^[5]. Szczególnie narażeni są użytkownicy publicznych sieci Wi-Fi. Ofiara nie widzi błędu, a atakujący może przechwycić hasło do panelu albo token sesyjny.

HSTS ma też słabość wpisaną w konstrukcję: nie chroni pierwszego połączenia, bo przeglądarka jeszcze nie zna polityki ^[2]. Sekurak zwrócił na to uwagę już w 2013 roku ^[5]. RFC 6797 jako odpowiedź wskazuje listy hostów wbudowane w przeglądarki ^[1].

Twarda reakcja na błąd certyfikatu jest celowa. RFC 6797 odbiera użytkownikowi możliwość zignorowania ostrzeżenia, bo klikanie w takie ostrzeżenia było jedną z głównych dróg ataku ^[1]. Ma to jednak drugą stronę: błędna konfiguracja może odciąć dostęp do strony. Jeśli certyfikat wygaśnie, przeglądarka nie pozwoli ominąć ostrzeżenia ^[1]. Z includeSubDomains przestają działać subdomeny bez HTTPS, na przykład stary panel pod adresem po HTTP.

Jak się bronić

• Najpierw zapewnić ważny certyfikat SSL/TLS dla domeny i wszystkich subdomen, a dopiero potem włączyć HSTS.
• Zaczynać od krótkiego max-age i wydłużać go po sprawdzeniu, że strona działa.
• Dopuszczać wyłącznie TLS 1.2 i TLS 1.3 oraz wyłączyć SSL 2.0, SSL 3.0, TLS 1.0 i TLS 1.1, jak zaleca CERT Polska ^[4]. Te same zalecenia wskazują silne szyfry, takie jak AES-GCM i ChaCha20-Poly1305, oraz wyłączenie RC4 i 3DES ^[4].
• Przy wycofywaniu HSTS wysłać nagłówek z max-age=0. Działa to tylko w odpowiedzi po HTTPS ^[2], więc certyfikat musi pozostać ważny, dopóki przeglądarki nie odbiorą nowej wartości.
• Rozważyć listę preload. Wymaga ona ważnego certyfikatu, przekierowania z HTTP na HTTPS na tym samym hoście, HTTPS na wszystkich subdomenach oraz nagłówka z max-age co najmniej roku, includeSubDomains i preload ^[3].
• Traktować HSTS jako część nagłówków bezpieczeństwa HTTP. Dyrektywa upgrade-insecure-requests z CSP nie zastępuje HSTS.

Historia i przykłady

Specyfikację HSTS opublikowano w listopadzie 2012 roku jako RFC 6797 ze statusem Proposed Standard; autorami są J. Hodges, C. Jackson i A. Barth ^[1]. Listę preload prowadzi usługa hstspreload.org, z której według MDN korzystają wszystkie główne przeglądarki ^[2]. Serwis ostrzega, że wpisu nie da się łatwo cofnąć: usunięcie trafia do użytkowników Chrome dopiero po miesiącach, wraz z aktualizacją przeglądarki ^[3]. Wpis obejmuje wszystkie subdomeny, także wewnętrzne, niedostępne publicznie ^[3].