Jak nastavit HSTS, aniž byste se sami odřízli

HSTS je jednoduché, dokud není

HTTP Strict Transport Security, obvykle zkracované na HSTS, říká prohlížečům: „pro tento web vždy používej HTTPS.“ Jakmile prohlížeč obdrží hlavičku přes platné HTTPS spojení, zapamatuje si pravidlo na dobu, kterou určíte.

To je užitečné. Brání útokům na snížení úrovně protokolu, omezuje náhodné nezabezpečené požadavky a předchází nepříjemné chvíli, kdy uživatel zadá example.com a na okamžik se dotkne prostého HTTP, než je přesměrován.

Je to ale také lepkavé. Pokud zveřejníte špatnou politiku HSTS, prohlížeče ji mohou vynucovat ještě dlouho poté, co hlavičku ze serveru odstraníte. Tak se týmy samy odříznou: ne nutně od vlastního administračního panelu, ale od prohlížečů uživatelů, subdomén, stagingových systémů, legacy endpointů a zapomenutých služeb, které nejsou připravené na vynucené HTTPS.

Cílem není HSTS se vyhnout. Cílem je nasadit ho jako migraci, ne jako přepínač.

Co hlavička HSTS skutečně dělá

Typická hlavička HSTS vypadá takto:

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

Má tři důležité části:

• max-age: jak dlouho, v sekundách, má prohlížeč pro tohoto hostitele vynucovat HTTPS.
• includeSubDomains: zda se pravidlo vztahuje také na každou subdoménu.
• preload: signál, že chcete doménu zahrnout do preload seznamů prohlížečů.

Prohlížeč této hlavičce důvěřuje jen tehdy, když ji obdrží přes platné HTTPS. Pokud je certifikát neplatný, expirovaný nebo neodpovídá hostiteli, prohlížeč by z takové odpovědi neměl přijmout novou politiku HSTS.

Jakmile je politika uložená, budoucí pokusy navštívit http://example.com prohlížeč před odesláním požadavku povýší na https://example.com. To je přínos pro soukromí: nezabezpečený požadavek nikdy neopustí zařízení.

Scénáře odříznutí, kterým se vyhnout

Většinu selhání HSTS nezpůsobuje hlavní web. Dějí se na okrajích.

1. Zapomenutá subdoména není připravená na HTTPS

includeSubDomains působí úhledně, ale je absolutní. Pokud ho nastavíte na example.com, vztahuje se na:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• cokoli dalšího pod touto doménou

Pokud některý z těchto hostitelů nedokáže obsloužit platné HTTPS, uživatelé s uloženou politikou HSTS se k němu přes HTTP nedostanou.

2. Certifikát vyprší

Bez HSTS uživatelé někdy prokliknou varování o certifikátu. Není to dobrá bezpečnostní praxe, ale stává se to.

S HSTS moderní prohlížeče pro daného hostitele neumožňují snadné obejití chyb certifikátu. To je záměr. Zároveň to znamená, že obnova certifikátů musí být nudná, monitorovaná a otestovaná.

3. Staging nebo interní nástroje žijí pod produkční doménou

Umístění interních nástrojů pod *.example.com se může stát bolestivé, jakmile nadřazená doména používá includeSubDomains. Pokud tyto nástroje používají self-signed certifikáty, privátní certifikační autority, staré konfigurace TLS nebo žádné HTTPS, HSTS tuto zkratku odhalí.

To je jeden z důvodů, proč mnoho týmů drží interní a experimentální systémy pod samostatnou doménou s vlastní bezpečnostní politikou.

4. Preload se bere jako běžné zaškrtávátko

HSTS preload není jen další direktiva. Znamená, že vaše doména může být dodaná přímo v prohlížečích jako HTTPS-only ještě předtím, než uživatel váš web vůbec navštíví.

Tím se uzavírá mezera „první návštěvy“, ale návrat zpět je mnohem těžší. Odstranění z preload seznamů může trvat týdny nebo měsíce, než se dostane k uživatelům, podle vydávacích cyklů prohlížečů. Preload je vhodný pro stabilní, vyzrálé domény. Není vhodný pro web, který teprve zjišťuje, jaké subdomény vlastně má.

