De website heeft zojuist een van haar bekendste privacylekken gesloten. Encrypted Client Hello, beter bekend als ECH, is nu een officiële standaard van de IETF, de organisatie die veel van de basale protocollen van het internet definieert. De specificatie werd op 3 maart gepubliceerd als RFC 9849, wat een formele status geeft aan deze technologie die de manier waarop versleuteld webverkeer wordt beschermd zou kunnen veranderen. Bovendien maakt het het nog moeilijker om blokkades uit te voeren op basis van domeinnaaminspectie tijdens het opbouwen van de verbinding.
Het nieuws heeft aanzienlijke technische implicaties, maar ook politieke, juridische en zakelijke aspecten. Jarenlang versleutelde het TLS-protocol de inhoud van HTTPS-verbindingen, maar liet het een bijzonder gevoelige informatie zichtbaar: de SNI, het veld waarmee de browser aangeeft op welk domein hij wil verbinden wanneer meerdere websites op hetzelfde IP-adres hosten. Deze informatie is lange tijd een essentiële sleutel geweest voor providers, filtratiesystemen en selectieve blokkeringmechanismen. Met ECH wordt deze informatie niet langer in platte tekst verzonden.
Het verschil: niet meer web versleutelen, maar de start van de verbinding beter beveiligen
Wat ECH doet, is niet HTTPS vervangen, maar het versterken op een van zijn meest kwetsbare punten. Hoewel TLS 1.3 al veel had verbeterd op het gebied van privacy tijdens de handshake, bleef de SNI en een deel van de andere initiële metadata nog steeds zichtbaar. RFC 9849 definieert een mechanisme om de ClientHello van de browser te versleutelen met de publieke sleutel van de server, zodat waarnemers op het netwerk de echte domeinnaam niet langer duidelijk kunnen zien.
Dit betekent niet dat ECH het gehele surfgedrag onzichtbaar maakt. De standaard benadrukt dat het niet voldoende is om alleen de identiteit van de server te verbergen, vooral als DNS-queries nog steeds in platte tekst worden gedaan of als het IP-adres van de bestemming uniek en gemakkelijk herleidbaar is. Maar het elimineert wel een van de meest bruikbare signalen voor passieve inspectie van verkeer. In een internet waar veel websites IP-adressen delen en waar versleutelde DNS langzaam vordert, kan het praktische effect aanzienlijk zijn.
Bovendien is ECH niet uit de lucht komen gevallen of uitsluitend ontwikkeld door één bedrijf. Het is het resultaat van jarenlange inspanningen binnen de IETF en wordt ondertekend door onder andere Eric Rescorla, Kazuho Oku, Nick Sullivan en Christopher A. Wood, met deelname van partners als Apple, Fastly en de technologische gemeenschap die TLS heeft doorontwikkeld. Parallel hieraan definieert een aanvullend document, RFC 9848, hoe deze ECH-configuraties bekend te maken via DNS SVCB en HTTPS-registraties, een essentiële stap voor daadwerkelijke implementatie.
Cloudflare, Firefox en grote browsers versnellen de adoptie
Hoewel het officiële standaard nu is aangenomen, was de praktische toepassing al geruime tijd gaande. Cloudflare kondigde in 2023 de beschikbaarheid van ECH aan voor al haar plannen en gaf in 2024 aan de implementatie samen met browserpartners verder te versterken. Mozilla introduceerde ECH in Firefox 118 en zette het standaard aan in Firefox 119, waarmee zij de privacy verder verbeterden ten opzichte van netwerkintermediairs.
Ook Apple beweegt in deze richting. De documentatie voor ontwikkelaars bevat ondersteuning voor het activeren van Encrypted Client Hello binnen het beveiligingskader, een duidelijke indicatie dat deze technologie inmiddels geïntegreerd is in de kern van grote platforms. Met andere woorden: de formaliteit van het RFC-document markeert niet het begin vanaf nul, maar het moment waarop de technische basis al stevig ligt en grote spelers hun voorbereidingen hebben getroffen.
Dat is belangrijk, omdat het in het internetlandschap niet altijd betekent dat een standaard meteen breed wordt toegepast. Maar in dit geval biedt ECH een zeldzame voorsprong: er is al ervaring met de implementatie, er zijn browsers die het gebruiken en infrastructuuraanbieders die het ondersteunen. Alles wijst erop dat de adoptie gaandeweg zal toenemen, maar wel voortdurend.
Waarom ECH botsen kan met domeinblokkering door providers
De goedkeuring van ECH is niet alleen relevant voor netwerkingenieurs en privacyexperts. Het raakt ook direct de partijen die afhankelijk zijn van de SNI om restricties toe te passen. In Nederland is dat bijvoorbeeld zichtbaar in de strijd tegen online piraterij. Liga en Telefónica hebben voor de rechter gepleit voor blokkades gebaseerd op domeinen en IP-adressen, en schakelden over op meer ingrijpende methoden toen versleuteling de traditionele filtering begonnen te ondermijnen.
Specialistische media, die toegang hadden tot juridische documenten, stellen dat in de ondersteunde documenten expliciet wordt vermeld dat ECH en Apple’s Private Relay de effectiviteit van blokkades op basis van verkeersanalyse verminderen. In dat licht werd de aanpak verschoven van het blokkeren van specifieke domeinen naar IP-blokkeringen, met het risico dat ook derden die dezelfde infrastructuur delen, getroffen worden.
De Liga uit kritiek dat haar strategie wordt gesteund door de rechter en dat er geen sprake is van willekeurige blokkades of verlies van garanties. Het debat is dus niet gesloten: sommigen wijzen het aan als een legitieme maatregel ter bescherming van audiovisuele rechten, anderen vinden dat het technisch onnodig ingrijpend is en schadelijk voor onschuldige gebruikers en diensten.
Wat met ECH verandert, is het technische speelveld. Als de werkelijke domeinnaam niet langer in duidelijkheid zichtbaar is tijdens de start van TLS, wordt het blokkeren op basis van die naam veel moeilijker. Dit dringt de noodzaak verder te gaan naar ingrijpender en complexere methoden, zoals IP-blokkades of meer invasieve inspraakoefeningen. Daarom is deze RFC zo belangrijk, ook buiten de technische wereld.
Een standaard voor privacy met bredere gevolgen
ECH is ontworpen om de privacy te verbeteren en het delen van gevoelige metadata te beperken. Maar zoals bij veel beveiligingstechnologieën, heeft het ook invloed op het bredere netwerkregime. Het bemoeilijkt censuur via passieve inspectie, beperkt bepaalde vormen van toezicht en vereist dat bestaande instrumenten voor beheer en filtering opnieuw worden geëvalueerd.
Het betekent niet dat alle problemen weg zijn. De standaard waarschuwt expliciet voor implementatiefouten, middleboxes en beperkingen in de praktijk. Sommige toepassingen die afhankelijk waren van onversleuteld TLS-informatie, zullen alternatieven moeten zoeken, bijvoorbeeld in bedrijfsomgevingen, via proxies of meer invasieve controles. Maar de kernboodschap is duidelijk: het oude SNI in tekst blijft niet langer relevant voor de toekomstige webarchitectuur.
De vraag is nu niet meer of ECH een standaard wordt, maar hoe snel browsers, CDN’s, hostingproviders en operators het zullen adopteren. Tegelijkertijd zullen zij die hun blokkade- en monitoringsystemen construeren op gegevens die nu verdwijnen, zich moeten aanpassen.
Veelgestelde vragen
Wat is ECH en waarvoor dient het?
ECH, of Encrypted Client Hello, is een uitbreiding van TLS die het initiële verbindingsbericht van de browser met de server versleutelt. Het belangrijkste doel is om de werkelijke bestemming, het domein, en andere gevoelige metadata te verbergen die vroeger in het begin van een HTTPS-verbinding zichtbaar waren.
Vervangt ECH HTTPS of TLS 1.3?
Nee. ECH vervangt HTTPS en TLS 1.3 niet, maar biedt aanvullingen. Het versterkt vooral de eerste fase van de verbinding, waar nog elementen zoals de SNI zichtbaar waren.
Waarom maakt ECH het moeilijker voor providers om websites te blokkeren?
Omdat veel selectieve blokkades afhankelijk waren van het in platte tekst lezen van de SNI om te bepalen welke website werd bezocht. Als die informatie wordt versleuteld, wordt deze techniek onbruikbaar en moeten meer ingrijpende of bredere methoden worden ingezet.
Verbergt ECH volledig welke website een gebruiker bezoekt?
Niet helemaal. Het standaard erkent dat er nog andere aanwijzingen kunnen zijn, zoals onvervale DNS-queries of IP-adressen die eenvoudig kunnen worden gekoppeld aan een enkele service. ECH verbetert dus de privacy, maar garandeert die niet in alle scenario’s afzonderlijk.
Bronnen: