HTTPS er ikke sikkert nok alene. Her ser du hvorfor

Internett er et fiendtlig sted hvor mange forsøker å overliste alle som våger seg utpå nettet. I dag er det de aller fleste.

Derfor jobber de på den «snille siden» iherdig med å komme med tiltak som i alle fall kan bidra til at slik overlisting blir vanskeligere.

Mange nettsteder har nå tatt i bruk krypterte og sikre forbindelser, gjerne kjent som HTTPS. Uten kryptering sendes alle data som klartekst, noe som betyr at alle som har tilgang til forbindelsen på veien mellom nettleseren og serveren, kan avlytte eller manipulere dataene som overføres – i begge retninger.

Stadig flere tar i bruk HSTS: For første gang var over halvparten av sidevisningene med HTTPS

«Mannen i midten»

Problemet er at bruken av HTTPS alene ikke kan sikre at forbindelsen er kryptert hele veien.

La oss si at du taster inn adressen til nettbanken din i adressefeltet til nettlesere, omtrent som dette:

nettbanken.no

altså bare domenenavnet, uten http eller https foran.

Mange banknettsteder vil umiddelbart dirigere om til en HTTPS-forbindelse, fordi nettstedet ikke tilbyr innhold over HTTP. Noen banker, som Nordea, tilbyr deler av nettstedet via både HTTP og HTTPS, men selve nettbanken er selvfølgelig kun tilgjengelig via HTTPS.

Dersom en angriper kan avskjære forbindelsen mellom deg og nettbanken, så kan angriperen ved hjelp av kjente verktøy ta imot din forespørsel til banken – en forespørsel som ikke sier noe om hvilken protokoll som skal brukes – og deretter fungere som en mellommann som tar imot og videresender spørringer og svar fra begge parter.

Selv om nettbanken i utgangspunktet omdirigerer alt til HTTPS, så gjelder dette bare forbindelsen mellom nettbanken og angriperen. Mellom angriperen og offeret har krypteringen blitt strippet vekk, slik at dataene sendes åpent.

Det er fullt mulig å hindre slike angrep, men da må offerets nettleser få beskjed om at forbindelsen skal være kryptert, uansett hva en mellommann måtte finne på.

Les også: Ny webstandard kan blokkere farlig JavaScript

HSTS

Det er her sikkerhetsteknologien HTTP Strict Transport Security (HSTS) kommer inn. Teknologien støttes av alle nyere nettlesere, inkludert Internet Explorer 11 for Windows 7 og nyere.

Det HSTS gjør, er å fortelle nettleseren at forbindelsen med serveren skal være HTTPS-basert og ikke kunne nedgraderes til HTTP. Dette gjøres ved at serveren sender en HTTP-header til nettleseren, som forteller den at all kommunikasjon med det aktuelle domenet skal skje ved hjelp av HTTPS.

Nå er det selvfølgelig mulig for en angriper å filtrere vekk denne headeren før dataene sendes videre til offeret. Men det er mulig for nettstedet å beskytte brukerne mot dette også.

Dersom en nettleser allerede har mottatt en HSTS-header fra et domene, vil den kunne ta vare på beskjeden om kun å bruke HTTPS i lang tid framover. Hvor lenge, avhenger av et forfallstid som er oppgitt i headeren.

Et forsøk på å degradere HTTPS til HTTP, slik som beskrevet over, vil dermed ikke lykkes.

En slik header vil typisk kunne se slik ut:

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

Her er utløpstiden satt til å være et 365 dager (oppgitt i sekunder). Direktivet includeSubDomain er valgfritt og forteller at også alle de eventuelle underdomenene skal kunne kontaktes med HTTPS.

Men det er også mulig å beskytte brukere som ennå ikke har mottatt en slik header fra nettstedet de vil besøke, eller som har fått slettet tidligere lagret HSTS-informasjon.

De fleste nettlesere har nemlig en egen liste med domener som har tatt i bruk HSTS. I utgangspunktet er det Google som administrerer listen, men de andre nettleserne forhåndslaster lister som er basert på listen til Google.

For å komme med på denne listen, må man selv legge til domenet sitt i et skjema på denne siden. Chrome har i tillegg et eget administrasjonsskjema innebygd på denne siden.

Før man sender inn skjemaet, må HSTS-headeren fra webserveren inkludere et preload-direktiv. I tillegg må includeSubDomains-direktivet også være inkludert. Dermed vil headeren se omtrent slik ut:

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

Googles liste inkluderer mange tusen domenenavn, men under hundre .no-domener. Store tjenester som Facebook, Twitter og Paypal har tatt i bruk HSTS, men knapt noen norske nettbanker.

Mot slutten av denne siden finnes det beskrivelser av hvordan ulik webserverprogramvare, inkludert Apache, IIS og nginx, kan konfigureres for å ta i bruk HSTS.

Etter kritikk: De norske nettbankene skjerpet seg

Forholdsregler

Når man for første gang tar i bruk HSTS for et domene, bør man sørge for at utløpstiden er kort, gjerne bare noen få minutter. Dersom noe går galt, vil HSTS-informasjonen som nettlesere har mottatt, utløpe temmelig raskt.

I motsatt fall, dersom noe går galt etter at man har satt en lang utløpstid og mange av brukerne har mottatt den med sine nettlesere, er det i praksis ingen retrettmulighet via HTTP. Setter man lang utløpstid, må man også være sikker på at man greier å støtte HTTPS kontinuerlig i lang tid framover.

Med HSTS aktivert, vil det for eksempel ikke være mulig å omgå advarsler om utløpte eller usikre TLS-sertifikater i nettleseren. Å glemme å fornye slike sertifikater i tide kan tydeligvis skje hvem som helst. Både Google, Microsoft, Apple og Instagram skal være blant dem som har glemt dette i løpet av de siste årene.

Man kan riktignok redusere utløpstiden HSTS, og ved å sette max-age til 0 kan man resette verdien som er lagret i nettleseren. Men dette må gjøres via HTTPS.

Enda mer sikker på at man kan tilby HTTPS i lang tid framover, må man være før man melder nettstedet inn i preload-listen til Google. Verdiene i denne listen blir hardkodet inn i kildekoden til nettleseren. I alle fall Google opplyser at det kan gå måneder før en oppdatering i HSTS-verdiene når den stabile utgaven.

Men heller ikke HSTS er uproblematisk: HTTPS kan gi supercookie

Få med deg alle Ekstra-sakene i arkivet her »