Bezpečný plán nasazení

Krok 1: Proveďte audit každého hostname, který ovládáte

Než nastavíte includeSubDomains, sepište každý hostname pod danou doménou. DNS záznamy jsou začátek, ale ne celý příběh. Zkontrolujte konfigurace CDN, hostingové dashboardy, hostname související s e-mailem, staré marketingové nástroje, storage buckety a interní dokumentaci.

U každého hostname si odpovězte:

• Obsluhuje HTTP, HTTPS, nebo obojí?
• Je HTTPS certifikát platný a automaticky obnovovaný?
• Přesměrovává HTTP na HTTPS čistě?
• Má být veřejný?
• Je stále potřeba?

Pokud už váš tým má návyky pro ladění produkčních hlaviček, přirozeně to patří vedle kontrol přesměrování a hlaviček. Tento workflow jsme popsali v článku malá sada nástrojů pro ladění přesměrování a HTTP hlaviček v produkci.

Krok 2: Opravte HTTPS před přidáním HSTS

HSTS neudělá z rozbitého HTTPS nastavení bezpečné. Pouze udělá HTTPS povinným.

Před zapnutím ověřte:

• TLS certifikáty pokrývají správné hostname.
• Certifikáty se automaticky obnovují.
• HTTP se přesměrovává na HTTPS pokud možno jedním čistým skokem.
• Přesměrování na kanonického hostitele jsou konzistentní, například z non-www na www, nebo naopak.
• Aplikační assety nezávisí na nezabezpečených URL http://.

Mixed content je méně častý než dříve, ale stále se objevuje ve starých CMS šablonách, analytických snippetech, vložených médiích a natvrdo zapsaných cestách k obrázkům.

Krok 3: Začněte s velmi krátkým max-age

Nezačínejte jedním rokem. Začněte pěti minutami:

Strict-Transport-Security: max-age=300

Nasaďte to jen na hostname, který testujete, obvykle na kanonický produkční web. includeSubDomains zatím vynechte.

Potom testujte ve skutečných prohlížečích a pomocí požadavků z příkazové řádky:

curl -I https://example.com

Měli byste vidět přesně jednu hlavičku Strict-Transport-Security. Duplicitní hlavičky HSTS z aplikačního serveru a CDN jsou častým zdrojem zmatku. Prohlížeče obecně použijí efektivní politiku, ale lidé ladící incident nepotřebují nejednoznačnost.

Krok 4: Postupně prodlužujte

Pokud se nic nerozbije, prodlužujte dobu po etapách:

Strict-Transport-Security: max-age=86400

Potom:

Strict-Transport-Security: max-age=604800

A pak třeba:

Strict-Transport-Security: max-age=2592000

Praktický harmonogram je:

• 5 minut
• 1 den
• 1 týden
• 1 měsíc
• 6 měsíců nebo 1 rok

Za spěch není žádná odměna. Smyslem postupného nasazení je dát monitoringu, support inboxu a okrajovým případům čas říct vám, co váš checklist minul.

Krok 5: includeSubDomains přidejte až po skutečném auditu

Jakmile je každá veřejná subdoména připravená na HTTPS, můžete zvážit:

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

Tohle je chvíle pro konzervativní přístup. Pokud jedna legacy služba stále potřebuje HTTP, nepřidávejte includeSubDomains na nadřazenou doménu. Buď tuto službu migrujte, přesuňte ji na jinou doménu, nebo přijměte, že vaše politika HSTS musí zatím zůstat užší.

Bezpečnostní hlavičky mají odrážet realitu. Nemají se používat jako motivační plakáty pro infrastrukturu, kterou doufáte mít později.

Krok 6: Berte preload jako samostatný projekt

O preload uvažujte pouze tehdy, když platí vše následující:

• Doména a všechny subdomény podporují platné HTTPS.
• HTTP se přesměrovává na HTTPS.
• Hlavička HSTS používá max-age alespoň 31536000 sekund.
• Hlavička obsahuje includeSubDomains.
• Hlavička obsahuje preload.
• Jste si jistí, že nikde pod doménou nebudete potřebovat prosté HTTP.

