Co to jest nagłówek HSTS i jak go poprawnie skonfigurować?

Nagłówek HSTS (HTTP Strict Transport Security) to mechanizm bezpieczeństwa wymuszający na przeglądarkach internetowych łączenie się z witryną wyłącznie za pośrednictwem szyfrowanego protokołu HTTPS, ignorując całkowicie próby nawiązania nieszyfrowanego połączenia HTTP. Żeby go poprawnie skonfigurować, należy dodać do odpowiedzi serwera dyrektywę Strict-Transport-Security z odpowiednio długim czasem obowiązywania (np. max-age=31536000), opcjonalnie obejmując nią wszystkie subdomeny za pomocą parametru includeSubDomains.

Wielu administratorów myśli, że wdrożenie certyfikatu SSL i ustawienie prostego przekierowania na serwerze załatwia sprawę. To bzdura. W zdecydowanej większości przypadków ataki typu man-in-the-middle bazują na pierwszej, całkowicie nieszyfrowanej fazie kontaktu użytkownika z serwerem. Zanim przeglądarka otrzyma instrukcję zmiany protokołu, atakujący zdąży przejąć sesję. HSTS zamyka tę lukę definitywnie.

Dlaczego samo przekierowanie 301 na HTTPS to za mało?

Zwykłe przekierowanie 301 działa na zasadzie reakcji. Użytkownik wpisuje w pasek adresu nazwę domeny. Przeglądarka domyślnie wysyła żądanie po porcie 80 (HTTP). Serwer odbiera ten sygnał i odpowiada kodem 301 Moved Permanently, wskazując nowy adres zaczynający się od HTTPS. Przeglądarka posłusznie wykonuje drugie żądanie, tym razem po porcie 443. Problem polega na tym, że to pierwsze, ułamkowe zapytanie leci przez sieć jawnym tekstem. To wystarczy.

Narzędzia takie jak sslstrip, stworzone lata temu przez Moxiego Marlinspike’a, żerują dokładnie na tym pojedynczym żądaniu. Atakujący, znajdujący się w tej samej sieci Wi-Fi co ofiara (np. w kawiarni), przechwytuje zapytanie HTTP. Zamiast pozwolić mu dotrzeć do serwera docelowego, sam nawiązuje bezpieczne połączenie HTTPS z bankiem lub sklepem. Ofierze natomiast serwuje z powrotem stronę po zwykłym HTTP, podmieniając wszystkie linki w kodzie HTML na nieszyfrowane. Użytkownik loguje się, podaje hasło, a haker czyta wszystko jak z otwartej książki. Serwer widzi z kolei w pełni szyfrowany ruch i nie protestuje.

HSTS eliminuje ten wektor ataku z poziomu samej przeglądarki. Kiedy mechanizm HTTP Strict Transport Security jest aktywny, program (Chrome, Firefox, Safari) zapisuje w swojej wewnętrznej bazie informację: „Z tą konkretną domeną wolno mi rozmawiać tylko i wyłącznie przez HTTPS”. Kiedy użytkownik następnym razem wpisze adres bez przedrostka, przeglądarka w ogóle nie wyśle żądania HTTP. Sama, lokalnie na urządzeniu, zmieni URL na szyfrowany i od razu uderzy na port 443. Brak pierwszego jawnego zapytania oznacza brak możliwości jego przechwycenia.

Jak dokładnie działa mechanizm HTTP Strict Transport Security w przeglądarce?

Zasada działania opiera się na pamięci podręcznej polityk bezpieczeństwa, która jest wbudowana w silnik renderujący. Przeglądarka musi chociaż raz wejść na stronę po bezpiecznym protokole i otrzymać w nagłówku odpowiedzi HTTP odpowiednią instrukcję od serwera. Od tego momentu włącza się zegar odliczający czas określony w dyrektywie. Z każdym kolejnym wejściem użytkownika na stronę, ten zegar ulega resetowi do wartości maksymalnej. To mechanizm odnawialny.

Co się stanie, jeśli atakujący spróbuje zablokować ruch HTTPS lub podsunie fałszywy, samopodpisany certyfikat SSL osobie, która ma już zapamiętaną politykę HSTS dla danej domeny? Przeglądarka wyświetli twardy błąd prywatności. Nie będzie tam przycisku „Zignoruj ostrzeżenie i przejdź na stronę”. Czerwony ekran zablokuje dostęp całkowicie. To celowe i brutalne rozwiązanie. Albo połączenie jest kryptograficznie nienaruszone, albo użytkownik nie zobaczy ani linijki kodu HTML.

Chociaż prawdę mówiąc brakuje nam twardych danych na temat zachowania użytkowników w obliczu takich komunikatów na rynkach niszowych, to z perspektywy bezpieczeństwa infrastruktury korporacyjnej nie ma lepszej blokady. Użytkownik nie ma prawa decydować o ignorowaniu błędów certyfikatu. Decyzję podejmuje polityka serwera.

Jakie dyrektywy zawiera nagłówek HSTS i co oznaczają w praktyce?

Nagłówek Strict-Transport-Security przyjmuje bardzo określoną składnię. Składa się z jednej dyrektywy obowiązkowej i dwóch opcjonalnych. Ich poprawne zrozumienie to warunek uniknięcia potężnej awarii na produkcji.

• max-age – To parametr obligatoryjny. Określa czas (w sekundach), przez jaki przeglądarka ma trzymać domenę w swojej bazie wymuszonych połączeń szyfrowanych. Wartość max-age=31536000 oznacza dokładnie jeden rok. Jeśli podasz tu zero (max-age=0), przeglądarka natychmiast usunie politykę HSTS dla tej witryny, pozwalając ponownie na ruch nieszyfrowany.
• includeSubDomains – Parametr opcjonalny, ale wysoce zalecany. Mówi przeglądarce, że zasada wymuszonego szyfrowania dotyczy nie tylko głównej domeny, ale absolutnie wszystkich jej subdomen obecnych i przyszłych. Zastosowanie tego wymusza posiadanie poprawnego certyfikatu SSL na każdym testowym środowisku w danej przestrzeni nazw. W przeciwnym razie odetniesz sobie do nich dostęp.
• preload – Flaga, która wyraża zgodę administratora na wpisanie domeny na globalną listę HSTS Preload wbudowaną bezpośrednio w kod źródłowy przeglądarek na etapie ich kompilacji. Zabezpiecza to użytkowników nawet przy ich pierwszej, historycznej wizycie na twojej stronie.
• Wpływ na ciasteczka – Zastosowanie HSTS sprawia, że kradzież ciasteczek sesyjnych bez flagi Secure staje się znacznie trudniejsza, ponieważ przeglądarka odmawia transmisji jakichkolwiek danych poza tunelem TLS.

Zrobiliśmy na wdrożeniu sklepu wymuszenie HSTS z includeSubDomains i natychmiastowym dodaniem flagi preload. Zapomnieliśmy, że stary blog na subdomenie blog.firma.pl działał na wygasłym certyfikacie, a serwer poczty webmail wymagał od pracowników logowania po dziwnym, niestandardowym porcie bez SSL. O trzeciej nad ranem telefony od zarządu rozgrzały się do czerwoności. Prawda jest zresztą absolutnie taka, że nikt nie czyta dokumentacji do końca, dopóki strona nie wywali błędu prywatności na twarz. Pół firmy straciło dostęp do narzędzi pracy z powodu głupiego błędu w składni jednego nagłówka.

Jak poprawnie skonfigurować HSTS na serwerze Nginx?

Wdrożenie na serwerze Nginx jest bezpośrednie. Wymaga edycji bloku server obsługującego ruch na porcie 443. Zmian dokonujemy w pliku konfiguracyjnym konkretnego vhosta lub w głównym pliku nginx.conf.

Otwórz konfigurację. Znajdź sekcję odpowiedzialną za SSL. Dopisz jedną linijkę:

