Sådan opsætter du HSTS uden at låse dig selv ude

HSTS er enkelt, indtil det ikke er det

HTTP Strict Transport Security, normalt forkortet til HSTS, fortæller browsere: “brug altid HTTPS for dette site.” Når en browser modtager headeren over en gyldig HTTPS-forbindelse, husker den reglen i den periode, du angiver.

Det er nyttigt. Det forhindrer protokol-nedgraderingsangreb, reducerer utilsigtede usikre forespørgsler og undgår det akavede øjeblik, hvor en bruger skriver example.com og kortvarigt rammer almindelig HTTP, før der omdirigeres.

Det er også klæbrigt. Hvis du publicerer den forkerte HSTS-politik, kan browsere blive ved med at håndhæve den længe efter, at du har fjernet headeren fra din server. Det er sådan teams låser sig selv ude: ikke præcist fra deres eget adminpanel, men fra brugernes browsere, subdomæner, staging-systemer, legacy-endpoints og glemte tjenester, der ikke er klar til tvungen HTTPS.

Målet er ikke at undgå HSTS. Målet er at udrulle det som en migrering, ikke som en kontakt.

Hvad HSTS-headeren faktisk gør

En typisk HSTS-header ser sådan ud:

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

Den har tre vigtige dele:

• max-age: hvor længe, i sekunder, browseren skal håndhæve HTTPS for denne host.
• includeSubDomains: om reglen også gælder for hvert subdomæne.
• preload: et signal om, at du ønsker domænet inkluderet i browsernes preload-lister.

Browseren stoler kun på denne header, når den modtager den over gyldig HTTPS. Hvis certifikatet er ugyldigt, udløbet eller ikke matcher, bør browseren ikke acceptere en ny HSTS-politik fra det svar.

Når politikken er gemt, opgraderes fremtidige forsøg på at besøge http://example.com af browseren til https://example.com, før forespørgslen sendes. Det er privatlivsgevinsten: den usikre forespørgsel forlader aldrig enheden.

Lockout-scenarierne, du bør undgå

De fleste HSTS-fejl skyldes ikke hovedwebsitet. De sker i kanterne.

1. Et glemt subdomæne er ikke HTTPS-klar

includeSubDomains lyder ordentligt, men det er absolut. Hvis du sætter det på example.com, gælder det for:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• alt andet under det domæne

Hvis nogen af disse hosts ikke kan levere gyldig HTTPS, vil brugere med HSTS-politikken cachet ikke kunne nå dem over HTTP.

2. Et certifikat udløber

Uden HSTS klikker brugere nogle gange videre gennem certifikatadvarsler. Det er ikke god sikkerhedspraksis, men det sker.

Med HSTS tillader moderne browsere ikke en nem omgåelse af certifikatfejl for den host. Det er pointen. Det betyder også, at certifikatfornyelse skal være kedelig, overvåget og testet.

3. Staging eller interne værktøjer ligger under produktionsdomænet

At placere interne værktøjer under *.example.com kan blive smertefuldt, når det overordnede domæne bruger includeSubDomains. Hvis disse værktøjer bruger selvsignerede certifikater, private certifikatmyndigheder, gamle TLS-konfigurationer eller slet ingen HTTPS, vil HSTS afsløre genvejen.

Det er én grund til, at mange teams holder interne og eksperimentelle systemer under et separat domæne, der har sin egen sikkerhedspolitik.

4. Preload behandles som et rutinemæssigt afkrydsningsfelt

HSTS preload er ikke bare endnu et direktiv. Det betyder, at dit domæne kan blive leveret inde i browsere som HTTPS-only, før nogen bruger har besøgt dit site.

Det lukker hullet ved “første besøg”, men det er meget sværere at fortryde. Fjernelse fra preload-lister kan tage uger eller måneder om at nå brugere, afhængigt af browsernes udgivelsescyklusser. Preload er passende for stabile, modne domæner. Det er ikke passende for et site, der stadig er ved at opdage sin subdomænebeholdning.

