Hvis du ikke vil bli valgt vekk – velg HTTPS!

Grovt regnet finnes det ca. 400 millioner aktive nettsteder. Litt over halvparten av nettstedene på Alexa sin liste av topp 1 million mest besøkte nettsteder bruker HTTPS. Selv om det finnes noe usikkerhet i dette tallet viser det at omtrent halvparten av nettstedene ikke er tilstrekkelig sikret. Her følger en innføring i HTTPS og hva som skal til for å sikre ditt nettsted.  

Hvorfor trenger man HTTPS?

HTTPS er grunnsteinen for å lansere et sikkert nettsted. All trafikk som kommer over HTTP regnes som utrygg, da den kan ha blitt endret underveis. Bare for et par år siden ble implementering av HTTPS rutinemessig nedprioritert, med argumenter som at sertifikater var dyre og HTTPS var tregt i forhold til HTTP. Heldigvis har vi nå flere gode ressurser som motbeviser disse argumentene, som DoesMySiteNeedHttps (om hvorfor man alltid bør bruke HTTPS) og HttpVsHttps (lastetid over HTTP mot en versjon av HTTPS).

HTTPS gjør at en sesjon av kommunikasjon mellom nettleser og nettsted skjer ved å sende krypterte data. Krypteringen sikrer at data man sender ikke kan leses av andre. Det sikrer også at man ikke kan bli utsatt for «man in the middle» angrep der en angriper fanger opp trafikk mellom to maskiner og dermed har mulighet til å lese og endre data.

I denne bloggposten setter jeg opp HTTPS på et nettsted som kjører på IIS på en Windows Server. Selv om dette eksempelet ikke sikrer alle deler av et nettsted er det et godt utgangspunkt. I tillegg bør man sikre at alle Iframes, lenker, skjemaer og lignende, også går mot HTTPS, samt alle steder man laster JavaScript og CSS.

Kom i gang

For å sette opp gyldig HTTPS trenger man kun et gyldig sertifikat. Jeg bruker Let’s Encrypt som CA (Certificate Authority), da disse sertifikatene er gratis å benytte, og enkle å sette opp. Ulempen med disse sertifikatene er at de kun er gyldige i 3 måneder, og må fornyes ganske ofte. Programvare som  Let’s Encrypt win-acme hjelper deg både å sette opp sertifikater, samt sette opp automatisk fornyelse av ett eller flere sertifikater på en server.

Grensesnittet er enkelt, og dersom jeg ønsker et sertifikat for nettstedet som har SiteId 22, trykker man enkelt følgende taster:
N => Nytt sertifikat
1 => Jeg ønsker kun et sertifikat for et nettsted.
1 => Sertifikatet skal gjelde for dette nettstedet.
I dette tilfellet ville jeg fått en BadRequest fordi dev.local ikke er et offentlig domene suffiks. Men dette er framgangsmåten for alle oppsett av Let’s Encrypt.

Ok, nå har vi et gyldig SSL sertifikat for nettstedet, hva nå?
Videre starter arbeidet med å sette opp slik at innkommende trafikk alltid havner på HTTPs.

Aktivere HTTPS på webserveren, f.eks. på en IIS server vil oppsettet av dette se slik ut:

Her setter vi opp bindingen for domenet på port 443, og gir det sertifikatet som er opprettet 1.10.2018.

Videresending fra HTTP 

Den siste tingen man må ha før HTTPS er gyldig konfigurert, er en videresending fra HTTP. I IIS kan man benytte en modul som heter URL Rewrite. Denne modulen gjør det mulig å videresende all trafikk fra HTTP over til HTTPS. Dette kan enkelt settes opp i IIS og resultatet ser da slik ut:

Men normalt, bruker man IIS som webserver kan man også benytte seg av muligheten til å legge dette i Web.Config, koden for dette ser slik ut:

Sikring av den første forespørselen

Vi har nå et nettsted som kjører gyldig HTTPS på en IIS webserver. Selv om dette dekker kravet for å være gyldig HTTPS, er det en header egenskap jeg ønsker å påpeke viktigheten av. Dette fordi den er utrolig kraftig i det den gjør, og den headeren heter HSTS eller Strict-Transport-Security. Denne headeren forteller nettleseren at neste gang denne siden lastes, skal den kun lastes over HTTPS. Selv om man går til nettsted.com vil nettleseren se at denne har blitt lastet tidligere med HSTS headeren, og derfor vil den automatisk gjøre også den første forespørselen over HTTPS.
Headeren kan legges til slik i IIS:

For å legge denne headeren til via Web.Config kan det gjøres slik:

Forhåndslasting av protokoll

Nå vil nettstedet vårt også hentes over HTTPS det neste året, men vi har en egenskap til vi kan sette på HSTS headeren. Denne gjør at nettleseren på forhånd kan vite at det er HTTPS som skal benyttes.  Denne heter preload, og man kan benytte seg av følgende kode i Web.config:

Med denne konfigurasjonen kan nettstedet bli lagt inn i en liste som nettleseren har over nettsteder som alltid bruker HTTPS. Man må registrere nettstedet sitt manuelt på https://hstspreload.org/ for å havne på den innebygde preload listen i nettleseren. Denne listen oppdateres deretter hver gang det sleppes en ny versjon av nettleseren man benytter. Det er flere krav til hva som må være med for å komme med. Har du gjort som meg, og satt opp HTTPS med den siste headeren, er du faktisk kvalifisert. Det eneste kravet som ikke etterkommes her, er at dette må settes opp på samme måte for alle offentlige subdomener. Det mest brukte offentlige subdomenet er www.

Hvordan dette gjøres på Apache?

Dette er enda enklere i linux verden og med Apache server, og er delt opp i 3 deler: installasjon, opprette SSL-sertifikat og verifisere at den automatiske fornyelsesjobben er satt opp riktig.

For å installere og oppdatere Let’s Encrypt på serveren/maskinen kan følgende kommandoer kjøres:

Deretter har man litt ulike valg når man skal opprette SSL-sertifikatene.
Opprette et enkelt sertifikat for et domene:

Opprette et sertifikat som dekker flere subdomener ved en site:

Denne kommandoen setter opp et sertifikat som er gyldig for både example.com og www.example.com. Når dette er gjort kan man verifisere at sertifikatet er gyldig på:
https://www.ssllabs.com/ssltest/analyze.html?d=example.com&latest

Til slutt kan en verifisere at cron-jobben som skal automatisk fornye sertifikatet fungerer ved å kjøre kommandoen:

Omdirigere fra http til https i Apache kan gjøres ved å legge følgende i /etc/apache2/httpd.conf

For å ligge til fullstendig Strict-Transport-Security med “preload” attributten, kan dette gjøres ved å legge følgende inn i /etc/apache2/sites-enabled/website.conf

DO IT

Dette er noe alle kan gjøre, og det er svært enkelt. Ikke la press på leveringstid og pris påvirke sikkerhetsnivået i løsningen man leverer. Om man alltid leverer kvalitet, er det bare et kort steg for alltid å levere sikkert!