Robert Heaton

HTTPS är helt enkelt ditt standard-HTTP-protokoll med ett generöst lager av läcker SSL/TLS-kryptering. Om inte något går fruktansvärt fel (och det kan det göra) förhindrar det personer som den ökända Eve från att se eller ändra de förfrågningar som utgör din webbläsarupplevelse. Det är det som håller dina lösenord, kommunikations- och kreditkortsuppgifter säkra i ledningen mellan din dator och de servrar som du vill skicka dessa uppgifter till. Även om det lilla gröna hänglåset och bokstäverna ”https” i adressfältet inte betyder att det inte fortfarande finns gott om rep för både dig och den webbplats du tittar på att hänga upp sig någon annanstans, hjälper de dig åtminstone att kommunicera på ett säkert sätt medan du gör det.

Vad är HTTPS och vad gör det?

HTTPS tar det välkända och välförstådda HTTP-protokollet, och lägger helt enkelt ett SSL/TLS-krypteringslager (hädanefter bara kallat ”SSL”) ovanpå det. Servrar och klienter talar fortfarande exakt samma HTTP till varandra, men över en säker SSL-anslutning som krypterar och dekrypterar deras förfrågningar och svar. SSL-skiktet har två huvudsyften:

• Säkerställa att du pratar direkt med den server som du tror att du pratar med
• Säkerställa att endast servern kan läsa det du skickar till den och att endast du kan läsa det den skickar tillbaka

Det riktigt, riktigt smarta är att vem som helst kan avlyssna vartenda ett av de meddelanden som du utbyter med en server, inklusive de meddelanden där ni kommer överens om nyckeln och krypteringsstrategin som ska användas, utan att kunna läsa någon av de faktiska data du skickar.

Hur en SSL-anslutning upprättas

En SSL-anslutning mellan en klient och en server upprättas genom ett handshake, vars mål är:

• För att säkerställa att klienten talar med rätt server (och eventuellt vice versa)
• För att parterna ska ha kommit överens om en ”chifferföljd”, vilket inkluderar vilken krypteringsalgoritm de kommer att använda för att utbyta data
• För att parterna ska ha kommit överens om eventuella nödvändiga nycklar för denna algoritm

När förbindelsen är etablerad kan båda parter använda den överenskomna algoritmen och nycklarna för att på ett säkert sätt skicka meddelanden till varandra. Vi kommer att dela upp handskakningen i tre huvudfaser – Hello, Certificate Exchange och Key Exchange.

1. Hello – Handskakningen börjar med att klienten skickar ett ClientHello meddelande. Detta innehåller all information som servern behöver för att kunna ansluta till klienten via SSL, inklusive de olika chiffersviterna och den maximala SSL-versionen som den stöder. Servern svarar med ett ServerHello, som innehåller liknande information som klienten behöver, inklusive ett beslut baserat på klientens preferenser om vilken chifferföljd och version av SSL som ska användas.

2. Certifikatutbyte – Nu när kontakten har etablerats måste servern bevisa sin identitet för klienten. Detta görs med hjälp av dess SSL-certifikat, som är lite som dess pass. Ett SSL-certifikat innehåller olika uppgifter, bland annat ägarens namn, den fastighet (t.ex. domän) som certifikatet är kopplat till, certifikatets offentliga nyckel, den digitala signaturen och information om certifikatets giltighetsdatum. Klienten kontrollerar att den antingen implicit litar på certifikatet eller att det är verifierat och betrodd av en av flera certifikatutfärdare (CA) som den också implicit litar på. Mycket mer om detta inom kort. Observera att servern också får kräva ett certifikat för att bevisa klientens identitet, men detta sker vanligtvis bara i mycket känsliga tillämpningar.

3. Nyckelutbyte – Krypteringen av de faktiska meddelandedata som utbyts av klienten och servern kommer att ske med hjälp av en symmetrisk algoritm, vars exakta karaktär redan överenskommits under Hello-fasen. En symmetrisk algoritm använder en enda nyckel för både kryptering och dekryptering, till skillnad från asymmetriska algoritmer som kräver ett offentligt/privat nyckelpar. Båda parter måste komma överens om denna enda, symmetriska nyckel, en process som sker på ett säkert sätt med asymmetrisk kryptering och serverns offentliga/privata nycklar.

