Szyfrowanie HTTPS rozwiązuje wiele problemów, ale jeden element od lat pozostaje krytycznym punktem podatności: moment, w którym przeglądarka jeszcze nie wie, czy powinna korzystać z HTTPS. Ten etap poprzedza właściwe połączenie TLS – następuje zanim zostanie wykonany handshake, zanim zostanie zweryfikowany certyfikat i zanim serwer w ogóle otrzyma możliwość wymuszenia jakichkolwiek zasad. Właśnie w tym oknie czasowym powstaje przestrzeń dla SSL strippingu, manipulacji ruchem w sieci publicznej oraz dla ataków polegających na przechwytywaniu pierwszego zapytania i modyfikowaniu odpowiedzi tak, aby użytkownik nigdy nie trafił do wersji szyfrowanej.

HSTS i HSTS Preload: jak przeglądarka podejmuje decyzje o zaufaniu zanim nawiąże połączenie?

Mechanizm HSTS został zaprojektowany jako element, który pozwala przeglądarce zapamiętać, że dana domena ma być obsługiwana wyłącznie przez HTTPS. Jednak ta informacja trafia do przeglądarki dopiero w momencie, kiedy serwer zwróci odpowiedni nagłówek, a więc po pierwszym połączeniu. Jeśli to pierwsze połączenie jest skażone, polityka HSTS może nigdy nie zostać dostarczona, ponieważ atakujący łatwo ją usuwa lub podmienia. To sprawia, że podstawowy model HSTS działa znakomicie, ale tylko wtedy, gdy użytkownik miał już kiedyś szansę odwiedzić stronę w bezpiecznych warunkach. HSTS Preload całkowicie usuwa ten problem. Lista preload jest wpisana w kod przeglądarki – dosłownie znajduje się w strukturze kompilacji Chrome i jest synchronizowana do pozostałych przeglądarek. Gdy użytkownik wpisuje adres domeny preloadowanej, przeglądarka nie zadaje żadnych pytań: nie łączy się przez HTTP, nie pozwala ustanowić połączenia na porcie 80, nie oczekuje na nagłówek serwera. Po prostu z góry przepuszcza ruch wyłącznie przez HTTPS. W praktyce wygląda to tak, jakby cała domena została przeniesiona do innego, twardszego modelu zaufania – jedynego w którym nie istnieje możliwość oszukania przeglądarki przez zmanipulowanie pierwszego pakietu.

Można to łatwo zaobserwować, porównując zachowanie przeglądarki z preload i bez preload. W domenie bez preload przeglądarka wykona faktyczne zapytanie HTTP, zanim otrzyma redirect 301:

GET / HTTP/1.1
Host: example.pl

Natomiast w domenie preloadowanej nie powstaje nawet połączenie TCP do portu 80 – przeglądarka przepisuje adres wewnętrznie jeszcze przed warstwą sieciową:

https://example.pl

Ten krok jest niewidoczny dla użytkownika, ale ma fundamentalne znaczenie. Cała pierwsza faza komunikacji, która była najbardziej wrażliwa na manipulację, przestaje istnieć. To właśnie dlatego preload jest traktowany jako poważna deklaracja technologiczna: nie da się go wycofać od ręki, nie da się go obejść, a jego konsekwencje są globalne. Wymagania techniczne wynikają wprost z tego modelu zaufania. Przeglądarki nie mogą dopuścić do sytuacji, w której preloadowana domena ma choć jedną subdomenę działającą na HTTP lub choć jeden endpoint, który nie obsługuje certyfikatu. Dlatego konieczne są trzy elementy: max-age na minimum rok, includeSubDomains oraz słowo kluczowe preload. Konstrukcja nagłówka musi wyglądać następująco:

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

Jeżeli domena używa Cloudflare, nagłówek można ustawić nawet bez dotykania originu – bezpośrednio w regułach transformacji lub w panelu SSL → HSTS. W przypadku serwerów takich jak NGINX albo OpenLiteSpeed konfiguracja również jest trywialna:

NGINX:

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

OpenLiteSpeed (vhost-level rule):

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