En sikker udrulningsplan

Step 1: Gennemgå hvert hostname, du kontrollerer

Før du sætter includeSubDomains, skal du liste hvert hostname under domænet. DNS-records er en start, men ikke hele historien. Tjek CDN-konfigurationer, hostingdashboards, email-relaterede hostnames, gamle marketingværktøjer, storage buckets og intern dokumentation.

For hvert hostname skal du svare på:

• Serverer det HTTP, HTTPS eller begge dele?
• Er HTTPS-certifikatet gyldigt og automatisk fornyet?
• Omdirigerer det HTTP til HTTPS rent?
• Skal det være offentligt?
• Er der stadig brug for det?

Hvis dit team allerede har vaner for debugging af produktionsheaders, passer dette naturligt sammen med redirect- og header-tjek. Vi dækkede den arbejdsgang i et lille toolkit til debugging af redirects og HTTP-headers i produktion.

Step 2: Ret HTTPS, før du tilføjer HSTS

HSTS gør ikke en ødelagt HTTPS-opsætning sikker. Det gør kun HTTPS obligatorisk.

Før du aktiverer det, skal du verificere:

• TLS-certifikater dækker de korrekte hostnames.
• Certifikater fornyes automatisk.
• HTTP omdirigerer til HTTPS med et enkelt rent hop, hvor det er muligt.
• Kanoniske host-redirects er konsekvente, for eksempel non-www til www, eller omvendt.
• Applikationsassets afhænger ikke af usikre http:// URLs.

Mixed content er mindre almindeligt, end det var før, men det dukker stadig op i gamle CMS-temaer, analytics-snippets, indlejrede medier og hårdkodede billedstier.

Step 3: Start med en meget kort max-age

Begynd ikke med ét år. Begynd med fem minutter:

Strict-Transport-Security: max-age=300

Udrul det kun på det hostname, du tester, typisk det kanoniske produktionswebsite. Udelad includeSubDomains indtil videre.

Test derefter i rigtige browsere og med kommandolinjeforespørgsler:

curl -I https://example.com

Du bør se præcis én Strict-Transport-Security-header. Duplikerede HSTS-headers fra en app-server og et CDN er en almindelig kilde til forvirring. Browsere anvender generelt den effektive politik, men mennesker, der debugger en hændelse, har ikke brug for tvetydighed.

Step 4: Øg gradvist

Hvis intet går i stykker, kan du øge varigheden i etaper:

Strict-Transport-Security: max-age=86400

Derefter:

Strict-Transport-Security: max-age=604800

Og måske derefter:

Strict-Transport-Security: max-age=2592000

En praktisk tidsplan er:

• 5 minutter
• 1 dag
• 1 uge
• 1 måned
• 6 måneder eller 1 år

Der er ingen præmie for at skynde sig. Hele pointen med trinvis udrulning er at give din overvågning, supportindbakke og edge cases tid til at fortælle dig, hvad din tjekliste overså.

Step 5: Tilføj kun includeSubDomains, efter auditten er reel

Når hvert offentligt subdomæne er HTTPS-klar, kan du overveje:

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

Dette er tidspunktet til at være konservativ. Hvis én legacy-tjeneste stadig har brug for HTTP, skal du ikke tilføje includeSubDomains til det overordnede domæne. Migrér enten den tjeneste, flyt den til et andet domæne, eller acceptér, at din HSTS-politik må forblive smallere indtil videre.

Sikkerhedsheaders bør afspejle virkeligheden. De bør ikke bruges som motivationsplakater for infrastruktur, du håber at have senere.

Step 6: Behandl preload som et separat projekt

Overvej kun preload, når alt det følgende er sandt:

• Domænet og alle subdomæner understøtter gyldig HTTPS.
• HTTP omdirigerer til HTTPS.
• HSTS-headeren bruger max-age på mindst 31536000 sekunder.
• Headeren inkluderer includeSubDomains.
• Headeren inkluderer preload.
• Du er sikker på, at du ikke får brug for almindelig HTTP nogen steder under domænet.

