Privacy & Security

Ako nastaviť HSTS bez toho, aby ste sa odrezali

Postupný, vratný plán zavedenia Strict-Transport-Security, ktorý zlepšuje súkromie bez toho, aby jeden chybný certifikát spôsobil výpadok.

The Wux Webtools Team The Wux Webtools Team 10 min čítania Pomocou AI, kontrolované človekom
Illustration of a secure browser connection with redirect arrows and subdomain warning markers.
Obsah
  1. HSTS je jednoduché, kým nie je
  2. Čo hlavička HSTS v skutočnosti robí
  3. Scenáre odrezania, ktorým sa treba vyhnúť
  4. 1. Zabudnutá subdoména nie je pripravená na HTTPS
  5. 2. Certifikát expiruje
  6. 3. Staging alebo interné nástroje žijú pod produkčnou doménou
  7. 4. Preload sa berie ako bežné zaškrtávacie políčko
  8. Bezpečný plán zavedenia
  9. Krok 1: Skontrolujte každý hostname, ktorý ovládate
  10. Krok 2: Opravte HTTPS pred pridaním HSTS
  11. Krok 3: Začnite s veľmi krátkym max-age
  12. Krok 4: Zvyšujte postupne
  13. Krok 5: includeSubDomains pridajte až po skutočnom audite
  14. Krok 6: Preload berte ako samostatný projekt
  15. Príklady konfigurácie
  16. Nginx
  17. Apache
  18. CDN alebo edge platforma
  19. Ako bezpečne vrátiť HSTS späť
  20. Testovací checklist pred nasadením
  21. Prínos HSTS pre súkromie

HSTS je jednoduché, kým nie je

HTTP Strict Transport Security, zvyčajne skracované na HSTS, hovorí prehliadačom: „pre túto lokalitu vždy používaj HTTPS.“ Keď prehliadač dostane túto hlavičku cez platné HTTPS pripojenie, zapamätá si pravidlo na vami určený čas.

Je to užitočné. Bráni útokom na zníženie protokolu, znižuje počet náhodných nezabezpečených požiadaviek a odstraňuje nepríjemný moment, keď používateľ zadá example.com a na chvíľu sa dotkne obyčajného HTTP, kým prebehne presmerovanie.

Je to však aj lepkavé. Ak zverejníte nesprávnu politiku HSTS, prehliadače ju môžu vynucovať ešte dlho po tom, čo hlavičku zo servera odstránite. Takto sa tímy odrezávajú: nie presne od vlastného administrátorského panela, ale od prehliadačov používateľov, subdomén, staging systémov, starších endpointov a zabudnutých služieb, ktoré nie sú pripravené na vynútené HTTPS.

Cieľom nie je vyhnúť sa HSTS. Cieľom je nasadiť ho ako migráciu, nie ako prepínač.

Čo hlavička HSTS v skutočnosti robí

Typická hlavička HSTS vyzerá takto:

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

Má tri dôležité časti:

  • max-age: ako dlho, v sekundách, má prehliadač vynucovať HTTPS pre tento hostiteľský názov.
  • includeSubDomains: či sa pravidlo vzťahuje aj na každú subdoménu.
  • preload: signál, že chcete doménu zaradiť do preload zoznamov prehliadačov.

Prehliadač tejto hlavičke dôveruje iba vtedy, keď ju dostane cez platné HTTPS. Ak je certifikát neplatný, expirovaný alebo nesedí, prehliadač by z takejto odpovede nemal prijať novú politiku HSTS.

Keď je politika uložená, budúce pokusy navštíviť http://example.com prehliadač upgraduje na https://example.com ešte pred odoslaním požiadavky. To je prínos pre súkromie: nezabezpečená požiadavka nikdy neopustí zariadenie.

Scenáre odrezania, ktorým sa treba vyhnúť

Väčšinu zlyhaní HSTS nespôsobí hlavný web. Dej sa odohráva na okrajoch.

1. Zabudnutá subdoména nie je pripravená na HTTPS

includeSubDomains znie upratane, ale je absolútne. Ak ho nastavíte na example.com, vzťahuje sa na:

  • www.example.com
  • api.example.com
  • old-crm.example.com
  • printer-setup.example.com
  • staging.example.com
  • čokoľvek ďalšie pod touto doménou

