Jak skonfigurować HSTS, żeby nie odciąć sobie dostępu

HSTS jest prosty, dopóki przestaje taki być

HTTP Strict Transport Security, zwykle skracane do HSTS, mówi przeglądarkom: „dla tej witryny zawsze używaj HTTPS”. Gdy przeglądarka otrzyma ten nagłówek przez poprawne połączenie HTTPS, zapamiętuje regułę na określony przez ciebie czas.

To przydatne. Zapobiega atakom polegającym na obniżeniu wersji protokołu, ogranicza przypadkowe niezabezpieczone żądania i eliminuje niezręczny moment, w którym użytkownik wpisuje example.com i na chwilę trafia na zwykły HTTP, zanim zostanie przekierowany.

Jest też uporczywe. Jeśli opublikujesz niewłaściwą politykę HSTS, przeglądarki mogą egzekwować ją długo po tym, jak usuniesz nagłówek ze swojego serwera. W ten sposób zespoły odcinają sobie dostęp: nie dokładnie do własnego panelu administracyjnego, lecz do przeglądarek użytkowników, subdomen, środowisk stagingowych, starszych endpointów i zapomnianych usług, które nie są gotowe na wymuszone HTTPS.

Celem nie jest unikanie HSTS. Celem jest wdrożenie go jak migracji, a nie jak przełącznika.

Co naprawdę robi nagłówek HSTS

Typowy nagłówek HSTS wygląda tak:

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

Ma trzy ważne części:

• max-age: jak długo, w sekundach, przeglądarka ma wymuszać HTTPS dla tego hosta.
• includeSubDomains: czy reguła obejmuje też każdą subdomenę.
• preload: sygnał, że chcesz dodać domenę do list preload w przeglądarkach.

Przeglądarka ufa temu nagłówkowi tylko wtedy, gdy otrzyma go przez poprawne HTTPS. Jeśli certyfikat jest nieprawidłowy, wygasły albo nie pasuje do hosta, przeglądarka nie powinna zaakceptować nowej polityki HSTS z takiej odpowiedzi.

Gdy polityka zostanie zapisana, przyszłe próby odwiedzenia http://example.com są podnoszone przez przeglądarkę do https://example.com, zanim żądanie zostanie wysłane. To jest korzyść dla prywatności: niezabezpieczone żądanie nigdy nie opuszcza urządzenia.

Scenariusze odcięcia dostępu, których należy unikać

Większość awarii HSTS nie wynika z głównej witryny. Dzieją się na obrzeżach.

1. Zapomniana subdomena nie jest gotowa na HTTPS

includeSubDomains brzmi porządnie, ale działa bezwzględnie. Jeśli ustawisz je na example.com, obejmie:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• wszystko inne pod tą domeną

Jeśli którykolwiek z tych hostów nie potrafi serwować poprawnego HTTPS, użytkownicy z zapisaną polityką HSTS nie będą mogli dotrzeć do niego przez HTTP.

2. Certyfikat wygasa

Bez HSTS użytkownicy czasem przechodzą przez ostrzeżenia o certyfikacie. To nie jest dobra praktyka bezpieczeństwa, ale się zdarza.

Z HSTS nowoczesne przeglądarki nie pozwalają łatwo obejść błędów certyfikatu dla danego hosta. O to właśnie chodzi. Oznacza to też, że odnawianie certyfikatów musi być nudne, monitorowane i testowane.

3. Narzędzia stagingowe lub wewnętrzne działają pod domeną produkcyjną

Umieszczanie narzędzi wewnętrznych pod *.example.com może stać się bolesne, gdy domena nadrzędna używa includeSubDomains. Jeśli te narzędzia korzystają z certyfikatów self-signed, prywatnych urzędów certyfikacji, starych konfiguracji TLS albo w ogóle nie mają HTTPS, HSTS ujawni ten skrót.

To jeden z powodów, dla których wiele zespołów trzyma systemy wewnętrzne i eksperymentalne pod osobną domeną z własną polityką bezpieczeństwa.

4. Preload jest traktowany jak rutynowy checkbox

HSTS preload to nie jest po prostu kolejna dyrektywa. Oznacza, że twoja domena może zostać dostarczona w przeglądarkach jako dostępna wyłącznie przez HTTPS, zanim jakikolwiek użytkownik odwiedzi twoją witrynę.

Zamyka to lukę „pierwszej wizyty”, ale znacznie trudniej to odwrócić. Usunięcie z list preload może zająć tygodnie albo miesiące, zanim dotrze do użytkowników, zależnie od cykli wydawniczych przeglądarek. Preload jest właściwy dla stabilnych, dojrzałych domen. Nie jest właściwy dla witryny, która dopiero odkrywa swój spis subdomen.

