Phenquestions
Problemen met HTTP en platte tekst
Het internet is een onbetrouwbaar communicatiekanaal. Wanneer u informatie verzendt of ontvangt van een oude HTTP-site http://www.voorbeeld.com in uw browser kunnen er veel dingen gebeuren halverwege uw pakketten.
- Een slechte acteur kan de communicatie onderscheppen, de gegevens voor zichzelf kopiëren, voordat hij deze opnieuw op het kanaal naar u of de server waarmee u sprak opnieuw verzendt. Zonder medeweten van beide partijen wordt de informatie gecompromitteerd. We moeten ervoor zorgen dat de communicatie is: privaat.
- Een slechte acteur kan de informatie wijzigen terwijl deze over het kanaal wordt verzonden. Bob heeft misschien een bericht gestuurd "X" maar Alice zou ontvangen "j" van Bob, omdat een slechte acteur het bericht heeft onderschept en gewijzigd. Met andere woorden, de integriteit van het bericht is gecompromitteerd.
- Ten slotte, en vooral, moeten we ervoor zorgen dat de persoon met wie we praten inderdaad is wie hij zegt dat hij is. Teruggaan naar de voorbeeld.com domein. Hoe kunnen we ervoor zorgen dat de server die ons heeft geantwoord inderdaad de rechtmatige houder is van www.voorbeeld.com? Op elk punt in uw netwerk kunt u verkeerd worden doorgestuurd naar een andere server. Een DNS ergens is verantwoordelijk voor het omzetten van een domeinnaam, zoals www.voorbeeld.com, in een IP-adres op het openbare internet. Maar uw browser kan niet controleren of het DNS-vertaalde IP-adres.
De eerste twee problemen kunnen worden opgelost door het bericht te versleutelen voordat het via internet naar de server wordt verzonden. Dat wil zeggen, door over te stappen op HTTPS. Het laatste probleem, het identiteitsprobleem, is echter waar een certificeringsinstantie in het spel komt.
Versleutelde HTTP-sessies starten
Het grootste probleem met versleutelde communicatie via een onveilig kanaal is "Hoe beginnen we eraan?"?”
De allereerste stap zou zijn dat de twee partijen, uw browser en de server, de coderingssleutels uitwisselen die via het onveilige kanaal moeten worden uitgewisseld. Als u niet bekend bent met de term sleutels, beschouw ze dan als een heel lang willekeurig gegenereerd wachtwoord waarmee uw gegevens worden versleuteld voordat ze over het onveilige kanaal worden verzonden.
Welnu, als de sleutels via een onveilig kanaal worden verzonden, kan iedereen daarop luisteren en de beveiliging van uw HTTPS-sessie in de toekomst in gevaar brengen. Bovendien, hoe kunnen we erop vertrouwen dat de sleutel die wordt verzonden door een server die beweert www . te zijn.voorbeeld.com is inderdaad de daadwerkelijke eigenaar van die domeinnaam? We kunnen een gecodeerde communicatie hebben met een kwaadwillende partij die zich voordoet als een legitieme site en we weten het verschil niet.
Het probleem van het waarborgen van identiteit is dus belangrijk als we een veilige sleuteluitwisseling willen garanderen.
Certificaatautoriteiten
Je hebt misschien gehoord van LetsEncrypt, DigiCert, Comodo en een paar andere diensten die TLS-certificaten aanbieden voor je domeinnaam. U kunt degene kiezen die bij uw behoefte past. Nu moet de persoon/organisatie die eigenaar is van het domein op de een of andere manier aan hun certificeringsinstantie bewijzen dat ze inderdaad controle hebben over het domein. Dit kan worden gedaan door ofwel een DNS-record aan te maken met een unieke waarde erin, zoals gevraagd door de certificeringsinstantie, of u kunt een bestand toevoegen aan uw webserver, met inhoud gespecificeerd door de certificeringsinstantie, de CA kan dit bestand vervolgens lezen en bevestig dat u de geldige eigenaar van het domein bent.
Vervolgens onderhandel je met de CA over een TLS-certificaat en dat resulteert in een privésleutel en een openbaar TLS-certificaat dat aan je domein wordt uitgegeven. Berichten die met uw privésleutel zijn versleuteld, kunnen vervolgens worden ontsleuteld met het openbare certificaat en vice versa. Dit staat bekend als asymmetrische encryptie
De clientbrowsers, zoals Firefox en Chrome (soms zelfs het besturingssysteem) hebben kennis van certificeringsinstanties. Deze informatie wordt vanaf het begin in de browser/het apparaat ingebakken (dat wil zeggen, wanneer ze zijn geïnstalleerd), zodat ze weten dat ze bepaalde CA's kunnen vertrouwen. Nu, wanneer ze proberen verbinding te maken met www.voorbeeld.com via HTTPS en een certificaat zien dat is uitgegeven door, zeg DigiCert, de browser kan dat daadwerkelijk verifiëren met behulp van de lokaal opgeslagen sleutels. Er zijn eigenlijk nog een paar tussenstappen, maar dit is een goed vereenvoudigd overzicht van wat er gebeurt.
Nu het certificaat van www.voorbeeld.com kan worden vertrouwd, wordt dit gebruikt om te onderhandelen over een unieke symmetrische coderingssleutel die wordt gebruikt tussen de client en de server voor de rest van hun sessie. Bij symmetrische codering wordt één sleutel gebruikt om zowel te coderen als te decoderen en is deze meestal veel sneller dan zijn asymmetrische tegenhanger.
Nuances
Als het idee van TLS en internetbeveiliging je aanspreekt, kun je verder in dit onderwerp kijken door je te verdiepen in LetsEncrypt en hun gratis TLS CA. Deze hele rompslomp heeft veel meer details dan hierboven vermeld.
Andere bronnen die ik kan aanbevelen voor meer informatie over TLS zijn Troy Hunt's Blog en werk van EFF zoals HTTPS Everywhere en Certbot. Alle bronnen zijn gratis toegankelijk en erg goedkoop om te implementeren (je hoeft alleen maar te betalen voor domeinnaamregistratie en VPS-uurkosten) en doe praktische ervaring op.
