Certificaten, HTTPS en TLS
Digitale certificaten
Een certificaat is een (digitaal) document dat de identiteit van een gebruiker bindt aan een publieke sleutel. Dit document werd digitaal ondertekend door een vertrouwde derde partij (trusted third party) zodat bij twijfel van de echtheid van het certificaat men altijd bij deze derde partij terecht kan. Uiteraard is het belangrijk dat we deze derde partij kunnen vertrouwen, anders kunnen we ook niet het certificaat vertrouwen die zij onderschrijven.
Certificaten worden beschreven in de X.509 standaard.
Om een certificaat aan te maken dient Bob naar een Registration authority (RA) te gaan die zijn identiteit zal verifiëren. Dit gebeurt aan de hand van de typische documenten die ook buiten het Internet worden gebruikt om iemands identiteit te bewijzen: identiteitskaart, paspoort, rijbewijs, etc. In sommige gevallen zal de RA zelfs eisen dat Bob zich naar een fysiek kantoor begeeft om daar z’n identiteit in the flesh te bewijzen. Indien de RA de identiteit heeft bevestigd zal deze de aanvraag van Bob doorsturen naar een Certification authority (CA), inclusief Bobs publieke sleutel, die een certificaat zal aanmaken én ondertekenen.
Het gehele systeem van CA’s, RA’s, etc. dat bestaat om certificaten uit te geven, beheren en bewijzen heet een Public Key Infrastructure (PKI).
De CA zal deze informatie gebruiken om een certificaat, van een bepaalde levensduur, te genereren. Hierbij zal de echtheid van het certificaat achteraf bewezen kunnen worden door de CA:
- Het certificaat bevat Bobs publieke sleutel en informatie over Bob en de CA in leesbare vorm. Daaraan wordt een digitale handtekening van de CA toegevoegd: een hash van al deze informatie, versleuteld met de private sleutel van de CA.
- Om later de echtheid van het certificaat te verifiëren, berekent de ontvanger zelf de hash van de inhoud van het certificaat en vergelijkt die met de ontsleutelde handtekening (die met de publieke sleutel van de CA wordt gedecrypteerd). Als beide hashes gelijk zijn, weten we dat het certificaat door de gegeven CA werd ondertekend - enkel de houder van de private sleutel van die CA kan zo’n geldige handtekening produceren.
Een X.509-certificaat bevat minstens volgende velden:
- Versie van de X.509-standaard (vandaag doorgaans v3).
- Serienummer: uniek binnen de uitgevende CA.
- Signature algorithm: welk algoritme de CA gebruikte om te ondertekenen (bv. SHA-256 met RSA).
- Issuer: naam van de CA die het certificaat uitgaf.
- Validity: begin- en einddatum van geldigheid.
- Subject: naam van de eigenaar (domeinnaam of persoon).
- Public key van de eigenaar, met het gebruikte algoritme.
- Extensions: bijkomende info zoals gebruiksbeperkingen of alternatieve domeinnamen.
- Signature: de digitale handtekening van de CA over al het bovenstaande.
Voorgaande proces zal bijvoorbeeld plaatsvinden wanneer je browser via een HTTPS verbinding surft naar een website en zo wil controleren of wel degelijk met de website wordt gecommuniceerd en niet met een imposter. Indien de browser (of de gebruiker) twijfelt aan de echtheid van de publieke sleutel van de CA die het certificaat van de website ondertekent, dan zal het voorgaande proces zich herhalen, maar deze keer om het certificaat van de CA te controleren met behulp van een bovenliggende CA. Op die manier kan het dus zijn dat een keten van CA’s ontstaan die telkens CA’s onder zich bewijzen. Uiteraard zal er steeds bovenaan zo’n ketting een root CA staan. Als je die vertrouwt, dan kan je al de CA’s er onder dus ook vertrouwen…maar ook vice versa!
Alhoewel HTTPS al sinds 1995 bestond, werd het tot voor kort amper door websites aangeboden. Nochtans geeft HTTPS een extra defensielaag tijdens de communicatie van jouw computer met die waar een website op gehost staat. HTTPS zal namelijk je communicatie versleutelen zodat enkel zender en ontvanger kunnen lezen wat er gezegd wordt. Met HTTP is dat niet: al je communicatie kan door eender wie gelezen worden die zich tussen jouw computer en je eindbestemming nestelt. Het helpt echter niet dat je data versleuteld wordt als je niet kan bevestigen dat de ontvangende website ook effectief diegene is die je nodig hebt, vandaar dat dus certificaten en HTTPS in tandem werken om gebruikers een veiliger Internet aan te bieden.
Pas in 2017 boden meer dan de helft van de websites wereldwijd HTTPS aan. In 2021 gebruikt ongeveer 70% van alle websites HTTPS als standaard communicatiemiddel aan (vroeger waren er al websites met HTTPS, maar HTTP was de standaard oplossing).
Het ergste dat voor een CA kan voorvallen is dat de betrouwbaarheid van de CA in het gedrang komt. Als een CA bijvoorbeeld weet heeft van een potentiële inbraak op zijn systemen dan bestaat er de kans dat aanvallers de private sleutel van de CA hebben bemachtigd en dus zelf certificaten op naam van de CA kunnen genereren, met alle gevolgen van dien! Indien dus deze kans bestaat, is er een breach of trust en zullen alle certificaten van deze CA als ongeldig worden bestempeld, inclusief alle certificaten van sub-CA’s! Dit kan verregaande gevolgen hebben.
In 2011 werd de Nederlandse CA DigiNotar gehackt. De aanvallers konden valse certificaten uitgeven voor onder andere google.com, die vervolgens werden ingezet om Iraanse Gmail-gebruikers te bespioneren. Zodra de inbraak publiek werd, verwijderden browserfabrikanten DigiNotar uit hun lijst van vertrouwde root-CA’s. Alle certificaten van DigiNotar werden daarmee in één klap ongeldig - ook die van de Nederlandse overheid, die DigiNotar gebruikte voor DigiD en andere diensten. DigiNotar zelf ging binnen enkele weken failliet. Het incident toont hoe fragiel de chain of trust is: één gecompromitteerde CA kan het vertrouwen voor duizenden sites kapotmaken.
Certificaten bekijken
In iedere moderne browser kan je snel bekijken hoe zo’n certificaat er juist uitziet. Als je via een HTTPS verbinding naar een website surft, dan op het slotje naast de URL in de adresbalk klikt kan je doorklikken om het certificaat te openen. Als je naar HTTPS://www.belgium.be surft en dit doet dan krijg je eerst wat samenvattende informatie:
Zo zien we onder andere de geldigheidsduur, alsook de CA die dit certificaat heeft gegenereerd. Onder details kunnen we onder andere de publieke sleutel zien van de website alsook de gebruikte algoritmes voor de hash, e.d.
En op de laatste tab, Certificeringspad, zien we de chain of trust. We kunnen vervolgens hier de bovenliggende certificaten bekijken.
Het certificaat van Sectigo is uiteraard een selfsigned certificate, daar zij “bovenaan de hiërarchie staan”. Als we Sectigo niet vertrouwen dan kunnen we ook de communicatie met belgium.be niet vertrouwen.
Persoonlijke certificaten
Naast certificaten voor webservers (zogenaamde SSL certificaten) kan je ook een persoonlijk certificaat aankopen om je eigen identiteit aan derden te bewijzen tijdens bijvoorbeeld e-mail-communicatie. Voorts heb je ook code signing certificaten die de echtheid van een applicatie bewijzen zodat je zeker bent dat je geen malware installeert als je programma X hebt gedownload.
Persoonlijke certificaten worden ook gebruikt voor mutual TLS (mTLS), een uitbreiding op gewone HTTPS waarbij niet alleen de server, maar ook de client zich met een certificaat authenticeert. Dit wordt vaak gebruikt in bankomgevingen, e-government, bedrijfs-VPN’s en communicatie tussen backend-servers, waar de server zeker wil zijn dat de client effectief is wie die beweert te zijn. Bij gewone HTTPS gebeurt dit niet omdat een website in principe elke bezoeker welkom heet.
Als je in Windows 10 of nieuwer een applicatie of installer probeert uit te voeren dan zal de ingebouwde SmartScreen service ogenblikkelijk de echtheid (of ontbreken van) het certificaat controleren, net zoals dit ook in de browser zou gebeuren.
Wil dat dan zeggen dat je applicaties niet kunt vertrouwen die door Smart Screen als onveilig worden aangeduid? Neen, dat niet. Je mag niet vergeten dat een certificaat geld kost en dat niet alle software-ontwikkelaars de middelen hebben om een officieel certificaat te kopen. Het loont dus altijd om extra waakzaam te zijn wanneer Smart Screen een waarschuwing geeft, maar het is dus niet zo dat de software automatisch als onveilig moet gehanteerd worden.
Je kan via de Certification Manager van Windows bekijken welke certificaten je lokaal hebt geïnstalleerd, welke worden vertrouwd, etc. Je kan de GUI-versie van deze tool opstarten door “certlm.msc” uit te voeren.
Web of Trust: een alternatief voor PKI
Het PKI-model steunt op gecentraliseerde Certificate Authorities die de identiteit van sleuteleigenaars garanderen. Er bestaat echter ook een gedecentraliseerd alternatief: het Web of Trust (WoT), dat bekend werd door PGP (Pretty Good Privacy) en de open-source variant GPG (GNU Privacy Guard).
In een Web of Trust zijn er geen centrale autoriteiten. In plaats daarvan ondertekenen gebruikers elkaars publieke sleutels. Als Alice de publieke sleutel van Bob persoonlijk heeft geverifieerd (bijvoorbeeld door zijn key fingerprint te vergelijken tijdens een ontmoeting), kan zij zijn sleutel ondertekenen met haar eigen private sleutel. Hiermee verklaart Alice: “Ik bevestig dat deze publieke sleutel effectief van Bob is.”
Stel nu dat Carol de sleutel van Bob nodig heeft maar hem niet persoonlijk kent. Als Carol wél Alice vertrouwt en ziet dat Alice de sleutel van Bob heeft ondertekend, dan kan Carol via dat vertrouwenspad besluiten om ook Bobs sleutel te aanvaarden. Zo ontstaat een netwerk (een web) van onderlinge vertrouwensrelaties.
| Eigenschap | PKI | Web of Trust |
|---|---|---|
| Vertrouwensmodel | Hiërarchisch (top-down via CA’s) | Gedecentraliseerd (peer-to-peer) |
| Wie valideert? | Certificate Authorities | De gebruikers zelf |
| Zwak punt | Eén gecompromitteerde CA treft iedereen | Vergt actieve deelname van gebruikers |
| Typisch gebruik | HTTPS, e-mail (S/MIME), code signing | PGP/GPG e-mailencryptie, softwarepakketten |
Het Web of Trust werd jarenlang gebruikt door de PGP/GPG-gemeenschap, onder andere via zogenaamde key signing parties waar mensen fysiek samenkwamen om elkaars sleutels te verifiëren en te ondertekenen. In de praktijk bleek het model echter moeilijk schaalbaar: het vergt veel moeite van individuele gebruikers en het is lastig om een betrouwbaar vertrouwenspad te vinden naar iemand die je niet kent. Daarom wordt voor de meeste toepassingen op het Internet vandaag het PKI-model met Certificate Authorities gebruikt.
HTTPS en TLS
Certificaten vormen het hart van een veilige manier van surfen. HTTPS, “HTTP-Secure”, zorgt ervoor dat de communicatie tussen je browser en de website via een beveiligde, geëncrypteerde tunnel gebeurt. Tegenwoordig is HTTPS de default manier om een website te benaderen, maar dat is maar recent. Vroeger gebeurde alles via HTTP, waardoor iedereen die jouw trafiek kon sniffen, kon zien welke informatie je met de website uitwisselde.
HTTPS is een protocol dat een beveiligde encryptietunnel opzet tussen jou en de website waarover vervolgens gewoon HTTP-verkeer kan verlopen (dit gebeurt over poort 443 in plaats van de klassieke poort 80 waarover HTTP verloopt). Deze tunnel wordt opgezet door het TLS-protocol, het Transport Layer Security protocol, dat de opvolger is van SSL (Secure Sockets Layer). TLS gebruikt certificaten om te vergewissen dat de website aan de andere zijde wel degelijk de website is die de gebruiker verwacht. Het doet dit door de publieke sleutel van de website eerst te controleren voor het vervolgens deze sleutel gebruikt om een gemeenschappelijke sleutel af te spreken die zal dienst doen als de encryptie-sleutel voor de gemeenschappelijke tunnel. Vanaf dit punt kunnen derden de trafiek van en naar de website niet meer sniffen.
Samengevat: HTTPS is de combinatie van HTTP en een veilige encryptietunnel die met behulp van het TLS protocol wordt opgezet.
Samengevat zal dus TLS twee zaken doen:
- Door middel van een certificaat (asymmetrische crypto) wordt de identiteit (de publieke sleutel) van de website gecontroleerd.
- Door middel van een afgesproken algoritme (Diffie-Hellman, Forward Secrecy, Elliptic Curve, etc.) een gemeenschappelijke sleutel(s) afspreken en uitwisselen.
Zoals reeds eerder vermeld is asymmetrische crypto trager, waardoor het altijd aanbevolen is om de trafiek tussen 2 punten finaal via een symmetrische crypto verbinding te laten plaatsvinden. TLS/HTTPS combineert met andere woorden de sterktes van beide soorten crypto om zo de zwaktes van beiden te neutraliseren.
De manier waarop een TLS-verbinding wordt opgezet is vrij uitgebreid. Volgende briljante website (tls.ulfheim.net/) visualiseert de berichten die server en client uitwisselen om zo’n verbinding te starten, onderhouden en eindigen.
Alhoewel HTTPS onze verbinding een pak veiliger maakt, heeft het voor je ISP (Internet Service Provider, bijvoorbeeld Telenet of Proximus) en de website ook enkele nadelen. Omdat alle informatie geëncrypteerd wordt heeft de ISP geen enkel idee wat voor informatie je aan het uitwisselen bent, waardoor caching ook niet meer mogelijk is. In een normale HTTP-omgeving kan een ISP trafiek over het Internet uitsparen door een reeds bewaarde versie van hetgeen jij nodig hebt uit de cache te halen en naar je te sturen. Ook de website naar waar je surft, ondervindt dit nadeel: het zal met HTTPS veel meer trafiek genereren dan wanneer de tussenliggende ISP een deel van het werk via zijn caching overnemen.
End-to-end encryptie onder druk: Apple en de UK
End-to-end encryptie (E2EE) zorgt ervoor dat enkel de zender en ontvanger de inhoud van berichten of data kunnen lezen - zelfs de dienstverlener (zoals Apple of Google) heeft geen toegang. Dit principe is een directe toepassing van de publieke cryptografie die we in dit hoofdstuk bespraken: data wordt versleuteld met de publieke sleutel van de ontvanger en kan enkel met diens private sleutel worden ontsleuteld.
In 2025 werd Apple door de Britse overheid gedwongen om Advanced Data Protection (ADP), de end-to-end encryptie van iCloud-data, uit te schakelen voor alle gebruikers in het Verenigd Koninkrijk. De overheid eiste namelijk een backdoor: een manier voor opsporingsdiensten om toegang te krijgen tot versleutelde gegevens. Apple weigerde een backdoor in te bouwen (omdat dit de beveiliging voor alle gebruikers zou verzwakken) en koos er in plaats daarvan voor om de E2EE-functionaliteit in het VK volledig te verwijderen. iMessage, FaceTime en iCloud Keychain behielden wel hun end-to-end encryptie.
Dit voorbeeld illustreert een fundamenteel spanningsveld in cryptografie: een backdoor die enkel voor “de goeden” werkt, bestaat niet. Zodra er een achterpoortje in een encryptiesysteem zit, is het slechts een kwestie van tijd voordat ook kwaadwillige actoren deze ontdekken of misbruiken. Dit gaat recht in tegen Kerckhoffs principe: de veiligheid van het systeem mag enkel afhangen van de geheimhouding van de sleutel, niet van het verbergen van zwakheden in het systeem zelf.
Chat Control: ook in de EU
Dit debat speelt niet enkel in het Verenigd Koninkrijk. De Europese Commissie stelde in 2022 de Child Sexual Abuse Regulation voor, beter bekend als Chat Control. Dit voorstel zou chatdiensten zoals WhatsApp en Signal verplichten om berichten van alle gebruikers automatisch te scannen op illegale inhoud - ook berichten die end-to-end versleuteld zijn. Critici, waaronder cryptografen en organisaties als de EFF en EDRi, waarschuwen dat dit technisch neerkomt op het inbouwen van een backdoor of het installeren van client-side scanning (spyware op het toestel zelf), wat de facto end-to-end encryptie onmogelijk maakt.
Na jarenlange controverse en tegenstand vanuit het Europees Parlement, werd het meest omstreden onderdeel (het verplicht scannen van versleutelde berichten) in 2025 afgezwakt. Het voorstel wordt echter nog steeds onderhandeld en de uiteindelijke impact op E2EE blijft onzeker.
De kern van het probleem is telkens hetzelfde: je kan niet tegelijk echte end-to-end encryptie garanderen én een manier voorzien om berichten te lezen. Of de sleutel is geheim, of hij is het niet - er is geen tussenweg.
Mitmproxy
Mitmproxy is een krachtige linux-tool die een man-in-the-middle aanval op HTTPS toelaat. Het zal ervoor zorgen dat een aanvaller zich tussen jou en het Internet kan nestelen en vervolgens doen alsof al je HTTPS-verbindingen veilig blijven. In de praktijk zorgt mitmproxy ervoor dat alle HTTPS-verbindingen van de client naar de aanvaller gebeuren, die op zijn beurt TLS tunnels zal opzetten met de website waar het slachtoffer naar surft. Hierdoor kan de aanvaller enerzijds alle trafiek lezen, maar bijvoorbeeld ook ongezien aanpassen.
De aanvaller zal echter nog steeds geen geldige certificaten kunnen genereren waardoor moderne browsers normaal gezien hier een waarschuwing zouden moeten geven.
Samenvatting
Cryptografie is de gereedschapskist waarmee we CIA realiseren. De centrale inzichten uit dit hoofdstuk:
- Kerckhoffs is de kern: alleen de sleutel moet geheim blijven, nooit het algoritme. Security through obscurity is een valstrik.
- Oude technieken (Caesar, Vigenère, scytale) combineren substitutie en transpositie - dezelfde bouwstenen die AES nog steeds gebruikt.
- Symmetrische encryptie is snel (AES als de-facto standaard, gebaseerd op het Belgische Rijndael) maar kent het sleuteloverdrachtsprobleem.
- De blockcipher-mode is even kritiek als de cipher zelf: ECB lekt patronen, CBC/CTR niet - mits correcte IV/nonce.
- Asymmetrische encryptie (RSA, ECC) lost het sleuteloverdrachtsprobleem op via een publiek/privé-sleutelpaar. Diffie-Hellman laat twee partijen zonder vooraf gedeeld geheim een gezamenlijke sleutel afspreken.
- Hashes zorgen voor integrity, digitale handtekeningen voegen daar authenticiteit en non-repudiation aan toe.
- Digitale certificaten en PKI lossen het vertrouwensprobleem op - maar enkel zolang de CA betrouwbaar blijft (cfr. de val van DigiNotar).
- HTTPS/TLS combineert al deze bouwstenen, en toch blijft het kwetsbaar zonder goede certificaatvalidatie, zoals mitmproxy aantoont.
- Cryptanalyse dwingt sleutels steeds langer te maken; quantum-computers bedreigen RSA/ECC op lange termijn - store now, decrypt later is een realistische dreiging.
In het volgende hoofdstuk zien we hoe authenticatie op deze crypto-bouwstenen steunt.