Hoe beveiligt TLS eigenlijk een HTTPS-verbinding?

Mensen zeggen "HTTPS betekent dat het versleuteld is" en laten het daar. Maar het interessante deel is hoe twee vreemden op het internet een gedeeld geheim afspreken zonder elkaar ooit te ontmoeten, over een netwerk vol mensen die zouden kunnen luisteren. Dat is wat TLS doet, en het is de moeite waard om de mechanica te begrijpen als je met netwerken, webontwikkeling of beveiliging te maken hebt.

De handshake, stap voor stap

Wanneer je browser verbinding maakt met https://example.com, gebeurt er ruwweg dit (TLS 1.3, wat de meeste sites nu gebruiken):

1. ClientHello — de browser stuurt ondersteunde cipher suites, een willekeurige nonce en een gok voor een sleutelshare (met iets als X25519 of secp256r1) voor sleuteluitwisseling.
2. ServerHello — de server kiest een cipher suite, stuurt zijn eigen sleutelshare, en retourneert zijn certificaat plus een handtekening die bewijst dat het de privésleutel bij dat certificaat heeft.
3. Sleutelafleiding — beide zijden berekenen nu onafhankelijk hetzelfde gedeelde geheim met Diffie-Hellman-achtige wiskunde op hun sleutelshares. Geen van beiden stuurt het geheim zelf; het wordt afgeleid, niet verzonden.
4. Finished-berichten — beide zijden bevestigen dat de handshake niet is gemanipuleerd door een MAC over het volledige handshake-transcript te sturen.

Daarna is alles versleuteld met symmetrische sleutels afgeleid van het gedeelde geheim, meestal AES-128-GCM of ChaCha20-Poly1305. TLS 1.3 reduceerde dit van TLS 1.2's handshake in twee rondetijden tot effectief één rondetijd, wat op schaal een echt voordeel voor latentie is.

Waarom het certificaat meer uitmaakt dan de versleuteling

Versleuteling zonder identiteitsverificatie is zinloos — iedereen kan een versleuteld kanaal opzetten, inclusief een aanvaller die een man-in-the-middle uitvoert. Het certificaat is wat een publieke sleutel aan een domeinnaam koppelt, en het is ondertekend door een certificaatautoriteit (CA) zoals Let's Encrypt of DigiCine.

Je browser vertrouwt een vaste lijst van root-CA's die in het besturingssysteem of browservertrouwensarchief zijn ingebakken. Het servercertificaat ketent omhoog via tussenliggende certificaten naar een van die roots. Als de keten niet valideert, of het domein in het certificaat komt niet overeen met wat je hebt aangevraagd, krijg je de rode waarschuwingspagina. Dat ketenumdeel-van-vertrouwensmodel is de werkelijke veiligheidslijn — steel de ondertekensleutel van een CA en je kunt geldige certificaten voor elk domein maken, daarom worden CA-inbreuken als grote incidenten behandeld.

Wat symmetrische versus asymmetrische crypto hier doet

Asymmetrische crypto (RSA of elliptische curve) is traag en duur, dus TLS gebruikt het alleen tijdens de handshake — om de server te verifiëren en het gedeelde geheim vast te stellen. Zodra dat gedaan is, wordt alle werkelijke gegevens (HTML, JSON, wat dan ook) versleuteld met snelle symmetrische ciphers. Deze hybride aanpak is hetzelfde patroon dat je in SSH, PGP en de meeste echte cryptosystemen zult zien: asymmetrisch voor identiteit en sleuteluitwisseling, symmetrisch voor bulkgegevens.

Vooruitzicht op toekomstige geheimhouding is een gerelateerde detail die het weten waard is: omdat het gedeelde geheim uit kortstondige Diffie-Hellman-sleutelshares komt die per sessie vers worden gegenereerd, kunnen aanvallers, zelfs als ze je verkeersverkeer opnemen en later de privésleutel van de server stelen, oude sessies nog steeds niet ontsleutelen. Die eigenschap bestond niet in oudere alleen-RSA-sleuteluitwisseling.

Het zelf controleren

Je hoeft niet zomaar op het vertrouwen van een groen hangslotpictogram af te gaan. Voer dit uit:

openssl s_client -connect example.com:443 -tls1_3

Dat toont je de onderhandelde cipher suite, de certificaatketen en of de handshake werkelijk is voltooid. Voor een sneller overzicht van wat een browser ziet, print curl -v https://example.com de TLS-versie en certificaatdetails vóór het HTTP-antwoord.

Je kunt ook je eigen verkeersverkeer in Wireshark ontsleutelen als je de omgevingsvariabele SSLKEYLOGFILE exporteert voordat je Chrome of Firefox start — werkelijk nuttig voor het opsporen van TLS-problemen in plaats van gissen.

Waar dit in de praktijk werkelijk mislukt

De meeste echte HTTPS-fouten zijn geen cryptografische breuken, ze zijn operationeel: verlopen certificaten, verkeerd geconfigureerde tussenliggende ketens, clients vastgelopen op oude TLS-versies, of gemengde inhoud (een HTTPS-pagina laadt een HTTP-resource). Werkelijke aanvallen op protocolniveau tegen modern TLS 1.3 zijn zeldzaam omdat de spec de meeste van de padding-oracle en downgrade-trucjes die SSL 3.0 en vroeg TLS plagden, heeft gesloten. De zwakke punten zijn nu meestal de eindpunten — een gecompromitteerde CA, een gestolen privésleutel, of een gebruiker die een certificaatwarschuwing doorklikt die ze niet hadden mogen doen.

Als je verder wilt gaan, behandelen de netwerk- en cryptografiesegmenten van Korra Studio de onderliggende Diffie-Hellman-wiskunde en protocolanalyse op pakketniveau in meer detail.