Bezpieczny plan wdrożenia

Krok 1: Skontroluj każdy hostname, którym zarządzasz

Zanim ustawisz includeSubDomains, wypisz każdy hostname pod daną domeną. Rekordy DNS to początek, ale nie cała historia. Sprawdź konfiguracje CDN, panele hostingowe, hostname’y związane z pocztą, stare narzędzia marketingowe, buckety storage i dokumentację wewnętrzną.

Dla każdego hostname’u odpowiedz:

• Czy obsługuje HTTP, HTTPS, czy oba?
• Czy certyfikat HTTPS jest poprawny i odnawiany automatycznie?
• Czy HTTP przekierowuje do HTTPS w czysty sposób?
• Czy ma być publiczny?
• Czy nadal jest potrzebny?

Jeśli twój zespół ma już produkcyjne nawyki debugowania nagłówków, to naturalnie pasuje obok kontroli przekierowań i nagłówków. Opisaliśmy ten workflow w małym zestawie narzędzi do debugowania przekierowań i nagłówków HTTP na produkcji.

Krok 2: Napraw HTTPS przed dodaniem HSTS

HSTS nie sprawia, że zepsuta konfiguracja HTTPS staje się bezpieczna. Sprawia tylko, że HTTPS jest obowiązkowe.

Przed włączeniem sprawdź:

• Certyfikaty TLS obejmują właściwe hostname’y.
• Certyfikaty odnawiają się automatycznie.
• HTTP przekierowuje do HTTPS jednym czystym skokiem, gdy to możliwe.
• Przekierowania kanonicznego hosta są spójne, na przykład z wersji bez www na www albo odwrotnie.
• Zasoby aplikacji nie zależą od niezabezpieczonych URL-i http://.

Mixed content jest dziś rzadszy niż kiedyś, ale nadal pojawia się w starych motywach CMS, snippetach analitycznych, osadzonych mediach i wpisanych na sztywno ścieżkach obrazów.

Krok 3: Zacznij od bardzo krótkiego max-age

Nie zaczynaj od jednego roku. Zacznij od pięciu minut:

Strict-Transport-Security: max-age=300

Wdróż to tylko na testowanym hostname, zwykle na kanonicznej witrynie produkcyjnej. Na razie pomiń includeSubDomains.

Następnie testuj w prawdziwych przeglądarkach i za pomocą żądań z wiersza poleceń:

curl -I https://example.com

Powinien pojawić się dokładnie jeden nagłówek Strict-Transport-Security. Zduplikowane nagłówki HSTS z serwera aplikacji i CDN są częstym źródłem zamieszania. Przeglądarki zwykle stosują efektywną politykę, ale ludzie debugujący incydent nie potrzebują niejednoznaczności.

Krok 4: Zwiększaj stopniowo

Jeśli nic się nie psuje, zwiększaj czas etapami:

Strict-Transport-Security: max-age=86400

Potem:

Strict-Transport-Security: max-age=604800

A następnie być może:

Strict-Transport-Security: max-age=2592000

Praktyczny harmonogram to:

• 5 minut
• 1 dzień
• 1 tydzień
• 1 miesiąc
• 6 miesięcy albo 1 rok

Nie ma nagrody za pośpiech. Cały sens etapowego wdrożenia polega na tym, by dać monitoringowi, skrzynce supportu i przypadkom brzegowym czas na pokazanie, czego zabrakło na liście kontrolnej.

Krok 5: Dodaj includeSubDomains dopiero po realnym audycie

Gdy każda publiczna subdomena jest gotowa na HTTPS, możesz rozważyć:

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

To moment, w którym warto być konserwatywnym. Jeśli jedna starsza usługa nadal potrzebuje HTTP, nie dodawaj includeSubDomains do domeny nadrzędnej. Albo zmigruj tę usługę, albo przenieś ją do innej domeny, albo zaakceptuj, że twoja polityka HSTS musi na razie pozostać węższa.

Nagłówki bezpieczeństwa powinny odzwierciedlać rzeczywistość. Nie należy używać ich jako plakatów motywacyjnych dla infrastruktury, którą masz nadzieję mieć później.

Krok 6: Traktuj preload jako osobny projekt

Rozważ preload tylko wtedy, gdy wszystkie poniższe warunki są spełnione:

• Domena i wszystkie subdomeny obsługują poprawne HTTPS.
• HTTP przekierowuje do HTTPS.
• Nagłówek HSTS używa max-age co najmniej 31536000 sekund.
• Nagłówek zawiera includeSubDomains.
• Nagłówek zawiera preload.
• Masz pewność, że nigdzie pod tą domeną nie będzie potrzebny zwykły HTTP.