En preload-klar header ser sådan ud:

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

Indsendelse til preload-listen er en langsigtet forpligtelse. Hvis sitet er et kampagne-microsite, et midlertidigt produktdomæne eller et domæne med uklare ejerskabsgrænser, så spring det over.

Konfigurationseksempler

Nginx

Brug always, så headeren også sendes på fejlsvar:

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

Når udrulningen er stabil:

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

Apache

Med mod_headers aktiveret:

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

Senere:

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

CDN eller edge-platform

Hvis dit CDN sætter response headers, er det bedst at administrere HSTS ét sted. Sæt ikke én politik ved origin og en anden ved edge, medmindre du har en meget klar grund.

Tjek også, om CDN’et anvender headers på redirects, cachede fejl og brugerdefinerede fejlsider. Et produktionssite er ikke kun dets 200 OK-svar.

Sådan fortryder du HSTS sikkert

Hvis du har brug for at deaktivere HSTS, skal du sende:

Strict-Transport-Security: max-age=0

Men der er en hage: Browseren skal kunne nå sitet over gyldig HTTPS for at modtage den header. Hvis HTTPS i sig selv er ødelagt, kan brugere med en cachet HSTS-politik ikke hente den instruktion, der ville rydde den.

Den sædvanlige genopretningsrækkefølge er derfor:

1. Gendan gyldig HTTPS.
2. Servér Strict-Transport-Security: max-age=0.
3. Hold den på plads længe nok til, at tilbagevendende brugere modtager den.
4. Fjern eller erstat headeren, efter hændelsen er løst.

Hvis domænet er preloaded, er det ikke nok at servere max-age=0 for nye browserprofiler. Du skal også anmode om fjernelse fra preload-listen og vente på, at ændringen leveres gennem browseropdateringer.

Tjekliste til test, før du shipper

Brug denne tjekliste, før du øger max-age eller tilføjer includeSubDomains:

• Den kanoniske HTTPS URL returnerer et gyldigt certifikat.
• HTTP omdirigerer til HTTPS.
• Der er kun én HSTS-header.
• Headeren vises på redirects og fejlsvar, hvor det er relevant.
• Alle offentlige subdomæner har gyldig HTTPS.
• Certifikatfornyelse er overvåget.
• Intet kritisk internt system afhænger af HTTP under det samme overordnede domæne.
• Preload er blevet diskuteret eksplicit, ikke tilføjet af vane.

Lighthouse kan også markere manglende eller svage sikkerhedsheaders i nogle sammenhænge, men det bør ikke være din eneste verifikationsmetode. Hvis du bruger det som del af en bredere gennemgang, så læs resultaterne som signaler frem for domme; den samme tankegang gælder, når du læser en Lighthouse-rapport uden at gå i panik.

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

💡 Prøv dette: Før og efter hver HSTS-ændring skal du inspicere Strict-Transport-Security-svaret med Get Headers for at bekræfte, at max-age, includeSubDomains og preload er, som du forventer.

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

Privatlivsargumentet for HSTS

HSTS fremstilles ofte som en sikkerhedsheader, og det er det. Det har også en privatlivsfordel: Det reducerer risikoen for, at en brugers første forespørgsel lækker over almindelig HTTP på et upålideligt netværk.

Det betyder noget på lufthavns-Wi-Fi, hotelnetværk, virksomheders gæstenetværk og alle steder, hvor en brugers trafik kan blive observeret eller ændret. En almindelig HTTP-forespørgsel kan afsløre hostname, sti, cookies uden Secure-flaget og andre forespørgselsdetaljer. HTTPS er ikke magi, men ved konsekvent at gennemtvinge det fjernes en hel klasse af undgåelig lækage.

De bedste HSTS-udrulninger er uinteressante. De rulles langsomt ud, understøttes af pålidelige certifikater og er kedelige nok til, at ingen lægger mærke til dem. Det er præcis, hvad du ønsker af en header, hvis fejltilstand kan være dramatisk.