Slik sikrer du nettstedet med HTTPS

Stadig flere nettsteder velger å sende dataene over krypterte HTTPS-forbindelser (Hypertext Transfer Protocol Secure) framfor HTTP, hvor alle dataene sendes i klartekst. Det er flere fordeler med dette. Krypteringen gjør at dataene som overføres i utgangspunktet ikke kan avlyttes. Men HTTPS gjøre det også mulig for nettleserbrukere å se om nettstedet de besøker, er det det utgir seg for å være og ikke en forfalskning.

Men som vi har skrevet om i en tidligere Digi Ekstra-sak, er heller ikke HTTPS nødvendigvis sikkert nok alene. Men det er helt klart bedre enn ingen beskyttelse.

For nettsteder som ønsker å ta i bruk den nyeste webteknologien, er det i mange tilfeller et krav om at websider og -applikasjoner leveres over HTTPS. Uten dette vil ikke teknologiene fungere. Eksempler på dette er komprimeringsteknologien Brotli og bruken av posisjonsdata fra Geolocation API.

Kan bli et krav

I tiden framover vil dessuten flere nettlesere begynne å varsle brukeren om at websiden de besøker er usikker dersom den inneholder innloggingsfelter eller ber om kredittkortinformasjon. En slik advarsel kan være avskrekkende for brukerne og lite gunstig for nettstedeierne.

Dersom man forsøker å lese seg opp på hva som kreves for å ta i bruk HTTPS på et nettsted, er det fort gjort å føle seg litt utilstrekkelig. Det er mange detaljer og begreper som det kan være lurt å sette seg inn i. Men det er sjelden slik at man behøver å vite alt for å få det til.

I denne artikkelen skal vi gå relativt raskt gjennom hva som må gjøres for å ta i bruk HTTPS på et nettsted på en server man har mer eller mindre full tilgang til, i alle fall i den grad at man kan få utført kommandoer på den, samt endre enkelte deler av oppsettet til webserverprogramvaren.

Hovedtrekkene er vanligvis de samme på tvers av webserverprogramvare og operativsystem.

Les også: – Bare et tidsspørsmål før Google og Mozilla vil kreve sikre websider

Nøkkelpar

Selv om krypteringsteknologien som benyttes i forbindelse med HTTPS ofte omtales som SSL (Secure Sockets Layer), så er dette i stadig større grad uriktig. SSL har for lengst blitt erstattet av den mer moderne og sikrere TLS-teknologien (Transport Layer Security), og det er i dag ingen grunn til at webservere skal tilby støtte for SSL med mindre man vil støtte svært gamle nettlesere. Selv TLS 1.0 bør unngås, da denne versjonen har minst én stor svakhet.

Både SSL og TLS benytter en tilnærming hvor det benyttes et nøkkelpar, en offentlig nøkkel og en privat nøkkel. I praksis fungerer det slik at data som har blitt låst (kryptert) med den offentlige nøkkelen bare kan låses opp igjen (dekrypteres) med den private nøkkelen. Den offentlige nøkkelen er akkurat det – offentlig – og brukes av motparten til å kryptere data som skal oversendes eieren av nøkkelparet.

Dette er riktignok en veldig forenklet beskrivelse av det som egentlig foregår når en HTTPS-forbindelse etableres. Men det er ikke nødvendig å kjenne detaljene for å konfigurere webserveren til å ta i bruk HTTPS.

Det som derimot er viktig å vite, er at den private nøkkelen må holdes hemmelig. Lekkes denne, vil uvedkommende kunne dekryptere de krypterte dataene.

Derfor lagres den private nøkkelen på en godt beskyttet måte på serveren, men den offentlige nøkkelen distribueres, som en del av sikkerhetssertifikatet, til alle som ber om den.

Hvordan lage nøkkelparet?

Alt man egentlig behøver for å komme i gang, er nøkkelparet og det som kalles for en «Certificate signing request» (CSR), altså en forespørsel om å få signert et sertifikat.

Til de fleste aktuelle operativsystemer, inkludert Windows, finnes verktøyet openssl. Med dette kan man enkelt generere både nøkkelparet og CSR-en, men i praksis blir den offentlige nøkkelen en del av CSR-en.

Kommandoen nedenfor, som kan skrives inn i et kommandolinje- eller ledetekstverktøy, anbefales av mange. Den innebærer at det brukes en nøkkellengde på 2048 bit.

Med kortere nøkkellengde enn dette, for eksempel 1024 bit, må man gå ut fra at forbindelsen kan knekkes av aktører med betydelig evne og vilje. Ønsker man en enda lenger nøkkel, kan man erstatte 2048 med 4096 i kommandoen nedenfor.

openssl req -sha256 -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