Hlavička připravená pro preload vypadá takto:

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

Odeslání do preload seznamu je dlouhodobý závazek. Pokud je web kampaňový microsite, dočasná produktová doména nebo doména s nejasnými hranicemi vlastnictví, vynechte ho.

Příklady konfigurace

Nginx

Použijte always, aby se hlavička posílala i u chybových odpovědí:

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

Po stabilizaci nasazení:

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

Apache

Se zapnutým mod_headers:

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

Později:

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

CDN nebo edge platforma

Pokud vaše CDN nastavuje response headers, preferujte správu HSTS na jednom místě. Nenastavujte jednu politiku na originu a jinou na edge, pokud k tomu nemáte velmi jasný důvod.

Zkontrolujte také, zda CDN aplikuje hlavičky na přesměrování, cachované chyby a vlastní chybové stránky. Produkční web není jen jeho odpověď 200 OK.

Jak HSTS bezpečně vrátit zpět

Pokud potřebujete HSTS vypnout, pošlete:

Strict-Transport-Security: max-age=0

Má to ale háček: prohlížeč se musí úspěšně dostat na web přes platné HTTPS, aby tuto hlavičku obdržel. Pokud je samotné HTTPS rozbité, uživatelé s uloženou politikou HSTS si nemohou stáhnout instrukci, která by ji vymazala.

Obvyklé pořadí obnovy je tedy:

1. Obnovte platné HTTPS.
2. Servírujte Strict-Transport-Security: max-age=0.
3. Nechte ho na místě dost dlouho, aby ho vracející se uživatelé obdrželi.
4. Po vyřešení incidentu hlavičku odstraňte nebo nahraďte.

Pokud je doména v preload seznamu, servírování max-age=0 nestačí pro nové profily prohlížeče. Musíte také požádat o odstranění z preload seznamu a počkat, až se změna dostane k uživatelům prostřednictvím aktualizací prohlížečů.

Checklist pro testování před nasazením

Použijte tento checklist před zvýšením max-age nebo přidáním includeSubDomains:

• Kanonická HTTPS URL vrací platný certifikát.
• HTTP se přesměrovává na HTTPS.
• Existuje jen jedna hlavička HSTS.
• Hlavička se objevuje na přesměrováních a chybových odpovědích tam, kde je to vhodné.
• Všechny veřejné subdomény mají platné HTTPS.
• Obnova certifikátů je monitorovaná.
• Žádný kritický interní systém nezávisí na HTTP pod stejnou nadřazenou doménou.
• Preload byl výslovně prodiskutován, nebyl přidán ze zvyku.

Lighthouse může v některých kontextech také označit chybějící nebo slabé bezpečnostní hlavičky, ale neměl by být vaší jedinou metodou ověření. Pokud ho používáte jako součást širší kontroly, čtěte zjištění jako signály, ne jako verdikty; stejný přístup se hodí, když čtete Lighthouse report bez paniky.

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

💡 Vyzkoušejte toto: Před každou změnou HSTS i po ní zkontrolujte odpověď Strict-Transport-Security pomocí Get Headers, abyste potvrdili, že max-age, includeSubDomains a preload odpovídají vašemu očekávání.

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

Proč je HSTS dobré pro soukromí

HSTS se často popisuje jako bezpečnostní hlavička, a tou také je. Má ale i přínos pro soukromí: snižuje pravděpodobnost, že první požadavek uživatele unikne přes prosté HTTP na nedůvěryhodné síti.

To je důležité na letištní Wi-Fi, hotelových sítích, firemních sítích pro hosty a všude tam, kde může být provoz uživatele pozorován nebo upravován. Prostý HTTP požadavek může odhalit hostname, cestu, cookies bez příznaku Secure a další detaily požadavku. HTTPS není magie, ale jeho důsledné vynucení odstraňuje celou třídu zbytečných úniků.

Nejlepší nasazení HSTS jsou nezajímavá. Zavádějí se pomalu, opírají se o spolehlivé certifikáty a jsou dost nudná na to, aby si jich nikdo nevšiml. Přesně to chcete od hlavičky, jejíž způsob selhání může být dramatický.