Close
Hänglås (cc-by-cred-david-goehring-flickr)

När ska man använda HTTPS?

Ja, det kan man fråga sig. Tacksamt nog tog Artem Pereverzev upp diskussionen på Slack-kanalen för Webbstrategi för alla. Tacksamt för att jag glömt att skriva om detta trots att vi på min arbetsplats under året pratat en hel del om detta. Jag kan absolut förstå att frågan om HTTPS tenderar att bli väldigt teknisk. Eller att den tas upp av IT- tekniker på ett sätt som gör att alla andra backar undan och hoppas på det bästa.

Därför tänkte jag försöka skriva ihop något lite klargörande, börja med poängen och avsluta med den teknik man kan behöva känna till om man mot förmodan väljer att efterforska ytterligare eller ta den tekniska diskussionen. Det är upp till dig att avgöra om detta blev begripligt eller ännu ett bidrag till den tekniska mumbo-jumbon 🙂

tl;dr – Too long; didn’t read

HTTPS gör att webbkommunikation sker genom en privat och skyddad kanal över internet. En webbplats bör alltid använda HTTPS. Särskilt om man har formulär eller visar upp innehåll som är unik för respektive användare. Annars riskerar man att mellanhänder kan läsa allt i klartext.

“Formulär och känslig info skickas via säker kanal”

När jag skrev boken Webbstrategi för allas sista kapitel om vad man bör kolla på sin egen webbplats formulerade jag denna frågeställning så här:

“När ett formulär på webben postas tillbaka till webbservern sker det ibland på ett sätt som gör att alla fältens innehåll kan läsas i klartext om någon tjuvlyssnar på vad som skickas i nätet. Är det då ett inloggningsformulär kan lösenordet läsas av varje nätverksadministratör som övervakar nätverkets trafik. Men din besökare kan också sitta på ett oskyddat trådlöst nätverk på ett hotell eller råka ut för andra svagheter ofta kallat man in the middle-attacker vilket innebär att illvilliga kan avlyssna allt som skickas. Detta gäller även för webbsidor som besökaren tar emot, inte bara formulär som skickas, och känslig information i sidans innehåll kan teoretiskt sett avläsas vid transporten mellan server och besökarens dator.

Det varje webbplats bör göra är att skydda känslig trafik så det går via protokollet HTTPS. Det innebär att informationen sänds i en krypterad form via SSL/TLS.

Det är viktigt att besökaren själv kan verifiera att trafiken är skyddad så de vågar använda webbplatsen. Därför är det en bra idé att enhetligt köra med HTTPS på hela webbplatsen även om behovet bara finns på delar av webbplatsen. För att kontrollera att information som skickas säkert via egna API till besökarens enhet kan du behöva kontakta en utvecklare.”
– Webbstrategi för alla (2014)

Det handlar om användarens integritet

Så här i ett digitalt samhälle, “post-Snowden”, är det tyvärr tydligt att vi som utgivare av digitalt material behöver visa omsorg om de som väljer att ta del av materialet vi erbjuder.

Om man använder “vanlig” HTTP skickas allt mellan webbplatsen och besökaren i klartext över internet. Vi vet att åtminstone när information passerar landsgränser är många övervakningsmyndigheter väldigt intresserade att ta del av allt de kan komma över. Diskussionen om “rent mjöl i påsen” och varför kan vi ta någon annan gång.

Det är inte bara FRA, GCHQ, NSA med flera statliga övervakare man bör oroa sig för, eller om din användare är utomlands. Det räcker med att din användare har anslutit till ett hotells wifi-nät för att det ska börja bli riskabelt att skicka känsliga uppgifter. Man kan inte vara säker på om någon oönskad part övervakar kommunikationen. Att använda HTTPS är en billig försäkring för att göra den avlyssningen väldigt mycket svårare.

Frågan om HTTPS har vissa likheter med diskussionen om cookies, Google Analytics och tredjeparter i största allmänhet. Den största skillnaden är att om en webbplats spårar sina användare med hjälp av en tredjepart är det oftast (om man följer användarvillkoren) inte någon unik information om användaren som delas med en tredjepart.

Unik, och potentiellt väldigt känslig, information är ofta det som motiverar till att använda HTTPS på en webbplats. Mest klockrena exemplet är väl hur bekväm du är att fylla i en hälsodeklaration på nätet och skicka in om du inte vet vem som får ta del av det du skriver. Det kan i värsta fall vara mycket värre om dessa uppgifter får fötter jämfört med att tredjeparter får veta att man besökt en sida av känslig natur. Som att läsa på om klamydia eller liknande som DN rapporterade om hösten 2015.

“Går man exempelvis in på Centrum för sexuell hälsa vid Skånes universitetssjukhus är några av nyckelorden som skickas ”homosexualitet”, ”klamydia” och ”aids”. Nyckelorden tillsammans med ett unikt id-nummer gör att företaget kan följa besökaren på mängder med andra webbplatser.”
DN.se – Svenska myndigheter lämnar ut dina surfvanor