server {
    listen 443 ssl;
    server_name twojadomena.pl;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # Reszta konfiguracji SSL i ścieżek
}

Słowo always na końcu tej dyrektywy odgrywa rolę decydującą. Nginx domyślnie dodaje nagłówki zdefiniowane przez add_header tylko do odpowiedzi z kodami HTTP 200, 201, 204, 206, 301, 302, 303, 304, 307. Jeśli twoja aplikacja zwróci błąd 404 lub 500, a nie użyjesz parametru always, nagłówek HSTS w ogóle nie zostanie wysłany do klienta. Atakujący mógłby celowo wywołać błąd serwera, by ominąć przesyłanie polityki bezpieczeństwa. Przeładuj konfigurację poleceniem nginx -s reload po zapisaniu zmian.

Jak włączyć HSTS w Apache za pomocą pliku .htaccess?

Serwer Apache pozwala na manipulację nagłówkami za pomocą modułu mod_headers. Zanim zaczniesz modyfikować plik .htaccess, musisz upewnić się, że ten moduł jest aktywny w systemie operacyjnym. Na dystrybucjach opartych o Debiana/Ubuntu zrobisz to komendą a2enmod headers, po czym musisz zrestartować usługę.

Kiedy moduł działa, edytuj plik .htaccess znajdujący się w głównym katalogu twojej aplikacji webowej (public_html lub var/www/html). Dodaj poniższy kod:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
</IfModule>

Warunek env=HTTPS zabezpiecza przed wysyłaniem nagłówka HSTS w odpowiedziach na zapytania nieszyfrowane. Zgodnie z oficjalną specyfikacją RFC 6797, serwery nie powinny dołączać tego nagłówka, jeśli połączenie odbywa się po czystym HTTP. Przeglądarki i tak ignorują dyrektywę Strict-Transport-Security odebraną jawnym kanałem, żeby zapobiec atakom polegającym na złośliwym wymuszaniu HSTS dla domen, które w ogóle nie posiadają certyfikatów SSL (tzw. atak denial of service przez HSTS).

Czy wdrożenie HSTS w systemie Windows Server IIS wymaga dodatkowych modułów?

W środowisku Microsoft IIS konfiguracja wygląda inaczej. Od wersji IIS 10 (Windows Server 2016 i nowsze) obsługa HSTS jest wbudowana natywnie w menedżer usług internetowych. Nie musisz grzebać w plikach konfiguracyjnych ręcznie, choć możesz to zrobić z poziomu web.config.

Aby zrobić to przez interfejs graficzny, wybierz swoją witrynę w drzewie połączeń Menedżera IIS. W panelu akcji po prawej stronie znajdź opcję „HSTS…”. Zaznacz pole wyboru „Włącz”, wpisz maksymalny wiek (Max-Age) i opcjonalnie zaznacz pola obejmujące subdomeny. Kliknij OK. System sam odpowiednio zmodyfikuje odpowiedź serwera.

Jeśli wolisz lub musisz operować na pliku web.config w starszych wersjach (gdzie używa się modułu URL Rewrite), składnia wygląda następująco:

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Zwróć uwagę na to, by przetestować zachowanie aplikacji .NET po wdrożeniu. Niektóre starsze systemy intranetowe oparte o autoryzację Windows mogą gubić sesje, jeśli ruch zostanie nagle brutalnie przecięty przez wymuszenie tunelu TLS na poziomie przeglądarki klienta, a load balancer przed serwerem IIS nie obsługuje poprawnie nagłówków X-Forwarded-Proto.

Czym jest lista HSTS Preload i jak dopisać do niej swoją domenę?

Nawet z włączonym nagłówkiem HSTS istnieje jedno, początkowe okno podatności. Kiedy użytkownik wchodzi na twoją stronę absolutnie pierwszy raz w życiu po zakupie nowego laptopa lub instalacji nowej przeglądarki, jego lokalna baza HSTS jest pusta. To pierwsze żądanie może zostać przechwycone.

