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.
Obsah
- HSTS je jednoduché, kým nie je
- Čo hlavička HSTS v skutočnosti robí
- Scenáre odrezania, ktorým sa treba vyhnúť
- 1. Zabudnutá subdoména nie je pripravená na HTTPS
- 2. Certifikát expiruje
- 3. Staging alebo interné nástroje žijú pod produkčnou doménou
- 4. Preload sa berie ako bežné zaškrtávacie políčko
- Bezpečný plán zavedenia
- Krok 1: Skontrolujte každý hostname, ktorý ovládate
- Krok 2: Opravte HTTPS pred pridaním HSTS
- Krok 3: Začnite s veľmi krátkym max-age
- Krok 4: Zvyšujte postupne
- Krok 5: includeSubDomains pridajte až po skutočnom audite
- Krok 6: Preload berte ako samostatný projekt
- Príklady konfigurácie
- Nginx
- Apache
- CDN alebo edge platforma
- Ako bezpečne vrátiť HSTS späť
- Testovací checklist pred nasadením
- 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.comapi.example.comold-crm.example.comprinter-setup.example.comstaging.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-
wwwnawww, 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-ageaspoň 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:
- Obnovte platné HTTPS.
- Obsluhujte
Strict-Transport-Security: max-age=0. - Nechajte ho na mieste dosť dlho, aby ho dostali vracajúci sa používatelia.
- 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ý.