Nagłówek gotowy na preload wygląda tak:

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

Zgłoszenie do listy preload to długoterminowe zobowiązanie. Jeśli witryna jest mikrowitryną kampanii, tymczasową domeną produktu albo domeną o niejasnych granicach własności, pomiń to.

Przykłady konfiguracji

Nginx

Użyj always, aby nagłówek był wysyłany także w odpowiedziach błędów:

add_header Strict-Transport-Security "max-age=300" always;

Gdy wdrożenie będzie stabilne:

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

Apache

Przy włączonym mod_headers:

Header always set Strict-Transport-Security "max-age=300"

Później:

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

CDN albo platforma edge

Jeśli twój CDN ustawia nagłówki odpowiedzi, najlepiej zarządzaj HSTS w jednym miejscu. Nie ustawiaj jednej polityki na originie, a innej na brzegu sieci, chyba że masz bardzo jasny powód.

Sprawdź też, czy CDN stosuje nagłówki do przekierowań, błędów z cache i niestandardowych stron błędów. Witryna produkcyjna to nie tylko jej odpowiedź 200 OK.

Jak bezpiecznie wycofać HSTS

Jeśli musisz wyłączyć HSTS, wyślij:

Strict-Transport-Security: max-age=0

Jest jednak haczyk: przeglądarka musi skutecznie dotrzeć do witryny przez poprawne HTTPS, aby otrzymać ten nagłówek. Jeśli samo HTTPS jest zepsute, użytkownicy z zapisaną polityką HSTS nie mogą pobrać instrukcji, która by ją wyczyściła.

Dlatego typowa kolejność odzyskiwania wygląda tak:

1. Przywróć poprawne HTTPS.
2. Serwuj Strict-Transport-Security: max-age=0.
3. Utrzymaj to wystarczająco długo, aby powracający użytkownicy mogli to otrzymać.
4. Usuń albo zastąp nagłówek po rozwiązaniu incydentu.

Jeśli domena jest w preload, serwowanie max-age=0 nie wystarczy dla nowych profili przeglądarek. Musisz też poprosić o usunięcie z listy preload i poczekać, aż zmiana trafi do użytkowników przez aktualizacje przeglądarek.

Lista kontrolna przed wdrożeniem

Użyj tej listy przed zwiększeniem max-age albo dodaniem includeSubDomains:

• Kanoniczny URL HTTPS zwraca poprawny certyfikat.
• HTTP przekierowuje do HTTPS.
• Istnieje tylko jeden nagłówek HSTS.
• Nagłówek pojawia się na przekierowaniach i odpowiedziach błędów tam, gdzie to właściwe.
• Wszystkie publiczne subdomeny mają poprawne HTTPS.
• Odnawianie certyfikatów jest monitorowane.
• Żaden krytyczny system wewnętrzny nie zależy od HTTP pod tą samą domeną nadrzędną.
• Preload został omówiony świadomie, a nie dodany z przyzwyczajenia.

Lighthouse może też w niektórych kontekstach zgłaszać brakujące albo słabe nagłówki bezpieczeństwa, ale nie powinien być jedyną metodą weryfikacji. Jeśli używasz go jako części szerszego przeglądu, traktuj wyniki jako sygnały, a nie wyroki; to samo podejście przydaje się, gdy czytasz raport Lighthouse bez paniki.

<!-- tool-cta:start -->

💡 Wypróbuj to: Przed każdą zmianą HSTS i po niej sprawdź odpowiedź Strict-Transport-Security za pomocą Get Headers, aby potwierdzić, że max-age, includeSubDomains i preload są zgodne z oczekiwaniami.

<!-- tool-cta:end -->

Prywatnościowy sens HSTS

HSTS jest często opisywany jako nagłówek bezpieczeństwa, i słusznie. Ma też korzyść dla prywatności: zmniejsza szansę, że pierwsze żądanie użytkownika wycieknie zwykłym HTTP w niezaufanej sieci.

Ma to znaczenie w Wi-Fi na lotnisku, sieciach hotelowych, firmowych sieciach gościnnych i wszędzie tam, gdzie ruch użytkownika może być obserwowany albo modyfikowany. Zwykłe żądanie HTTP może ujawnić hostname, ścieżkę, cookies bez flagi Secure i inne szczegóły żądania. HTTPS nie jest magią, ale konsekwentne wymuszanie go usuwa całą klasę możliwych do uniknięcia wycieków.

Najlepsze wdrożenia HSTS są nieciekawe. Są wprowadzane powoli, wspierane przez niezawodne certyfikaty i na tyle nudne, że nikt ich nie zauważa. Właśnie tego chcesz od nagłówka, którego tryb awarii może być dramatyczny.