Żeby zamknąć tę ostatnią lukę, społeczność skupiona wokół Google Chrome stworzyła projekt HSTS Preload List. Jest to zakodowana na sztywno, gigantyczna lista domen, która jest kompilowana bezpośrednio w kodzie źródłowym przeglądarek Chrome, Firefox, Safari i Edge. Jeśli twoja domena znajduje się na tej liście, przeglądarka nigdy nie wyśle do niej zapytania HTTP, nawet podczas tej historycznej, pierwszej wizyty użytkownika.

Wpisanie się na tę listę wymaga spełnienia twardych warunków na stronie hstspreload.org. Musisz zaserwować nagłówek HSTS na głównej domenie. Parametr max-age musi wynosić minimum 31536000 sekund. Musisz dołączyć dyrektywę includeSubDomains. Musisz dołączyć dyrektywę preload. Dodatkowo musisz obsługiwać wszystkie przekierowania z HTTP na HTTPS po tej samej nazwie hosta, zanim przekierujesz ruch gdziekolwiek indziej.

Jeśli wpiszesz tam domenę, a potem zrezygnujesz z SSL, uceglisz sobie biznes na długie miesiące. Usunięcie domeny z listy preload wymaga zgłoszenia prośby o usunięcie, a następnie czekania na kolejny cykl wydawniczy wszystkich głównych przeglądarek na rynku. Może to potrwać od 3 do 6 miesięcy. W tym czasie nikt nie wejdzie na twoją stronę nieszyfrowaną. Ani jeden klient. Dlatego ta decyzja musi być przemyślana i poparta stabilną infrastrukturą klucza publicznego.

Jakie błędy najczęściej popełniamy przy wdrażaniu HSTS na produkcji?

Administratorzy notorycznie wdrażają maksymalny czas trwania polityki (rok lub dwa lata) już w pierwszej minucie testów. To proszenie się o kłopoty. Prawidłowy proces wdrożenia powinien opierać się na stopniowym skalowaniu wartości max-age.

Tabela poniżej pokazuje bezpieczny harmonogram wdrażania HSTS dla dużych projektów e-commerce.

Kolejnym potknięciem jest brak zrozumienia, jak nagłówki zachowują się za systemami CDN (Content Delivery Network). Włączając HSTS w panelu Cloudflare, nadpisujesz nagłówki wysyłane z twojego serwera źródłowego (origin). Czasami prowadzi to do podwójnego serwowania dyrektywy Strict-Transport-Security w jednym żądaniu, co sprawia, że niektóre restrykcyjne parsery przeglądarek uznają odpowiedź za uszkodzoną i odrzucają politykę w całości. Ustal jedno miejsce emisji nagłówka. Albo serwer WWW, albo warstwa brzegowa (Edge).

Jak usunąć HSTS z przeglądarki podczas awarii certyfikatu SSL?

Kiedy środowisko testowe ulegnie awarii i przeglądarka zablokuje ci dostęp z komunikatem ERR_CERT_AUTHORITY_INVALID na domenie objętej HSTS, jesteś odcięty. Nie ominiesz tego błędu standardowymi metodami.

Żeby wejść na stronę, musisz wyczyścić pamięć polityk bezpieczeństwa w swojej lokalnej przeglądarce. W Google Chrome i innych przeglądarkach opartych na silniku Chromium (Edge, Brave, Opera) wpisz w pasek adresu ukrytą komendę: chrome://net-internals/#hsts.

Zjedź na sam dół strony do sekcji „Delete domain security policies”. Wpisz nazwę swojej zablokowanej domeny w pole tekstowe i kliknij przycisk „Delete”. Następnie upewnij się, że operacja się powiodła, wpisując tę samą domenę wyżej w sekcji „Query HSTS/PKP domain” i klikając „Query”. Jeśli system zwróci wynik „Not found”, z powodzeniem usunąłeś politykę ze swojego komputera. Możesz teraz wejść na stronę i w mgnieniu oka naprawić problem z certyfikatem lub obniżyć wartość max-age do zera w konfiguracji serwera.