Ak ktorýkoľvek z týchto hostiteľov nevie obslúžiť platné HTTPS, používatelia s uloženou politikou HSTS sa k nemu cez HTTP nedostanú.

2. Certifikát expiruje

Bez HSTS používatelia niekedy prekliknú varovania o certifikáte. Nie je to dobrá bezpečnostná prax, ale deje sa to.

S HSTS moderné prehliadače pri danom hostiteľovi neumožňujú jednoduché obídenie chýb certifikátu. To je jeho zmysel. Zároveň to znamená, že obnova certifikátov musí byť nudná, monitorovaná a testovaná.

3. Staging alebo interné nástroje žijú pod produkčnou doménou

Umiestniť interné nástroje pod *.example.com môže byť bolestivé, keď nadradená doména používa includeSubDomains. Ak tieto nástroje používajú samopodpísané certifikáty, súkromné certifikačné autority, staré konfigurácie TLS alebo vôbec žiadne HTTPS, HSTS túto skratku odhalí.

Aj preto mnohé tímy držia interné a experimentálne systémy pod samostatnou doménou, ktorá má vlastnú bezpečnostnú politiku.

4. Preload sa berie ako bežné zaškrtávacie políčko

HSTS preload nie je len ďalšia direktíva. Znamená, že vaša doména môže byť dodaná priamo v prehliadačoch ako výlučne HTTPS ešte predtým, než používateľ vašu stránku navštívi.

Tým sa uzavrie medzera „prvej návštevy“, ale je oveľa ťažšie to vrátiť späť. Odstránenie z preload zoznamov môže trvať týždne alebo mesiace, kým sa dostane k používateľom, v závislosti od vydávacích cyklov prehliadačov. Preload je vhodný pre stabilné, zrelé domény. Nie je vhodný pre web, ktorý ešte len zisťuje inventár svojich subdomén.

Bezpečný plán zavedenia

Krok 1: Skontrolujte každý hostname, ktorý ovládate

Pred nastavením includeSubDomains vypíšte každý hostname pod doménou. DNS záznamy sú začiatok, ale nie celý príbeh. Skontrolujte konfigurácie CDN, hostingové rozhrania, hostname súvisiace s e-mailom, staré marketingové nástroje, storage buckets a internú dokumentáciu.

Pre každý hostname si odpovedzte:

  • Obsluhuje HTTP, HTTPS alebo oboje?
  • Je HTTPS certifikát platný a automaticky obnovovaný?
  • Presmerúva HTTP na HTTPS čisto?
  • Má byť verejný?
  • Je ešte potrebný?

Ak už váš tím má návyky ladenia produkčných hlavičiek, prirodzene to zapadne vedľa kontrol presmerovaní a hlavičiek. Tento pracovný postup sme pokryli v článku malá súprava nástrojov na ladenie presmerovaní a HTTP hlavičiek v produkcii.

Krok 2: Opravte HTTPS pred pridaním HSTS

HSTS nespraví z pokazenej konfigurácie HTTPS bezpečnú konfiguráciu. Iba urobí HTTPS povinným.

Pred zapnutím overte:

  • TLS certifikáty pokrývajú správne hostname.
  • Certifikáty sa obnovujú automaticky.
  • HTTP presmerúva na HTTPS jedným čistým skokom tam, kde je to možné.
  • Presmerovania kanonického hostiteľa sú konzistentné, napríklad z non-www na www, alebo naopak.
  • Aplikačné assets nezávisia od nezabezpečených http:// URL.

Mixed content je menej bežný než kedysi, ale stále sa objavuje v starých témach CMS, analytických snippetech, vložených médiách a natvrdo zapísaných cestách k obrázkom.

Krok 3: Začnite s veľmi krátkym max-age

Nezačínajte jedným rokom. Začnite piatimi minútami:

Strict-Transport-Security: max-age=300

Nasaďte to iba na hostname, ktorý testujete, zvyčajne na kanonický produkčný web. includeSubDomains zatiaľ vynechajte.

Potom testujte v skutočných prehliadačoch aj pomocou požiadaviek z príkazového riadka:

curl -I https://example.com

Mali by ste vidieť presne jednu hlavičku Strict-Transport-Security. Duplicitné hlavičky HSTS z aplikačného servera a CDN sú častým zdrojom zmätku. Prehliadače vo všeobecnosti použijú efektívnu politiku, ale ľudia ladiaci incident nepotrebujú nejednoznačnosť.

Krok 4: Zvyšujte postupne

Ak sa nič nepokazí, zvyšujte trvanie po etapách:

Strict-Transport-Security: max-age=86400

Potom:

Strict-Transport-Security: max-age=604800

A potom možno:

Strict-Transport-Security: max-age=2592000

Praktický harmonogram je:

  • 5 minút
  • 1 deň
  • 1 týždeň
  • 1 mesiac
  • 6 mesiacov alebo 1 rok

Za náhlenie nie je žiadna cena. Celý zmysel postupného zavádzania je dať monitoringu, support inboxu a okrajovým prípadom čas povedať vám, čo váš checklist prehliadol.

Krok 5: includeSubDomains pridajte až po skutočnom audite

Keď je každá verejná subdoména pripravená na HTTPS, môžete zvážiť:

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

V tomto momente buďte konzervatívni. Ak jedna staršia služba stále potrebuje HTTP, nepridávajte includeSubDomains na nadradenú doménu. Buď túto službu migrujte, presuňte ju na inú doménu, alebo prijmite, že vaša politika HSTS musí zatiaľ zostať užšia.

Bezpečnostné hlavičky majú odrážať realitu. Nemajú slúžiť ako motivačné plagáty pre infraštruktúru, v ktorú dúfate neskôr.

Krok 6: Preload berte ako samostatný projekt

Preload zvažujte iba vtedy, keď platí všetko nasledujúce:

  • Doména a všetky subdomény podporujú platné HTTPS.
  • HTTP presmerúva na HTTPS.
  • Hlavička HSTS používa max-age aspoň 31536000 sekúnd.
  • Hlavička obsahuje includeSubDomains.
  • Hlavička obsahuje preload.
  • Ste si istí, že nikde pod doménou nebudete potrebovať obyčajné HTTP.

Hlavička pripravená na preload vyzerá takto:

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

Odoslanie do preload zoznamu je dlhodobý záväzok. Ak je web kampaňový microsite, dočasná produktová doména alebo doména s nejasnými hranicami vlastníctva, preskočte ho.

Príklady konfigurácie

Nginx

Použite always, aby sa hlavička odosielala aj pri chybových odpovediach:

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

Keď je zavedenie stabilné:

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

Apache

So zapnutým mod_headers:

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

Neskôr:

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

CDN alebo edge platforma

Ak vaša CDN nastavuje hlavičky odpovedí, uprednostnite správu HSTS na jednom mieste. Nenastavujte jednu politiku na origine a inú na edge, pokiaľ na to nemáte veľmi jasný dôvod.

Skontrolujte aj to, či CDN aplikuje hlavičky na presmerovania, cacheované chyby a vlastné chybové stránky. Produkčný web nie je iba jeho odpoveď 200 OK.

Ako bezpečne vrátiť HSTS späť

Ak potrebujete HSTS vypnúť, odošlite:

Strict-Transport-Security: max-age=0

Má to však háčik: prehliadač sa musí úspešne dostať na web cez platné HTTPS, aby túto hlavičku prijal. Ak je pokazené samotné HTTPS, používatelia s uloženou politikou HSTS nemôžu získať inštrukciu, ktorá by ju vymazala.

Bežné poradie obnovy je teda:

  1. Obnovte platné HTTPS.
  2. Obsluhujte Strict-Transport-Security: max-age=0.
  3. Nechajte ho na mieste dosť dlho, aby ho dostali vracajúci sa používatelia.
  4. Po vyriešení incidentu hlavičku odstráňte alebo nahraďte.

Ak je doména v preload zozname, obsluhovanie max-age=0 nestačí pre nové profily prehliadačov. Musíte tiež požiadať o odstránenie z preload zoznamu a počkať, kým sa táto zmena dostane k používateľom cez aktualizácie prehliadačov.

Testovací checklist pred nasadením