Klienten genererar en slumpmässig nyckel som ska användas för den huvudsakliga, symmetriska algoritmen. Den krypterar den med hjälp av en algoritm som också överenskommits under Hello-fasen och serverns offentliga nyckel (som finns på dess SSL-certifikat). Den skickar denna krypterade nyckel till servern, där den dekrypteras med hjälp av serverns privata nyckel, och de intressanta delarna av handskakningen är avslutade. Parterna är tillräckligt nöjda med att de talar med rätt person och har i hemlighet kommit överens om en nyckel för att symmetriskt kryptera de uppgifter som de ska skicka till varandra. HTTP-förfrågningar och -svar kan nu skickas genom att bilda ett meddelande i klartext och sedan kryptera och skicka det. Den andra parten är den enda som vet hur meddelandet ska dekrypteras, så Man In The Middle-attackerare kan inte läsa eller ändra de förfrågningar som de kan avlyssna.

Certifikat

På sin mest grundläggande nivå är ett SSL-certifikat helt enkelt en textfil, och vem som helst som har en textredigerare kan skapa ett. Du kan faktiskt enkelt skapa ett certifikat som påstår att du är Google Inc. och att du kontrollerar domänen gmail.com. Om detta vore hela sanningen skulle SSL vara ett skämt; identitetsverifiering skulle i huvudsak innebära att klienten frågar servern ”Är du Google?”, att servern svarar ”Ja, helt klart, här är ett papper med ”Jag är Google” skrivet på” och att klienten säger ”Okej, bra, här är alla mina uppgifter”. Magin som förhindrar denna fars ligger i den digitala signaturen, som gör det möjligt för en part att verifiera att en annan parts papper verkligen är äkta.

Det finns två förnuftiga skäl till varför du kan lita på ett certifikat:

• Om det finns med på en lista över certifikat som du litar på implicit
• Om det kan bevisa att det är betrodd av kontrollanten för ett av certifikaten på ovanstående lista

Det första kriteriet är lätt att kontrollera. Din webbläsare har en förinstallerad lista över betrodda SSL-certifikat från certifikatutfärdare (CA) som du kan visa, lägga till och ta bort från. Dessa certifikat kontrolleras av en centraliserad grupp av (i teorin och i allmänhet i praktiken) extremt säkra, tillförlitliga och pålitliga organisationer som Symantec, Comodo och GoDaddy. Om en server visar upp ett certifikat från den listan vet du att du kan lita på dem.

Det andra kriteriet är mycket svårare. Det är lätt för en server att säga: ”Ja, jag heter Microsoft, du litar på Symantec och de litar helt och hållet på mig, så det är lugnt”. En någorlunda smart klient kan då fråga Symantec: ”Jag har en Microsoft här som säger att ni litar på dem, är det sant?”. Men även om Symantec säger ”Ja, vi känner dem, Microsoft är legitima”, vet du fortfarande inte om servern som påstår sig vara Microsoft verkligen är Microsoft eller något mycket värre. Det är här som digitala signaturer kommer in.

3.2 Digitala signaturer

Som redan nämnts har SSL-certifikat ett tillhörande offentligt/privat nyckelpar. Den offentliga nyckeln distribueras som en del av certifikatet och den privata nyckeln förvaras otroligt säkert. Detta par asymmetriska nycklar används i SSL-handskakningen för att utbyta ytterligare en nyckel för båda parter för att symmetriskt kryptera och dekryptera data. Klienten använder serverns offentliga nyckel för att kryptera den symmetriska nyckeln och skicka den säkert till servern, och servern använder sin privata nyckel för att dekryptera den. Vem som helst kan kryptera med den offentliga nyckeln, men endast servern kan dekryptera med den privata nyckeln.

Det motsatta gäller för en digital signatur. Ett certifikat kan ”signeras” av en annan myndighet, varvid myndigheten i praktiken säger: ”Vi har kontrollerat att den som kontrollerar det här certifikatet också kontrollerar den fastighet (domän) som anges på certifikatet”. I detta fall använder myndigheten sin privata nyckel för att (i stort sett) kryptera innehållet i certifikatet, och denna krypterade text bifogas certifikatet som dess digitala signatur. Vem som helst kan dekryptera denna signatur med hjälp av myndighetens offentliga nyckel och kontrollera att den resulterar i det förväntade dekrypterade värdet. Men det är bara myndigheten som kan kryptera innehållet med hjälp av den privata nyckeln, och därför är det bara myndigheten som faktiskt kan skapa en giltig signatur från början.