Największym błędem administratorów jest przekonanie, że HSTS to tylko kwestia jednego nagłówka. Wbrew pozorom jest to decyzja dotycząca całej architektury domeny. Jeśli w strukturze znajduje się nieużywana subdomena, środowisko testowe na HTTP, stary panel administracyjny lub cokolwiek, co nie spełnia wymogów HTTPS – preload dyskwalifikuje. To dlatego wiele firm komercyjnych świadomie z niego rezygnuje, mimo że wiedzą, że rozwiązanie jest idealne pod względem bezpieczeństwa. Preload nie toleruje niedociągnięć w organizacji. Warto też zauważyć, że preload idealnie komponuje się z nowoczesnym modelem ruchu przez CDN. Kiedy TLS jest terminowany na edge, np. w Cloudflare, to właśnie CDN staje się „serwerem” dla przeglądarki. Jeśli preload jest aktywny, cały model komunikacji jest deterministyczny i jednolity – niezależnie od tego, na którym POP przeglądarka zakończy trasowanie. To jest jeden z powodów, dla których domeny preloadowane częściej uzyskują stabilną ocenę A+ w SSL Labs na wszystkich punktach dostępności.

Wdrożenie preload jest więc decyzją, która zmienia charakter domeny z „HTTPS optional” na „HTTPS compulsory”. To nie jest zwykłe włączenie nagłówka. W praktyce to zamknięcie wszystkich możliwych dróg odwrotu i jednoznaczne oświadczenie: „ta domena już nigdy nie będzie działać przez HTTP”. Dla firm budujących produkty bezpieczeństwowe – jak HEXSSL – jest to naturalny krok, bo preload podkreśla spójność i konsekwencję w projektowaniu architektury transportowej.

Co jeśli coś pójdzie nie tak? Preload jako decyzja trudna do cofnięcia.

Preload jest jednym z niewielu mechanizmów bezpieczeństwa, który nie działa w czasie rzeczywistym, lecz opiera się na cyklu życia oprogramowania. Gdy domena zostanie wpisana na listę preloadowaną, przeglądarki pobierają tę informację w ramach aktualizacji i przechowują ją przez cały okres życia zainstalowanej wersji. Oznacza to, że nawet jeśli później usuniesz nagłówek preload, klienci nadal będą traktować Twoją domenę jako HTTPS-only do momentu, aż zainstalują nową wersję przeglądarki. Jeżeli użytkownik korzysta z systemu, którego aktualizacje są rzadkie (np. Android z 2018 roku), zmiana może nie dotrzeć do niego przez wiele lat.

Dlatego proces wycofania domeny z preload jest powolny, a czas propagacji zależy od milionów indywidualnych czynników. Google wymaga, aby administrator zgłaszał się do usunięcia domeny z preload tylko w uzasadnionych sytuacjach – takich, kiedy konfiguracja bezpieczeństwa została naruszona w sposób poważny i trwały. W praktyce oznacza to konieczność publikacji tymczasowego nagłówka, który wyłącza obowiązywanie polityki i pozwala przeglądarkom ponownie korzystać z HTTP. Jednak przeglądarki, które mają starą wersję listy preload, i tak będą wymuszać HTTPS. W efekcie mamy sytuację, w której preload nie jest ustawieniem konfiguracyjnym, ale deklaracją architektoniczną. Domen, które zostały usunięte z listy preload, jest bardzo niewiele, właśnie dlatego że procedura nie jest ani szybka, ani bezbolesna. Każda organizacja przed zgłoszeniem powinna mieć pełną świadomość, że preload cementuje model komunikacji na lata i nie ma możliwości natychmiastowego rollbacku.

Najczęstsze błędy administratorów: gdy domena łamie własną politykę bezpieczeństwa.

Chociaż preload jest prosty w warstwie technicznej, to błędy popełniane przez administratorów są często subtelne i trudno wykrywalne bez odpowiednich narzędzi. Najpowszechniejszym problemem są subdomeny, które funkcjonują poza świadomością zespołu – stagingi pozostawione w chmurze, testowe panele developerskie, nieużywane wildcardy lub integracje, które dawno straciły znaczenie, ale nadal istnieją w DNS. Jeśli choć jeden taki punkt końcowy działa wyłącznie na HTTP, polityka preload zostaje naruszona, choć sam właściciel domeny może nie wiedzieć, że problem istnieje.

