Slik aktiverer du HSTS uten å stenge nettstedet

HSTS er en nettleserpolicy med lang hukommelse. Riktig brukt hindrer den at en kjent HTTPS-side senere åpnes over HTTP. Feil brukt kan den gjøre gamle, interne eller glemte subdomener utilgjengelige i måneder.

Aktiver derfor ikke denne kopierte standardlinjen som første steg:

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

Begynn med å forstå rekkevidden og velg en utrulling dere kan stoppe mens konsekvensene fortsatt er små.

Hva gjør HSTS?

En HTTPS-respons kan sende headeren:

Strict-Transport-Security: max-age=300

Når nettleseren mottar den over en gyldig HTTPS-forbindelse, lagrer den en policy for vertsnavnet i 300 sekunder. I denne perioden vil nettleseren:

• endre senere http://-forsøk til HTTPS før nettverksforespørselen sendes
• bruke HTTPS også når brukeren skriver en HTTP-adresse
• nekte brukeren å klikke forbi en ugyldig sertifikatforbindelse

Headeren beskytter ikke den HTTPS-responsen som leverte den, og nettleseren ignorerer HSTS sendt over HTTP. HTTP-endepunktet bør fortsatt svare med en direkte permanent redirect til riktig HTTPS-adresse.

MDN beskriver hvordan nettleseren lagrer HSTS, oppgraderer URL-er og gjør TLS-feil uomgåelige .

Hva betyr direktivene?

HSTS identifiserer en host ved domenenavn, ikke IP-adresse. En policy på portal.bedrift.no gjelder ikke automatisk bedrift.no. En policy på bedrift.no med includeSubDomains kan derimot omfatte både portal.bedrift.no og api.portal.bedrift.no.

Hvert underdomene bør sende sin egen HSTS-header når det tåler policyen. En bruker kan besøke underdomenet direkte uten først å ha lastet rotdomenets includeSubDomains-policy.

Før utrulling

Lag en liste over alle navn under domenet, også:

• interne navn som kan åpnes fra vanlige nettlesere
• gamle kampanje- og leverandørdomener
• e-post-, autokonfigurasjons- og innloggingsnavn
• utviklings- og stagingmiljøer
• navn på dypere nivå enn *.bedrift.no
• DNS-wildcards som kan sende ukjente navn til en standardtjeneste

Kontroller for hvert relevant navn:

• gyldig sertifikat og full kjede
• riktig navn i sertifikatet
• direkte HTTP-til-HTTPS-redirect
• ingen mixed content
• fungerende fornyelse og ekstern utløpsvarsling
• dokumentert eier og gjenopprettingsvei

includeSubDomains krever ikke ett wildcardsertifikat. Hvert navn kan bruke sitt eget sertifikat. Det viktige er at alle navn som skal være tilgjengelige, faktisk kan leveres sikkert over HTTPS. Se hva et wildcard dekker og ikke dekker .

En utrulling som kan stoppes

Den offisielle preload-tjenesten anbefaler å øke max-age i trinn og vente hele perioden mellom trinnene. En forsiktig produksjonsplan er:

1. Aktiver max-age=300 uten preload. Overvåk feil og forretningskritiske funksjoner.
2. Øk til max-age=604800 når femminuttersperioden har vært stabil.
3. Øk til max-age=2592000 etter en stabil uke.
4. Vent hele måneden, rett avvik og vurder deretter en lengre policy.
5. Legg bare til includeSubDomains når inventaret viser at hele domenet tåler det. Kjør samme trinnvise plan på nytt.
6. Vurder preload separat og sist.

Eksempel på første trinn:

Strict-Transport-Security: max-age=300

Eksempel når hele domenet er kontrollert og virksomheten har valgt ett år:

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

Test headeren på den eksterne responsen fra CDN eller proxy, ikke bare i en lokal konfigurasjonsfil. Kontroller også redirects, feilresponser og andre ruter som kan leveres av en annen komponent.

Hva HSTS ikke løser

HSTS:

• utsteder eller fornyer ikke sertifikatet
• retter ikke mixed content i siden
• velger ikke en sikker TLS-profil for serveren
• beskytter ikke databasen eller applikasjonen mot innbrudd
• erstatter ikke Secure på cookies
• hindrer ikke phishing på et annet, lignende domene
• beviser ikke at virksomheten bak siden er legitim

HSTS sikrer transportvalget i nettleseren. Resten av sikkerhetsarbeidet består fortsatt. Bruk TLS- og sertifikatguiden for grunnlaget og HTTPS-feilsøkingen hvis en HSTS-host er blokkert.

Bør dere bruke preload?

Preload løser førstegangsproblemet ved å levere en liste med HTTPS-only-domener i selve nettleseren. Men den offisielle tjenesten sier nå at HSTS anbefales, mens preload ikke anbefales som standard. Mange nettlesere oppgraderer allerede HTTP-navigasjoner automatisk, og den ekstra gevinsten må veies mot en vanskelig reversering.

For innmelding krever preload-tjenesten blant annet:

• gyldig sertifikat
• HTTP-til-HTTPS-redirect på samme host
• HTTPS på alle underdomener, også interne navn
• HSTS på rotdomenet med minst ett års max-age
• både includeSubDomains og preload
• separat innsending til preload-tjenesten

Å skrive preload i headeren legger ikke domenet automatisk inn i nettleserne. Og fjerning går ikke raskt: tjenesten advarer om at en endring kan bruke måneder på å nå brukere, uten garanti for tidslinjen i andre nettlesere.

Les utrullingsplanen, innmeldingskravene og advarselen mot preload som standard før dere tar beslutningen.

Hvordan ruller dere tilbake?

For en vanlig, ikke-preloadet policy kan serveren sende:

Strict-Transport-Security: max-age=0

Dette virker bare når nettleseren klarer å opprette en gyldig HTTPS-forbindelse og mottar headeren. Hvis sertifikatet allerede er ugyldig, kan dere ikke slå av HSTS over HTTP for å komme rundt problemet.

Separate HSTS-policyer som underdomener tidligere har sendt, lagres uavhengig. Å fjerne policyen på rotdomenet sletter derfor ikke automatisk alle underdomenepolicyer. For et preloadet domene må dere i tillegg følge tjenestens fjerningsprosess og fortsatt regne med lang overgangstid.

HSTS for en side levert av Vymo

På den enkle bedriftsnettsiden Vymo setter opp og hoster, styres HTTPS- og responsheadere av plattformleveransen. Kunden har foreløpig ikke et selvbetjent panel for HSTS eller sertifikater.

Har virksomheten et konkret krav til HSTS, includeSubDomains eller preload, må alle berørte subdomener kartlegges før policyen endres. Send oss domenelisten og kravet i stedet for å aktivere en langvarig policy uten konsekvensanalyse.