Certifikatsmyndigheter är en av de viktigaste hörnstenarna för Internetsäkerhet. En certifikatutfärdare är någon som alla litar på, i början, när ingen litar på någon annan. Det är sedan denna certifikatutfärdares (a.k.a. CA) uppgift att se till att förtroende etableras mellan servrar och klienter innan de upprättar kommunikation över Internet. en CA är viktig inte bara för HTTPS som används av webbläsare och webbapplikationer, utan även för krypterad e-post, signerade programvaruuppdateringar, VPN:er och mycket mycket mer. Vi kommer att ta det prototypiska exemplet HTTPS och lära oss om CA, i detta speciella sammanhang. Även om du kan extrapolera resultatet till vilken annan programvarusvit som helst.

Internet är en opålitlig kanal för kommunikation. När du skickar eller tar emot information från en gammal HTTP-webbplats http://www.example.com i din webbläsare kan mycket hända mitt i dina paket.

1. En dålig aktör kan avlyssna kommunikationen, kopiera uppgifterna för sig själv, innan han eller hon sänder dem på nytt på kanalen mot dig eller servern som du pratade med. Utan någon av parternas vetskap är informationen komprometterad. Vi måste se till att kommunikationen är privat.
2. En dålig aktör kan ändra informationen när den skickas över kanalen. Bob kan ha skickat ett meddelande ”x”, men Alice skulle få ”y” från Bob, eftersom en dålig aktör avlyssnade meddelandet och ändrade det. Med andra ord äventyras meddelandets integritet.
3. Sist och viktigast av allt måste vi försäkra oss om att den person vi pratar med verkligen är den som han eller hon utger sig för att vara. Vi återgår till domänen example.com. Hur kan vi försäkra oss om att den server som svarade oss verkligen är den rättmätiga innehavaren av www.example.com? När som helst i ditt nätverk kan du bli omdirigerad till en annan server. En DNS någonstans ansvarar för att omvandla ett domännamn, t.ex. www.example.com, till en IP-adress på det offentliga internet. Men din webbläsare har inget sätt att kontrollera att DNS översatt IP-adressen.

De två första problemen kan lösas genom att kryptera meddelandet innan det skickas över Internet till servern. Det vill säga genom att gå över till HTTPS. Det sista problemet, problemet med identiteten, är dock där en certifikatutfärdare kommer in i bilden.

Initiering av krypterade HTTP-sessioner

Huvudproblemet med krypterad kommunikation över en osäker kanal är ”Hur startar vi den?”

Det allra första steget skulle innebära att de två parterna, webbläsaren och servern, skulle utbyta krypteringsnycklar som ska utbytas över den osäkra kanalen. Om du inte är bekant med begreppet nycklar kan du tänka dig dem som ett riktigt långt slumpmässigt genererat lösenord med vilket dina data krypteras innan de skickas över den osäkra kanalen.

Om nycklarna skickas över en osäker kanal kan vem som helst lyssna på det och äventyra säkerheten för din HTTPS-session i framtiden. Hur kan vi dessutom lita på att nyckeln som skickas av en server som påstår sig vara www.example.com verkligen är den faktiska ägaren av domännamnet? Vi kan ha en krypterad kommunikation med en skadlig part som utger sig för att vara en legitim webbplats utan att veta skillnaden.

Problemet med att säkerställa identiteten är alltså viktigt om vi vill garantera ett säkert nyckelutbyte.

Certifikatsmyndigheter

Du kanske har hört talas om LetsEncrypt, DigiCert, Comodo och ett par andra tjänster som erbjuder TLS-certifikat för ditt domännamn. Du kan välja den som passar dina behov. Nu måste den person/organisation som äger domänen på något sätt bevisa för sin certifikatutfärdare att de verkligen har kontroll över domänen. Detta kan göras genom att antingen skapa en DNS-post med ett unikt värde, vilket begärs av certifikatutfärdaren, eller så kan du lägga till en fil på din webbserver, med ett innehåll som specificeras av certifikatutfärdaren, certifikatutfärdaren kan sedan läsa denna fil och bekräfta att du är en giltig ägare av domänen.

Därefter förhandlar du om ett TLS-certifikat med certifikatutfärdaren, och det resulterar i att en privat nyckel och ett offentligt TLS-certifikat utfärdas för din domän. Meddelanden som krypterats med din privata nyckel kan sedan dekrypteras med det offentliga certifikatet och vice versa. Detta kallas asymmetrisk kryptering

Klientwebbläsare som Firefox och Chrome (ibland även operativsystemet) har kunskap om certifikatutfärdare. Denna information är inbakad i webbläsaren/enheten redan från början (dvs. när de installeras) så att de vet att de kan lita på vissa certifikatutfärdare. När de nu försöker ansluta till www.example.com via HTTPS och ser ett certifikat utfärdat av till exempel DigiCert, kan webbläsaren faktiskt verifiera detta med hjälp av de nycklar som lagras lokalt. Det finns faktiskt några fler mellanliggande steg, men detta är en bra förenklad översikt över vad som händer.

Nu när certifikatet som tillhandahålls av www.example.com kan vara tillförlitligt används detta för att förhandla fram en unik symmetrisk krypteringsnyckel som används mellan klienten och servern under resten av deras session. Vid symmetrisk kryptering används en nyckel för både kryptering och dekryptering och är vanligtvis mycket snabbare än sin asymmetriska motsvarighet.

Nyheter

Om idén om TLS och internetsäkerhet tilltalar dig kan du fördjupa dig ytterligare i detta ämne genom att gräva i LetsEncrypt och deras kostnadsfria TLS CA. Det finns mycket mer detaljerade uppgifter om hela denna rigmarole än vad som anges ovan.