Innym typowym błędem jest stosowanie tymczasowych środowisk do celów testowych, które są wystawiane publicznie i nieco później zapomniane. Narzędzia typu CertSpotter, crt.sh czy skanery DNS pokazują czasem setki certyfikatów wydanych na subdomeny, których administratorzy dawno nie pamiętają. Jeżeli polityka includeSubDomains jest aktywna, to każda taka subdomena jest traktowana jako zobowiązanie bezpieczeństwa. Wiele problemów wynika również z niejednolitego zachowania originu oraz CDN-u. Jeśli CDN zwraca poprawny nagłówek HSTS, ale origin już nie, powstaje niespójność. Przeglądarka widzi ruch wyłącznie przez CDN, ale mechanizmy automatyczne – np. skanery zgodności – mogą wykrywać różnice pomiędzy poziomami infrastruktury. W skrajnych przypadkach błędne nagłówki originu są interpretowane jako próba obniżenia poziomu bezpieczeństwa, co może prowadzić do odrzucenia zgłoszenia preload.

Te problemy nie wynikają ze złej woli, ale z naturalnej złożoności dużych struktur DNS i setek punktów dostępowych. To właśnie dlatego audyt subdomen i pełna obserwowalność warstwy transportowej są niezbędne przed jakąkolwiek decyzją o preload. Narzędzia takie jak curl, openssl s_client, a także dedykowane skrypty audytowe pozwalają wykryć niezgodności, które normalnie pozostają niewidoczne.

Jak przeglądarka egzekwuje politykę HSTS Preload? Wewnętrzny mechanizm Chrome.

Choć HSTS Preload wygląda z zewnątrz jak prosta lista domen, jego implementacja wewnątrz przeglądarki jest bardziej złożona. Chrome kompiluje statyczny plik JSON do struktury C++, która jest ładowana podczas startu aplikacji. Każdy wpis zawiera arenę danych, w której zaznaczone są atrybuty bezpieczeństwa, flagi polityk oraz informacje o konieczności wymuszenia HTTPS. Gdy użytkownik wpisuje adres domeny, Chrome nie wykonuje jeszcze żadnego zapytania sieciowego. Pierwszy etap odbywa się w warstwie URLLoadera: zanim zostanie zainicjowane socket TCP, Chrome sprawdza lokalną politykę HSTS. Jeżeli domena znajduje się na liście preload, przeglądarka modyfikuje schemat protokołu na https:// i rozpoczyna handshake TLS, pomijając cały proces HTTP. W kodzie źródłowym wygląda to mniej więcej tak:

if (IsPreloadedHSTS(host)) {
    scheme = "https";
}

Dopiero po wejściu w gałąź HTTPS Chrome przechodzi do warstwy net/socket i próbuje ustanowić połączenie z portem 443. Jeśli serwer nie obsługuje HTTPS, komunikacja natychmiast kończy się błędem i użytkownik widzi komunikat o niemożności nawiązania połączenia – nawet jeśli teoretycznie serwer działa na HTTP. To zachowanie jest w pełni zamierzone: preload blokuje wszelkie możliwości powrotu do nieszyfrowanej komunikacji. Cały proces działa lokalnie, deterministycznie i niezależnie od konfiguracji sieci. Atakujący nie ma żadnego punktu zaczepienia w tym mechanizmie, ponieważ nie jest w stanie wpływać na dane używane przez przeglądarkę przed ustanowieniem połączenia. To właśnie dlatego preload jest jednym z najskuteczniejszych mechanizmów ochronnych w historii Web Security.

Pełna ścieżka migracji organizacji na preload – proces, który musi objąć całą domenę.

Migracja na HSTS Preload wymaga podejścia bardziej zbliżonego do wdrażania architektury niż do ustawiania pojedynczego nagłówka. Preload nie wybacza półśrodków; wymusza pełną dyscyplinę transportową. Pierwszym krokiem jest uzyskanie pełnej widoczności nad przestrzenią DNS, ponieważ preload obejmuje absolutnie wszystkie subdomeny, a wiele organizacji ma w DNS historyczne wpisy, o których nikt już nie pamięta. To etap, w którym używa się szerokiej enumeracji, skanerów certyfikatów oraz narzędzi dostępowych, aby zidentyfikować pełną mapę punktów, które będą objęte polityką.

Typowa kontrola zaczyna się od zrzutu certyfikatów z crt.sh:

curl -s "https://crt.sh/?q=%.example.com&output=json"

To nie lista certyfikatów, tylko lista realnych, aktywnych śladów po subdomenach, z których wiele mogło zostać porzuconych. Preload wymusi ich HTTPS-only obsługę, dlatego muszą zostać uporządkowane.