Så om det kommer en server som påstår sig ha ett certifikat för Microsoft.com som är signerat av Symantec (eller någon annan certifikatutfärdare) behöver webbläsaren inte lita på den. Om det är legitimt kommer Symantec att ha använt sin (ultrahemliga) privata nyckel för att generera serverns SSL-certifikatets digitala signatur, och din webbläsare kan därför använda sin (ultraoffentliga) offentliga nyckel för att kontrollera att signaturen är giltig. Symantec kommer att ha vidtagit åtgärder för att säkerställa att den organisation som de signerar för verkligen äger Microsoft.com, och med tanke på att din klient litar på Symantec kan den vara säker på att den verkligen pratar med Microsoft Inc.

3.3 Självsignering

Bemärk att alla certifikat från rotcertifikatutfärdare är ”självsignerade”, vilket innebär att den digitala signaturen genereras med hjälp av certifikatets egen privata nyckel. Det finns inget i sig speciellt med ett root CA-certifikat – du kan generera ditt eget självsignerade certifikat och använda det för att signera andra certifikat om du vill. Men eftersom ditt slumpmässiga certifikat inte är förinstallerat som CA i någon webbläsare någonstans kommer ingen av dem att lita på dig för att signera vare sig dina egna eller andra certifikat. Du säger i själva verket: ”Ja, jag är helt och hållet Microsoft, här är ett officiellt identitetscertifikat som utfärdats och undertecknats av mig själv”, och alla korrekt fungerande webbläsare kommer att visa ett mycket skrämmande felmeddelande som svar på dina tvivelaktiga referenser.

Detta lägger en enorm börda på alla webbläsare och operativsystemutgivare att endast lita på rena rotcertifikatutfärdare, eftersom det är dessa organisationer som användarna i slutändan litar på när det gäller att granska webbplatser och hålla certifikaten säkra. Detta är ingen lätt uppgift.

3.4 Vad litar du på?

Det är intressant att notera att din klient tekniskt sett inte försöker verifiera om den ska lita på den part som skickat certifikatet, utan om den ska lita på den offentliga nyckeln i certifikatet. SSL-certifikat är helt öppna och offentliga, så vilken angripare som helst kan ta Microsofts certifikat, avlyssna en klients begäran till Microsoft.com och presentera det legitima certifikatet för klienten. Klienten skulle acceptera detta och börja handskakningen. När klienten krypterar den nyckel som kommer att användas för den faktiska datakrypteringen kommer den dock att göra det med hjälp av Microsofts riktiga offentliga nyckel från det riktiga certifikatet. Eftersom angriparen inte har Microsofts privata nyckel för att kunna avkryptera den är han eller hon nu fast. Även om handskakningen avslutas kommer de fortfarande inte att kunna dekryptera nyckeln, och därmed kommer de inte att kunna dekryptera några av de data som klienten skickar till dem. Ordningen upprätthålls så länge angriparen inte kontrollerar ett betroddat certifikats privata nyckel. Om klienten på något sätt luras att lita på ett certifikat och en offentlig nyckel vars privata nyckel kontrolleras av en angripare börjar problemen.

4.1 Kan ett kafé övervaka min HTTPS-trafik över deras nätverk?

Nej. Magin med kryptografi med offentlig nyckel innebär att en angripare kan övervaka varenda byte data som utbyts mellan din klient och servern och ändå inte ha någon aning om vad ni säger till varandra utöver ungefär hur mycket data ni utbyter. Din normala HTTP-trafik är dock fortfarande mycket sårbar i ett osäkert wi-fi-nätverk, och en oseriös webbplats kan falla offer för alla möjliga lösningar som på något sätt lurar dig att skicka HTTPS-trafik antingen över vanlig HTTP eller helt enkelt till fel ställe. Till exempel, även om ett inloggningsformulär skickar en kombination av användarnamn och lösenord över HTTPS, om själva formuläret laddas osäkert över HTTP så kan en angripare fånga upp formulärets HTML på vägen till din maskin och ändra det för att skicka inloggningsuppgifterna till sin egen slutpunkt.

