Certificaat Autoriteiten zijn een van de meest belangrijke hoekstenen voor Internet veiligheid. Een certificaatautoriteit is iemand die door iedereen wordt vertrouwd, in het begin, wanneer niemand iemand anders vertrouwt. Het is dan de taak van deze certificaatautoriteit (a.k.a CA) om ervoor te zorgen dat er vertrouwen is tussen servers en clients voordat ze communicatie over het internet tot stand brengen.Een CA is niet alleen belangrijk voor HTTPS dat door browsers en webapps wordt gebruikt, maar ook voor versleutelde e-mails, ondertekende software-updates, VPN’s, en nog veel meer. We zullen het prototypische voorbeeld van HTTPS nemen en leren over CA, in deze specifieke context. Hoewel je het resultaat kunt extrapoleren naar elke andere software suite.

Het Internet is een onvertrouwd communicatiekanaal. Wanneer je informatie verstuurt of ontvangt van een oude HTTP site http://www.example.com in je browser, kan er van alles gebeuren halverwege je pakketjes.

1. Een slechte actor kan de communicatie onderscheppen, de data voor zichzelf kopiëren, alvorens het opnieuw te versturen op het kanaal naar jou of de server waarmee je aan het praten was. Zonder medeweten van een van de partijen, is de informatie gecompromitteerd. We moeten ervoor zorgen dat de communicatie privé is.
2. Een slechte actor kan de informatie wijzigen terwijl het over het kanaal wordt verzonden. Bob kan een bericht “x” hebben verzonden, maar Alice zou “y” van Bob ontvangen, omdat een slechte actor het bericht heeft onderschept en gewijzigd. Met andere woorden, de integriteit van het bericht is gecompromitteerd.
3. Ten slotte, en dat is het belangrijkste, moeten we ons ervan vergewissen dat de persoon met wie we praten inderdaad is wie hij zegt dat hij is. Terugkomend op het voorbeeld.com domein. Hoe kunnen we er zeker van zijn dat de server die ons antwoordde inderdaad de rechtmatige houder is van www.example.com? Op elk punt in uw netwerk kunt u verkeerd omgeleid worden naar een andere server. Een DNS ergens is verantwoordelijk voor het omzetten van een domeinnaam, zoals www.example.com, in een IP-adres op het openbare internet. Maar uw browser heeft geen manier om te controleren of de DNS het IP-adres heeft vertaald.

De eerste twee problemen kunnen worden opgelost door het bericht te versleutelen voordat het over het Internet naar de server wordt gestuurd. Dat wil zeggen, door over te schakelen op HTTPS. Het laatste probleem, het probleem van de identiteit, is echter waar een Certificate Authority in het spel komt.

Initiating Encrypted HTTP sessions

Het grootste probleem met gecodeerde communicatie over een onveilig kanaal is “Hoe beginnen we het?”

De allereerste stap zou inhouden dat de twee partijen, uw browser en de server, de encryptiesleutels uitwisselen die over het onveilige kanaal moeten worden uitgewisseld. Als u niet vertrouwd bent met de term sleutels, denk aan hen als een echt lang willekeurig gegenereerd wachtwoord waarmee uw gegevens zullen worden versleuteld voordat ze worden verzonden over het onveilige kanaal.

Wel, als de sleutels worden verzonden over een onveilig kanaal, kan iedereen luisteren op dat en compromitteren de veiligheid van uw HTTPS-sessie in de toekomst. Bovendien, hoe kunnen wij erop vertrouwen dat de sleutel die wordt verzonden door een server die beweert www.example.com te zijn, inderdaad de werkelijke eigenaar van die domeinnaam is? We kunnen een versleutelde communicatie hebben met een kwaadwillende partij die zich voordoet als een legitieme site en het verschil niet weten.

Dus, het probleem van het waarborgen van de identiteit is belangrijk als we een veilige sleuteluitwisseling willen garanderen.

Certificaatautoriteiten

U hebt misschien gehoord van LetsEncrypt, DigiCert, Comodo en een paar andere diensten die TLS-certificaten aanbieden voor uw domeinnaam. U kunt degene kiezen die aan uw behoefte voldoet. Nu moet de persoon/organisatie die eigenaar is van het domein op een of andere manier aan hun Certificaat Autoriteit bewijzen dat zij inderdaad controle hebben over het domein. Dit kan worden gedaan door een DNS record aan te maken met een unieke waarde erin, zoals gevraagd door de Certificate Authority, of u kunt een bestand toevoegen aan uw webserver, met een door de Certificate Authority gespecificeerde inhoud, de CA kan dit bestand dan lezen en bevestigen dat u een geldige eigenaar van het domein bent.

Daarna onderhandelt u met de CA over een TLS certificaat, en dat resulteert in een prive sleutel en een publiek TLS certificaat uitgegeven aan uw domein. Berichten die met uw privé-sleutel zijn versleuteld, kunnen vervolgens met het openbare certificaat worden ontsleuteld en vice versa. Dit staat bekend als asymmetrische encryptie

De client browsers, zoals Firefox en Chrome (soms zelfs het besturingssysteem) hebben de kennis van Certificaat Autoriteiten. Deze informatie is vanaf het begin in de browser/het apparaat ingebakken (dat wil zeggen, wanneer ze worden geïnstalleerd), zodat ze weten dat ze bepaalde CA’s kunnen vertrouwen. Wanneer ze nu via HTTPS verbinding proberen te maken met www.example.com en een certificaat zien dat is uitgegeven door bijvoorbeeld DigiCert, kan de browser dat verifiëren met behulp van de sleutels die lokaal zijn opgeslagen. Eigenlijk zijn er nog een paar tussenstappen, maar dit is een goed vereenvoudigd overzicht van wat er gebeurt.

Nu het door www.example.com geleverde certificaat kan worden vertrouwd, wordt dit gebruikt om te onderhandelen over een unieke symmetrische encryptie sleutel die wordt gebruikt tussen de client en de server voor de rest van hun sessie. Bij symmetrische encryptie wordt één sleutel gebruikt voor zowel encryptie als decryptie en is meestal veel sneller dan zijn asymmetrische tegenhanger.

Nuances

Als het idee van TLS en Internet beveiliging je aanspreekt, kun je verder kijken in dit onderwerp door je te verdiepen in LetsEncrypt en hun gratis TLS CA. Er zit veel meer achter dit hele gedoe dan hierboven staat.