Drugim istotnym etapem jest spójność zachowania całej infrastruktury. Origin, CDN, load balancer, reverse proxy – wszystkie te warstwy muszą zwracać jednolitą politykę. W praktyce oznacza to korektę nagłówków, redirectów i konfiguracji TLS na każdym z nich. Jeśli na przykład CDN wysyła poprawny nagłówek, ale origin nie, pojawia się niespójność, która może unieważnić zgłoszenie preload lub prowadzić do błędnych interpretacji narzędzi audytowych.

Sama konfiguracja HSTS również musi być adekwatna do przyszłej polityki. W okresie przejściowym organizacje najczęściej stosują taką wersję nagłówka:

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

Słowo preload dodaje się dopiero wtedy, gdy stabilność całego środowiska nie budzi żadnych wątpliwości. Ten czas „obserwacji” trwa zwykle kilka tygodni – to jedyny sposób, aby upewnić się, że aplikacje, integracje, stare API czy systemy partnerskie działają poprawnie w warunkach wymuszonego HTTPS.

Dopiero po przejściu przez:

• pełną enumerację subdomen,
• harmonizację zachowania wszystkich warstw sieciowych,
• okres stabilizacji operacyjnej,

można zgłosić domenę do HSTS Preload.

To nie jest akcja konfiguracyjna – to decyzja architektoniczna o trwałym przeniesieniu całej domeny do modelu bezpieczeństwa bez luk komunikacyjnych.

Jak preload wpływa na HTTP/3 i QUIC? Nowy transport wymaga nowej logiki bezpieczeństwa.

HTTP/3 i QUIC zmieniają sposób, w jaki przeglądarka prowadzi komunikację z serwerem. QUIC działa wyłącznie na UDP i łączy handshake transportowy z kryptograficznym. Nie ma w nim miejsca na nieszyfrowane połączenia, więc preload staje się w naturalny sposób częścią mechanizmu, który decyduje o tym, czy przeglądarka w ogóle może próbować używać QUIC.

W przypadku domen preloadowanych zachowanie jest jednoznaczne: przeglądarka nie rozważa HTTP jako alternatywy. Od razu inicjuje handshake QUIC – a jeśli ten się nie powiedzie, przechodzi do TLS 1.3 przez TCP, ale nadal bez dopuszczenia ruchu HTTP. Mechanizm wyboru protokołu przestaje być heurystyczny i staje się deterministyczny. Chrome nie próbuje „zgadywać”, czy serwer ma wsparcie dla QUIC – wykonuje próbę natychmiast, ponieważ polityka preload nie pozostawia miejsca na warstwy nieszyfrowane.

Widać to w strukturze pierwszego pakietu QUIC, który łączy funkcję ClientHello z częścią transportową:

QUIC Initial Packet:
  - TLS ClientHello
  - Supported Versions: h3, h3-29, h3-27
  - ALPN: h3

Jeśli domena jest preloadowana, przeglądarka przejdzie do tego kroku niezależnie od warunków sieciowych. Atakujący nie może wymusić wcześniejszego połączenia HTTP, ponieważ preload blokuje próbę otwarcia portu 80 jeszcze przed warstwą sieciową. Wpływa to również na wydajność. W klasycznym modelu bez preload przeglądarka musiała przeanalizować zestaw informacji heurystycznych – historię odwiedzin, poprzednie protokoły, wcześniejsze błędy QUIC, charakterystykę sieci – aby podjąć decyzję, czy warto próbować HTTP/3. W przypadku preload logika jest uproszczona: QUIC jest pierwszym wyborem, a fallback stosowany jest tylko wtedy, gdy serwer rzeczywiście nie oferuje HTTP/3.

Preload i QUIC wzmacniają się wzajemnie. QUIC usuwa koszt TCP + TLS, preload usuwa całą kategorię nieszyfrowanego transportu. Razem tworzą model, w którym nie ma miejsca na manipulację na pierwszych pakietach, a cały proces ustanawiania połączenia jest zarówno bezpieczniejszy, jak i szybszy. Dla domen działających globalnie – takich jak HEXSSL – ta synergia ma istotne znaczenie: każdy POP CDN pracuje w identycznym modelu bezpieczeństwa, a użytkownik na dowolnym kontynencie otrzymuje przewidywalne zachowanie transportowe, bez ryzyka downgrade lub manipulacji po stronie sieci.

HEXSSL – HSTS & Preload Checklist.

1. Certyfikaty i domeny.

❑ Domena główna ma poprawny certyfikat
❑ Wszystkie subdomeny mają ważne certyfikaty
❑ Brak subdomen bez HTTPS
❑ Wildcard pokrywa to, co powinien (a reszta ma pojedyncze certyfikaty)
❑ Żadne środowisko DEV/OLD nie jest publicznie dostępne przez HTTP

2. Wymuszenie HTTPS.

❑ HTTP → zawsze 301 do HTTPS
❑ 301 ustawiony na poziomie serwera, nie PHP
❑ Brak jakiejkolwiek odpowiedzi HTTP 200/403/404
❑ HTTP 301 zwraca również nagłówek HSTS (zgodnie z RFC)

3. Nagłówek HSTS – poprawność.

❑ Nagłówek zwracany dla każdej odpowiedzi HTTPS
❑ Nagłówek ma dokładnie tę wartość: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload


❑ max-age ≥ 31536000
❑ includeSubDomains jest obecne
❑ preload jest obecne
❑ „always”/”set” wymusza nagłówek także przy błędach 3xx/4xx/5xx

4. Testy poprawności.

❑ curl -I https://domena | grep -i strict zwraca nagłówek
❑ curl -I http://domena → 301 + HSTS
❑ curl -I https://www.domena → HSTS
❑ curl -I https://sub.domena → HSTS
❑ Zero odpowiedzi HTTP (bez 301)
❑ Cloudflare (lub inne) nie nadpisuje nagłówka błędnymi wartościami

5. Subdomeny – pełna walidacja.

❑ Lista subdomen pobrana z CT Logs:

curl -s "https://crt.sh/?q=%.domena.com&output=json" | jq '.[].name_value' | sort -u

❑ Każda subdomena ma certyfikat
❑ Każda subdomena zwraca HSTS
❑ Każda subdomena wymusza HTTPS 301
❑ Brak „martwych” subdomen z certyfikatem, ale bez serwera

6. Cloudflare / CDN.

❑ SSL Mode: Full (strict)
❑ Minimum TLS: 1.2 lub 1.3
❑ HSTS włączone w panelu CF (jeśli używane)
❑ Transform Rule nie nadpisuje HSTS błędną wartością
❑ Brak Page Rules, które mogłyby obsługiwać HTTP

7. Preload – warunki do spełnienia.

❑ HSTS włączone z max-age ≥ 31536000
❑ includeSubDomains obecne
❑ preload obecne
❑ Wszystkie subdomeny odpowiadają po HTTPS
❑ Brak błędów 403/404 dla zasobów krytycznych
❑ HTTP nigdy nie zwraca treści

8. Preload – zgłoszenie.

❑ Wejście na: https://hstspreload.org
❑ Test przechodzi w 100%
❑ Domena zgłoszona
❑ Monitorowanie statusu w Chrome Preload List
❑ Zakomunikowanie wewnętrznie: „operacja NIEODWRACALNA w krótkim terminie”

9. Monitoring po wdrożeniu.

❑ Testy curl codziennie przez 7 dni
❑ Test SSL Labs po wdrożeniu
❑ Alerty na błędy HTTP → 301 → HTTPS
❑ Alert na brak nagłówka HSTS
❑ Alert na zmianę certyfikatu (CT Monitoring)
❑ Weryfikacja QUIC/H3 działa poprawnie

10. Punkty ryzyka (co może popsuć preload).

❑ Zapomniana subdomena z wyłączonym serwerem
❑ DEV/OLD subdomena w DNS
❑ Przenoszenie produktu na nowy serwer bez certyfikatu
❑ Cloudflare w trybie DNS-only
❑ Wyłączenie HTTPS przez przypadek
❑ Błędny wildcard (np. *.example.com nie pokrywa example.com)

11. Minimalna lista testowa przed zgłoszeniem.

❑ domena główna – HSTS
❑ www – HSTS
❑ wildcard – HSTS
❑ wszystkie rekordy A/CNAME z DNS – HTTPS only
❑ certyfikaty 100% OK
❑ 0 stron HTTP
❑ 0 błędów Mixed Content
❑ 0 błędów w preload validator