W przeglądarce Firefox musisz użyć zupełnie innej ścieżki. Zamknij wszystkie otwarte karty z zepsutą stroną. Otwórz menedżer historii (skrót Ctrl+Shift+H). Odszukaj swoją stronę na liście odwiedzonych witryn. Kliknij na nią prawym przyciskiem myszy i wybierz opcję „Zapomnij o tej witrynie” (Forget about this site). Ta operacja wyczyści nie tylko historię i ciasteczka, ale również zapisaną lokalnie flagę HSTS.

Jaki wpływ ma HSTS na pozycjonowanie stron i bezpieczeństwo techniczne SEO?

Z punktu widzenia widoczności w wyszukiwarkach, wdrożenie Strict-Transport-Security to silny sygnał jakościowy. Google oficjalnie traktuje protokół HTTPS jako czynnik rankingowy od 2014 roku. Sama obecność SSL to dziś standard absolutny. Natomiast poprawne wdrożenie HSTS daje algorytmom wyszukiwarki do zrozumienia, że infrastruktura jest zarządzana z dbałością o detale i bezpieczeństwo danych.

Główna zaleta SEO polega na redukcji łańcuchów przekierowań. Kiedy linkujesz do swojej strony zewnętrznie (np. w kampaniach PR lub w starych artykułach) z użyciem formatu http://, boty indeksujące i zwykli użytkownicy muszą przejść przez fizyczne przekierowanie 301 na serwerze. Dodaje to kilkadziesiąt do kilkuset milisekund opóźnienia do czasu pierwszego bajtu (TTFB – Time to First Byte). Szybkość ładowania jest bezpośrednim wskaźnikiem Core Web Vitals oceniającym wydajność strony.

Gdy domena figuruje na liście HSTS Preload, roboty Googlebota i przeglądarki klientów od razu, w ułamku sekundy, kierują żądanie na protokół HTTPS bez pytania serwera o zdanie. Oszczędzamy całą jedną podróż pakietów sieciowych (round trip) na zestawieniu połączenia. W skali milionów odsłon miesięcznie zdejmuje to odczuwalne obciążenie z maszyn obsługujących front-end aplikacji webowej. Odzyskujesz cykle procesora i skracasz czas oczekiwania klienta na wygenerowanie widoku.

Upewnij się tylko, że w pliku sitemap.xml oraz we wszystkich tagach rel=”canonical” podajesz adresy z przedrostkiem https://. Błędem nowicjuszy jest wymuszenie HSTS na poziomie serwera, pozostawiając w kodzie źródłowym linkowanie wewnętrzne kierujące do zasobów po nieszyfrowanym HTTP. Przeglądarka i tak zablokuje takie żądania (znane jako Mixed Content) lub naprawi je w locie uderzając w SSL, ale powoduje to niepotrzebny chaos strukturalny podczas analizy crawlerami SEO. Architektura informacji musi być spójna ze stanem serwera.

Zmieniając te zasady na robocie, zlikwidowaliśmy problem powracających zjawisk duplikacji treści, gdzie systemy indeksujące gubiły się pomiędzy wersjami portalu. Koniec z indeksowaniem pustych błędów certyfikatów.

Teraz zaloguj się na swój serwer. Sprawdź nagłówki odpowiedzi, używając konsoli deweloperskiej lub polecenia curl. Jeśli nie widzisz tam dyrektywy Strict-Transport-Security, po prostu tracisz czas i wystawiasz użytkowników na strzał w każdej publicznej sieci Wi-Fi. Zrób to dzisiaj.

Najczęściej zadawane pytania (FAQ)

Bibliografia

1. Mozilla Developer Network – https://developer.mozilla.org
2. NGINX Documentation – https://nginx.org
3. Apache HTTP Server Project – https://httpd.apache.org
4. HSTS Preload List Submission – https://hstspreload.org
5. Internet Engineering Task Force – https://ietf.org