Praxis på området borde vara att man använder HTTPS på hela webbplatsen om det finns behov av det någonstans. Anledningen till att inte använda HTTPS enbart där det behövs är att din användare kan vilja verifiera att webbplatsen använder en säker kanal innan hen ger sig i kast med att interagera. Det kan ge fel intryck att en webbshop först vid utcheckningen av en kundkorg börjar använda HTTPS, det är inte säkert att man lyckas behålla den säkerhetsmedvetna kunden så långt i processen. Samma sak vid e-tjänster som bygglovsansökan på en kommunsajt.

Ett av få undantag, bland kommunerna, som kör med HTTPS är Uppsala. Något min kloka vän Sebastian Danielsson i deras webbförvaltning säkert är nöjd över, de gör många rätt i största allmänhet i Uppsala.

Vad säger lagen?

Jag är inte jurist, men det är främst Personuppgiftslagen och Patientdatalagen jag tänker på i detta sammanhang. Har du lyxen (som jag har på jobbet) att ha erfarna jurister att rådfråga så kolla ifall de har ett utlåtande åt dig.

För oss lekmän har ofta Datainspektionen vettiga frågor och svar, så klart även om patientdatalagen och en om personuppgiftslagen. Det går faktiskt att ringa dem om man vill ställa kompletterande frågor, det har åtminstone jag lyckats med några gånger.

Kortfattat: En persons hälsotillstånd, sexualitet, religion, politiska åsikter, ursprung etc är känsliga uppgifter som man måste vara mycket försiktig med. Det innebär att det finns regler om hur man får dela med sig och vad som anses vara slarvigt handhavande.

Nackdelar med HTTPS

Säg det goda som inte har någon nackdel. I detta fallet är nackdelar primärt två stycken. Dels blir webbplatsen långsammare för många besökare, men det kostar också pengar att få ett certifikat för att kunna använda HTTPS. Om man är noggrann med begreppen så är det ett SSL-certifikat det handlar om (bra att veta om du ska göra mer efterforskningar). SSL står för Secure Sockets Layer och som namnet antyder är det ett säkert lager – i detta fallet ovanpå vanlig HTTP. SSL används ofta synonymt eller i kombination med TLS (Transport Layer Security).

Köp ett trovärdigt certifikat – eller låt bli

För att börja med certifikatet. De utfärdas, likt ett pass, av en betrodd part och är tänkta att kunna verifieras och vara svåra att förfalska. Tanken är att den organisation som utfärdar certifikatet ska vara trovärdiga, detta blir de genom att inte dela ut certifikat till tveksamma organisationer. Inte sällan kostar ett certifikat någon tusenlapp om man vill ha det från en trovärdig utfärdare.

Det erbjuds ibland certifikat från mindre kreddiga utfärdare. Det är dumsnålt att spara pengar på detta, risken är att det kostar dig väldigt mycket mer när samtliga certifikat från den utfärdaren återkallas. Sånt händer ibland. 2011 blockerades certifikat i flertalet webbläsare på grund av att en organisation (DigiNotar) utfärdat massor med felaktiga certifikat. Det handlar om förtroende, och efter att DigiNotar blivit hackade försvann förtroendet för dem.

Nackdel två – långsammare upplevelse

Genom att webbplatsen och användarens webbläsare har krypterat sin kommunikation blir allt material unikt för varje besökare. Dels för att en viss sida på webbplatsen inte ser likadan ut för två olika användare, men också för att det inte går att inspektera vad sidan innehåller gör att det inte går att använda cache-funktioner.

Ett exempel på var en cache-funktion kan finnas är det nätverk man kopplar upp sig på hos sin arbetsgivare. Det är troligt att delar av populära webbsidor mellanlagras en stund i det lokala nätverket på jobbet. Innebörden är att en artikel från Dagens Nyheter kanske hämtas från det lokala nätverket istället för från DNs webbserver, i alla fall om en kollega precis innan hämtade exakt samma artikel. Detta gör man för att minska organisationens trafik över internet (vilket kostar pengar) och det snabbar upp surfandet. Du som jobbar som webbredaktör har säkert råkat ut för att en ändring “inte slagit igenom” på den sida du just uppdaterade, det är samma typ av teknik vi talar om.

Kryptering via HTTPS gör att varje sida måste skickas från webbservern vid varje förfrågan, och att innehållet behöver sammanställas på nytt för varje besökare. Det tar kraft från servern, innebär mer trafik över internet och skapar extra fördröjningar på grund av att varje sida måste hämtas från källan – oavsett om innehållet ändrats eller ej.

Alternativet är att köra med HTTP/2

Ett alternativ jag tycker man ska undersöka är om det går att ta steget direkt till HTTP 2.0 (tidigare kallat SPDY). Främsta införsäljningsargumenten är att det är modernare, skapat för att stödja kryptering och dessutom ger upp till 10 gånger högre prestanda i överföring av innehåll.

Som grädde på moset behöver man inte vara lika nitisk med att ha få filer för varje sidvisning, HTTP/2 är bättre på parallellism än HTTP 1.1 – alltså bättre på att skicka flera filer på en gång. De organisationer som kör Microsofts webbserver IIS, vanligast i kombo med Episerver, får dock vänta på Windows Server 2016 innan stöd för HTTP/2 finns. På vissa plattformar finns redan stöd.

Klart som korvspad? 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *