Certificeringsmyndigheder er en af de vigtigste hjørnesten for internetsikkerhed. En certifikatmyndighed er en person, som alle har tillid til, i begyndelsen, når ingen stoler på andre. Det er så denne certifikatmyndigheds (alias CA) opgave at sikre, at der etableres tillid mellem servere og klienter, før de etablerer kommunikation over internettet. en CA er vigtig ikke kun for HTTPS, der bruges af browsere og webapps, men også for krypterede e-mails, signerede softwareopdateringer, VPN’er og meget meget mere. Vi vil tage det prototypiske eksempel med HTTPS og lære om CA i denne særlige kontekst. Selv om du kan ekstrapolere resultatet til enhver anden softwaresuite.

Internettet er en ikke betroet kanal for kommunikation. Når du sender eller modtager oplysninger fra et gammelt HTTP-websted http://www.example.com i din browser, kan der ske en masse ting midtvejs i dine pakker.

1. En dårlig aktør kan opsnappe kommunikationen, kopiere dataene til sig selv, inden han sender dem igen på kanalen mod dig eller den server, du talte med. Uden at nogen af parterne ved det, er oplysningerne kompromitteret. Vi er nødt til at sikre, at kommunikationen er privat.
2. En ond aktør kan ændre oplysningerne, mens de sendes over kanalen. Bob kan have sendt en meddelelse “x”, men Alice vil modtage “y” fra Bob, fordi en ond aktør opsnappede meddelelsen og ændrede den. Med andre ord er meddelelsens integritet kompromitteret.
3. Sidst, og vigtigst af alt, skal vi sikre, at den person, vi taler med, rent faktisk er den, han eller hun siger, han eller hun er. Vi vender tilbage til domænet example.com. Hvordan kan vi sikre os, at den server, der svarede tilbage til os, faktisk er den retmæssige indehaver af www.example.com? På ethvert tidspunkt i dit netværk kan du blive omdirigeret forkert til en anden server. Et eller andet sted er en DNS ansvarlig for at omdanne et domænenavn, f.eks. www.example.com, til en IP-adresse på det offentlige internet. Men din browser har ingen mulighed for at kontrollere, at den DNS-oversatte IP-adresse.

De to første problemer kan løses ved at kryptere meddelelsen, inden den sendes over internettet til serveren. Det vil sige ved at skifte over til HTTPS. Men det sidste problem, identitetsproblemet, er der, hvor en certifikatudstedende myndighed kommer ind i billedet.

Initiering af krypterede HTTP-sessioner

Det største problem med krypteret kommunikation over en usikker kanal er: “Hvordan starter vi den?”

Det allerførste skridt vil indebære, at de to parter, din browser og serveren, skal udveksle de krypteringsnøgler, der skal udveksles over den usikre kanal. Hvis du ikke er bekendt med begrebet nøgler, skal du tænke på dem som en rigtig lang tilfældigt genereret adgangskode, som dine data krypteres med, inden de sendes over den usikre kanal.

Jamen, hvis nøglerne sendes over en usikker kanal, kan alle lytte med på den og kompromittere sikkerheden i din HTTPS-session i fremtiden. Hvordan kan vi desuden stole på, at den nøgle, der sendes af en server, der hævder at være www.example.com, rent faktisk er den faktiske ejer af det pågældende domænenavn? Vi kan have en krypteret kommunikation med en ondsindet part, der udgiver sig for at være et legitimt websted, og vi kan ikke kende forskel.

Så problemet med at sikre identiteten er vigtigt, hvis vi ønsker at sikre sikker nøgleudveksling.

Certificeringsmyndigheder

Du har måske hørt om LetsEncrypt, DigiCert, Comodo og et par andre tjenester, der tilbyder TLS-certifikater for dit domænenavn. Du kan vælge den, der passer til dit behov. Nu skal den person/organisation, der ejer domænet, på en eller anden måde bevise over for deres certifikatudstedende myndighed, at de rent faktisk har kontrol over domænet. Dette kan gøres ved enten at oprette en DNS-record med en unik værdi i den, som krævet af certificeringsmyndigheden, eller du kan tilføje en fil til din webserver med et indhold, der er specificeret af certificeringsmyndigheden, CA kan så læse denne fil og bekræfte, at du er en gyldig ejer af domænet.

Dernæst forhandler du et TLS-certifikat med CA, og det resulterer i en privat nøgle og et offentligt TLS-certifikat udstedt til dit domæne. Meddelelser, der er krypteret med din private nøgle, kan derefter dekrypteres med det offentlige certifikat og omvendt. Dette er kendt som asymmetrisk kryptering

Klientbrowsere som Firefox og Chrome (nogle gange endda styresystemet) har kendskab til certifikatudstedere. Disse oplysninger er bagt ind i browseren/enheden fra starten (dvs. når de installeres), så de ved, at de kan stole på visse CA’er. Når de nu forsøger at oprette forbindelse til www.example.com via HTTPS og ser et certifikat udstedt af f.eks. DigiCert, kan browseren faktisk verificere dette ved hjælp af de nøgler, der er gemt lokalt. Der er faktisk flere mellemliggende trin, men dette er et godt forenklet overblik over, hvad der sker.

Nu, hvor man kan stole på det certifikat, der leveres af www.example.com, bruges dette til at forhandle en unik symmetrisk krypteringsnøgle, som bruges mellem klienten og serveren i resten af deres session. Ved symmetrisk kryptering bruges én nøgle til både kryptering og dekryptering, og den er normalt meget hurtigere end dens asymmetriske modstykke.

Nuancer

Hvis tanken om TLS og internetsikkerhed tiltaler dig, kan du se nærmere på dette emne ved at grave dig ned i LetsEncrypt og deres gratis TLS CA. Der er meget mere minutiøst i hele dette rigmarol, end hvad der er anført ovenfor.