4.2 Kan mitt företag övervaka min HTTPS-trafik över deras nätverk?

Om du också använder en maskin som kontrolleras av ditt företag, så ja. Kom ihåg att vid roten av varje förtroendekedja finns en implicit betrodd CA, och att en lista över dessa myndigheter finns lagrad i din webbläsare. Ditt företag kan använda sin tillgång till din maskin för att lägga till sitt eget självsignerade certifikat i denna lista över auktoriteter. De skulle sedan kunna avlyssna alla dina HTTPS-förfrågningar och presentera certifikat som påstås representera den aktuella webbplatsen och som är undertecknade av deras falska CA och som därför utan tvekan är betrodda av din webbläsare. Eftersom du skulle kryptera alla dina HTTPS-förfrågningar med hjälp av deras falska certifikats offentliga nyckel kan de använda motsvarande privata nyckel för att dekryptera och inspektera (och till och med ändra) din förfrågan och sedan skicka den till den avsedda platsen. Det gör de förmodligen inte. Men de skulle kunna göra det.

Det är av en slump också så här man använder en proxy för att inspektera och ändra de annars otillgängliga HTTPS-förfrågningar som görs av en iPhone-app.

4.3 Så vad hände med Lavabit och FBI?

Lavabit var Edward Snowdens supersäkra e-postleverantör under NSA-läckornas vansinnesfärd 2013. Som vi har sett kunde inget standardhaveri göra det möjligt för FBI att se data på väg mellan Lavabit och dess kunder. Utan den privata nyckeln för Lavabits SSL-certifikat var myndigheten körd. En hjälpsam amerikansk domare sa dock till Lavabits grundare, Ladar Levison, att han var tvungen att överlämna denna nyckel, vilket i praktiken gav FBI fria händer att snoka i trafiken efter eget gottfinnande. Levison gjorde ett tappert försök att förhala genom att lämna över nyckeln med 2560 tecken på 11 sidor i papperskopia med 4-punktsskrift, men fick en order som krävde att han skulle lämna över nyckeln i ett användbart format, annars skulle han få böter på 5 000 dollar per dag tills han gjorde det.

När han väl uppfyllde kraven återkallade GoDaddy, Lavabits certifikatutfärdare, certifikatet, eftersom de (med rätta) bedömde att det hade blivit komprometterat. Detta ledde till att Lavabit-certifikatet lades till en Certificate Revocation List (CRL), en lista över diskrediterade certifikat som kunderna inte längre bör lita på för att tillhandahålla en säker anslutning. Komprometterade, självsignerade eller på annat sätt opålitliga certifikat leder till att webbläsare visar ett stort rött felmeddelande och antingen avskräcker eller helt och hållet förbjuder användaren att vidta ytterligare åtgärder. Tyvärr fortsätter webbläsarna att lita på ett trasigt certifikat tills de tar fram de senaste uppdateringarna till CRL, en process som uppenbarligen är ofullständig i praktiken.

Slutsats

HTTPS är inte okränkbart, och SSL-protokollet måste ständigt utvecklas i takt med att nya attacker mot det upptäcks och krossas. Men det är fortfarande ett imponerande robust sätt att överföra hemliga uppgifter utan att bry sig om vem som ser dina meddelanden. Det finns naturligtvis många genomförandedetaljer som inte nämns här, t.ex. det exakta formatet och ordningsföljden för handshake-meddelandena, förkortade handshakes för att hämta upp nyligen genomförda sessioner utan att behöva omförhandla nycklar och chifferuppsättningar och de många olika krypteringsalternativ som finns tillgängliga i varje skede. Det viktigaste att komma ihåg är att även om HTTPS skyddar data på vägen till destinationen, skyddar det inte på något sätt dig (som användare eller utvecklare) mot XSS, databasläckor eller andra saker som kan hända under natten. Var glad över att den skyddar dig, men var vaksam. Med Will Smiths odödliga ord: ”Walk in shadow, move in silence, guard against extraterrestrial violence.”

Om du gillade det här kommer du förmodligen att gilla mitt inlägg som förklarar detaljerna i 2015 års FREAK-sårbarhet i SSL.