Vi har også spesifisert at vi ønsker å bruke SHA256-algoritmen siden den vanlige SHA1-algoritmen, som openssl bruker som standard, ikke regnes som særlig sikker lenger.

Når man kjører denne kommandoen, blir man bedt om å svare på en rekke spørsmål. Det aller viktigste å få rett, er spørsmålet om Common Name, som egentlig er vertsnavnet til nettstedet som skal benytte HTTPS. Dersom man ønsker å bruke det samme sertifikatet til flere ulike subdomener, kan skrive «*.domenenavn.no» eller tilsvarende. Det finnes også multidomene-sertifikater, men vi kommer ikke til å komme nærmere inn på slike i denne artikkelen.

En del av spørsmålene finnes det kanskje ikke noe svar på. Disse kan man ignorere ved å gi et blankt svar.

Når kommandoen er ferdig med å kjøre, har det blitt generert to tekstfiler: CSR.csr som selvfølgelig inneholder CSR-en, og privateKey.key som inneholder den private nøkkelen.

Openssl-alternativer

Det finnes alternativer som gjør den samme jobben som openssl i dette tilfellet. For eksempel tilbyr StartCom et fleksibelt verktøy til Windows som genererer de samme filene. Velg CSR-fanen i verktøyet, skru på «Professional Mode», og full ut skjemaet.

For øvrig gjør man lurt i å la være å benytte StartCom som sertifikatutsteder, av årsaker som er omtalt her.

En del hostingleverandører og andre tilbyr å generere CSR-en og nøklene som en tjeneste. Dette er kanskje enklere enn metodene beskrevet over, men frarådes på det sterkeste, siden man ikke lenger har full kontroll over hvem som har tilgang til privatnøkkelen.

Sertifikatet

Når nøklene og CSR-en har blitt generert, har turen kommet til å få utstedt sertifikatet. Da må man ta kontakt med en sertifikatutsteder (CA - Certificate Authority) som vil be om å få tilsendt CSR-en og annen, nødvendig informasjon.

I utgangspunktet koster det penger å få utstedt et sertifikat, men som vi kommer tilbake til litt senere i artikkelen, er det også mulig å få utstedt sertifikater av den enkleste sorten helt gratis.

Hos sertifikatutstedere som tar betalt for utstedelsen, er det flere faktorer som er med på å avgjøre prisen. Ofte tas det ekstra betalt for å støtte mer enn et subdomene, og multidomene-sertifikater koster gjerne enda mer.

Validering

En annen faktor som spiller inn, er hvilket valideringsnivå man har behov for.

Mange klarer seg med det enkleste, hvor det er tilstrekkelig at den som søker om sertifikatet, faktisk kontrollerer det. Dette kan gjøres ved at man for eksempel gjør en spesiell fil tilgjengelig på nettstedet eller at man har tilgang til epost som er sendt til kontoer som webmaster@domene.no eller postmaster@domene.no. Denne typen sertifikater kan gjerne utstedes i løpet av minutter eller timer.

Nivået over er vanligvis sertifikater med organisasjonsvalidering. Her blir ikke bare domeneeierskapet, men også detaljer om eieren, slik som organisasjonsnavn og fysisk adresse, autentisert. Det tar lenger tid å utføre en slik validering, vanligvis fra noen timer til noen dager.

Det øverste nivået er Extended Validation (EV). Her gjøres det en enda strengere validering av virksomheten som eier nettstedet, i henhold til regler som er utarbeidet av CA/Browser Forum. Det er enkelt å kjenne igjen nettsteder som har EV-sertifikat, fordi det juridiske navnet på eieren gjerne vises i adressefeltet, som i noen nettlesere også blir grønt.

Mer å passe på

I utgangspunktet har sertifikater vanligvis en levetid på ett år før de må fornyes, men hos mange kan man bestille sertifikater som ikke behøver å fornyes i alle fall tre år.

Når man etter en stund mottar sertifikatet, må dette og privatnøkkelen gjøres tilgjengelig for webserveren, som dessuten må settes opp til slik at nettstedet blir tilgjengelige via HTTPS. Ofte må man også inkludere et eller flere mellomliggende («intermediate») sertifikater på serveren. Dette er i så fall noe som tilbys av sertifikatutstederen.

Detaljene varierer såpass mye mellom de ulike webserverne at det blir for omfattende å gå i detalj på dette her.

Men mer eller mindre gode oppskrifter på dette er tilgjengelig for blant annet Apache HTTPD, nginx, IIS og ns.js.

Let's Encrypt, et enklere alternativ