Tento checklist použite pred zvýšením max-age alebo pridaním includeSubDomains:

  • Kanonická HTTPS URL vracia platný certifikát.
  • HTTP presmerúva na HTTPS.
  • Existuje iba jedna hlavička HSTS.
  • Hlavička sa zobrazuje na presmerovaniach a chybových odpovediach tam, kde je to vhodné.
  • Všetky verejné subdomény majú platné HTTPS.
  • Obnova certifikátov je monitorovaná.
  • Žiadny kritický interný systém nezávisí od HTTP pod tou istou nadradenou doménou.
  • Preload bol výslovne prediskutovaný, nie pridaný zo zvyku.

Lighthouse môže v niektorých kontextoch tiež označiť chýbajúce alebo slabé bezpečnostné hlavičky, ale nemal by byť vašou jedinou metódou overenia. Ak ho používate ako súčasť širšej kontroly, čítajte zistenia ako signály, nie ako verdikty; rovnaký prístup platí, keď čítate report Lighthouse bez paniky.

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

💡 Vyskúšajte toto: Pred každou zmenou HSTS aj po nej skontrolujte odpoveď Strict-Transport-Security pomocou Get Headers, aby ste potvrdili, že max-age, includeSubDomains a preload sú také, aké očakávate.

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

Prínos HSTS pre súkromie

HSTS sa často rámcuje ako bezpečnostná hlavička, a ňou aj je. Má aj prínos pre súkromie: znižuje šancu, že prvá požiadavka používateľa unikne cez obyčajné HTTP v nedôveryhodnej sieti.

Na tom záleží na letiskovej Wi‑Fi, hotelových sieťach, firemných hosťovských sieťach a všade tam, kde môže byť prevádzka používateľa pozorovaná alebo upravená. Obyčajná HTTP požiadavka môže odhaliť hostname, cestu, cookies bez príznaku Secure a ďalšie detaily požiadavky. HTTPS nie je mágia, ale jeho konzistentné vynútenie odstraňuje celú triedu zbytočných únikov.

Najlepšie nasadenia HSTS sú nezaujímavé. Zavádzajú sa pomaly, stoja na spoľahlivých certifikátoch a sú dosť nudné na to, aby si ich nikto nevšimol. Presne to chcete od hlavičky, ktorej režim zlyhania môže byť dramatický.

Často kladené otázky

Aká je bezpečná prvá hlavička HSTS?
Začnite s `Strict-Transport-Security: max-age=300`. Prehliadačom to dá päťminútovú politiku, čo je dosť dlho na otestovanie správania, ale dosť krátko na rýchle zotavenie z väčšiny chýb.
Má každý web používať includeSubDomains?
Nie. `includeSubDomains` používajte iba vtedy, keď každá subdoména pod nadradenou doménou podporuje platné HTTPS a bude v tom pokračovať. Jeden zabudnutý starší hostiteľ sa môže stať nedostupným pre používateľov s uloženou politikou.
Je HSTS preload nevyhnutný?
Nie pre väčšinu malých alebo stredných webov. Preload chráni úplne prvú návštevu, ale ťažko sa vracia späť a vyžaduje, aby bol celý menným priestor domény pripravený na HTTPS. Zvažujte ho až po stabilnom zavedení HSTS.
Môžem HSTS odstrániť vymazaním hlavičky?
Vymazanie hlavičky zastaví nastavovanie nových politík, ale nevymaže politiky, ktoré už majú prehliadače uložené. Na vymazanie HSTS obslúžte `Strict-Transport-Security: max-age=0` cez platné HTTPS.
Opravuje HSTS mixed content?
Nie. HSTS vynucuje HTTPS pre pripojenie k webu na najvyššej úrovni. Nezabezpečené URL assetov, vložený obsah a staré natvrdo zapísané odkazy `http://` musíte opraviť samostatne.

Zdroje a ďalšie čítanie

  1. MDN Web Docs: Strict-Transport-Security
  2. OWASP HTTP Strict Transport Security Cheat Sheet
  3. HSTS Preload Submission Requirements
  4. RFC 6797: HTTP Strict Transport Security
O autorovi
The Wux Webtools Team

Posledná aktualizácia:

Pokračujte v čítaní