For nettsteder som klarer seg med den enkleste sertifikatvalideringen, altså bare validering av domenet, har Let's Encrypt vokst fram som et glimrende alternativ. Ikke bare er det gratis, men den foretrukne måten å bruke et program som ikke bare gjør genereringen av nøkler og sertifikater til en lek, men som også til en viss grad kan sørge for å konfigurere webserveren til å bruke sertifikatet og nøkkelen.

Verktøyet heter Certbot og er utviklet av Electronics Frontier Foundation (EFF), en av initiativtakerne til Let's Encrypt. Det eneste brukeren behøver å gjøre etter å ha installert verktøyet, er å skrive inn domenenavn og subdomener som sertifikatet skal gjelde for. Deretter gjøres alt helt automatisk, bortsett fra at brukeren må bekrefte et par valg.

Certbot er tilgjengelig for Linux, macOS og andre Unix-lignende operativsystemer. Det støtter først og fremst webserverne Apache, nginx, Haproxy og Plesk.

Selv om Certbot er enkel å bruke, har det visse mangler. For eksempel støtter det ikke at flere virtuelle verter er konfigurert i én og samme fil, i alle fall dersom det er Apache som brukes. De virtuelle vertene som skal bruke Let's Encrypt, må være oppgitt i separate konfigurasjonsfiler.

Certbot utnytter Let's Encrypts støtte for protokollen ACME (Automatic Certificate Management Environment) for den automatiske utstedelsen av sertifikatene. For brukere som av ulike grunner ikke kan bruke Certbot, finnes det en rekke andre verktøy, inkludert webbaserte og Windows-baserte, som i alle fall kan sørge for genereringen av nøkler og sertifikatet.

Automatisk fornyelse

Det er likevel en stor fordel med Certbot. For sammenlignet med de fleste andre TLS-sertifikater, er levetiden til Let's Encrypt-sertifikatene begrenset til 90 dager. Da må de fornyes. Selv om dette altså er enkelt, må det gjøres langt oftere enn med andre sertifikater. Og mange har allerede opplevd at de eller andre har glemt å fornye slike sertifikater i tide.

Med Certbot kan også fornyelsen av sertifikatene gjøres helt automatisk. Det eneste man må gjøre er å sørge for at Certbot-kommandoen for å kontrollere og fornye sertifikatet, blir kjørt med jevne mellomrom – det anbefalte er hver 12. time. Dette kan gjøres ved å opprette en cron- eller systemd-jobb på de systemene som Certbot støtter.

Nødvendig «småfiksing»

For at brukerne skal kunne ta i bruk HTTPS-forbindelsen hver gang de kommer på besøk, uavhengig av om de skriver HTTPS først adressen eller klikker på en gammel lenke til sidene, så må alle forsøk på å laste ned websidene via HTTP bli omdirigert til en tilsvarende HTTPS-adresse.

Alle webservere har støtte for slik omdirigering eller omskrivning av adressene. Eksempelet nedenfor gjelder for Apache og kan for eksempel legges i en .htaccess-fil i dokumentroten til nettstedet.

RewriteEngine OnRewriteCond %{HTTPS} !=onRewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Dessuten bør man sørge for at ingen interne lenker er hardkodet til å bruke HTTP. Enten må man droppe vertsnavnet i adressen og starten URL-en med noe slikt som:

/index.html

Ellers bør man velge en protokoll-relativ URL hvor protokollen som brukes er den samme som er brukt på den siden URL-en er oppgitt på. Slike URL-er har et format tilsvarende og oppgir altså ikke hvilken protokoll som skal brukes.

//example.com/index.html

For større nettsteder kan det å rydde opp i slike absolutte URL-er utgjøre den største jobben med å få nettstedet til å fungere med HTTPS.

Videre sikring

All bruk av HTTPS er i utgangspunktet bedre enn bare HTTP. Men selv om man nå kanskje har fått satt opp en HTTPS-forbindelse basert på standardkonfigurasjonen til webserverprogramvaren, vil det ofte være behov for ytterligere forsterkning.

I en del tilfeller inkluderer standardkonfigurasjonen støtte for krypteringsteknologier som i dag anses som usikre. Et godt sted å starte er å teste nettstedet med SSL Server-testen til Qualys. Da får man en tilstandsrapport som forteller om eventuelle mangler og lenker til hvordan manglene kan utbedres.

Mange av tiltakene man kan gjøre, er ganske enkle. Det viktigste er nok likevel å deaktivere støtten for de gamle SSL-protokollene og å bare støtte det som til enhver tid anses som sikre chiffersamlinger. En liste over chiffersamlingene som anbefales, finnes på denne siden, sammen med en del andre tips og råd.

En enkel, men kanskje ikke helt oppdatert oppskrift på hvordan dette gjøres i både Apache og nginx, finnes på denne siden.