Digital Meet-up Privacy & Security: de controverse over dns-over-https

Wie heeft eigenlijk de controle over 'jouw' internet? Het afgelopen jaar lag hij in steeds grotere mate bij techbedrijven in plaats van je internetprovider. Google, Apple en Mozilla implementeren langzaam maar zeker dns-over-https. En hoewel meer versleuteling in eerste instantie misschien goed klinkt, zitten er ook veel nadelen aan, stelt Bert Hubert van PowerDNS.

Als je voor het eerst hoort van dns-over-https (DoH) denk je wellicht dat het een goed systeem is. Dns-queries worden normaal gesproken niet versleuteld. Daardoor kan bijvoorbeeld een internetprovider makkelijk zien welke sites je bezoekt en welke iot-apparaten je op je netwerk gebruikt. Versleuteling lijkt dus verstandig, maar het zorgt er niet voor dat je volledig anoniem wordt. Sterker, met dns-over-https verleg je de controle juist van je internetprovider naar een commercieel Amerikaans bedrijf, en daar kun je volgens Bert Hubert best wat vragen bij stellen.

"Er zijn een paar partijen die heel graag jouw dns willen overnemen", vertelt Hubert. "Google en Apple willen dat heel graag, en Cloudflare ook. Ze staan in de rij om dit helemaal gratis voor je te doen. Maar als ze het gratis willen doen, moet je je afvragen waarom." De redenen zijn verschillend. Apple zet de laatste jaren in op privacy als verkoopfeature, maar het bedrijf wil ook graag alles binnen zijn eigen ecosysteem houden, inclusief de internetverbinding. Voor Google spelen andere belangen mee; dit bedrijf wil bijvoorbeeld meer te weten komen over gebruikers.

Inmiddels gaan de meeste grote bedrijven stapje voor stapje over op dns-over-https. "In Firefox staat het in de VS tegenwoordig standaard aan, maar steeds minder gebruikers merken dat", zegt Hubert. In Chromium, en daarmee dus ook Edge, kunnen dns-queries via Googles resolver worden geleid, al is dat nog niet actief aangezet. En ook in iOS wordt de verbinding met de Apple-servers versleuteld via het DoH-protocol.

Hubert vindt dat internetgebruikers goed zouden moeten nadenken over de voor- en nadelen van dns-over-https. "Je krijgt er namelijk al snel een situatie mee waarin je je eigen netwerk niet meer vertrouwt, maar dat van Google wel", zegt hij. Ook voor bedrijven die liefst hun eigen resolver draaien kan DoH grote problemen op het netwerk veroorzaken.

Tijdens de Tweakers Meet-up Security & Privacy vertelt Bert Hubert alles over de voor- en nadelen. Hij toont wat je allemaal kunt zien door het afvangen van dns-queries en waarom je DoH wel of juist niet in je netwerk zou moeten willen.

Registreer je nu!

Mocht je enthousiast zijn geworden en wil je graag zeker zijn van een online plekje om de Digital Meet-up Privacy & Security te volgen, registreer je dan nu voor een gratis ticket. Het platform dat we voor deze meet-ups gebruiken is EventInsight. De Digital Meet-up Privacy & Security is alleen bij te wonen via je desktop. Om de meeste vragen daarover alvast te beantwoorden, hebben we een Q&A opgesteld.

Nadat je je hebt geregistreerd ontvang je een ticket. De QR-code die is afgebeeld op het ticket wordt niet gebruikt voor deze digitale meet-up. Je hoeft hem dus niet te gebruiken voor het aanmeldproces. Op 7 november om 12.30 uur ontvang je een e-mail vanuit @Eventinsight (check ook je spambox) met jouw inloggegevens.

Reacties (18)

[Jazco2nd]

In de VS, waar het heel gewoon is dat jouw internetprovider je surfhistorie verkoopt aan adtech partijen en B2C bedrijven, is het heel logisch dat DoH flink populariteit wint, browsermakers het implementeren, allerlei aanbieders VPN aanbieden etc.

Maar in NL en Europa, is DoH eigenlijk gek: je houdt namelijk jezelf voor de gek.
DoH versleuteld alleen tot de "eerste hop", de eerste DNS server. Daarna wordt je complete request zonder versleuteling nog naar een onbekend aantal DNS servers verstuurd, servers waarvan jij niks weet, ook niet welke organisatie (binnen of buiten de EU) daarachter zit.

Juist vanaf de eerste hop wil je beschermd zijn. Het is dan logischer om een recursive DNS oplossing te zoeken zoals Unbound bijvoorbeeld bied. Ipv DoH.

[ewoutpockele]

Ik ga akkoord met je mening dat een eigen recursive resolver draaien beter is als het op privacy aankomt (zeker als je dan heel je huishouden daarop zet).

Echter denk ik dat je DNS niet helemaal goed begrijpt, want je query wordt niet nog eens rond gestuurd. Stel ik wil weten waar test.example.org te vinden is, dan stuur ik een request naar mijn DNS server. Als die server dat in zijn cache heeft opgeslagen, kan die mij antwoorden met gegevens uit die cache. Zo wordt er nooit een query doorgestuurd naar andere servers.

Weet jou DNS server test.example.org niet zijn, zal hij eerst bij de root servers opvragen 'waar kan ik de authorative server van .org vinden?'. De root server antwoordt dan in de stijl 'De authorative server voor .org vindt je op address X'. Jouw server stuurt dan naar de DNS server op address X 'waar kan ik de authorative server voor example.org vinden?'. Die antwoordt dan met 'De authorative server voor example.org vindt je op addres Y'. Als laatste vraagt hij dan aan de DNS server op address Y 'Waar kan ik test.example.org vinden?'. Als alles goed is gegaan krijgt hij dan een antwoord, en stuurt die dat door naar jou apparaat die de initiele query maakte.

Uiteraard zullen veel van die authorative nameservers al in de cache zitten, waardoor hij vaak alleen die laatste stap moet maken om jou te antwoorden, maar dit is de algemene flow van een DNS request. Jouw volledige request wordt dus nooit doorgestuurd, het is jouw DNS server die in jouw plaats gaat rond-vragen.

Als de server die je gebruikt van, bijvoorbeeld, de provider komt kunnen zij uiteraard noteren welke requests jij allemaal maakt, maar dit wordt niet standaard doorgestuurd naar anderen.

[Jazco2nd]

Maar het voorbeeld wat je geeft is juist recursive DNS. Dat is waar ik op doel.
En dat is voor zover ik weet niet hoe DNS servers standaard werken. Bijvoorbeeld je ISP. Recursief het adres aflopen zoals je voorbeeld is dan niet de standaard keuze als het adres niet bekend is (in cache).

[Reactie gewijzigd door Jazco2nd op 24 juli 2024 12:19]

[ewoutpockele]

Ik doelde met mijn antwoord vooral op het feit dat je request niet letterlijk wordt rondgestuurd naar Jan-en-alleman, zoals je lijkt te insinueren.

Je request is dus (in principe) niet direct identificeerbaar als zijnde van jou, wat mijn originele punt was. Uiteraard kan er met extra informatie nog achterhaald worden welke requests van jou waren.

[lenwar]

Het blijft een heerlijke discussie
Mijns inziens worden er altijd twee zaken door elkaar heen gehaald.
Namelijk het protocol zelf, en de huidige beschikbaarheid/implementatie ervan.

Mijn mening: DoH (of DoT) is op zich een goed systeem en zou je eigenlijk altijd moeten willen gebruiken. Het 'probleem' dat er een paar commerciele tokos zijn waar je je van afhankelijk maakt is wat mij betreft een non-argument tegen DoH als protocol.
Waar ik me zeker wel in kan vinden is de huidige beschikbaarheid van DoH providers. Idealiter zouden alle DNS-servers van ISPs ook DoH praten, zodat er niet een paar grote partijen zijn die alle DNS-servers faciliteren.

Dat het iets moeilijker wordt om DNS-verkeer te filteren is wat mij betreft ook niet echt een valide tegenargument tegen het protocol. Hooguit tegen de huidigen implentatie van het protocol. Er is niet dat een Chromecast ervan kan weerhouden om DoH op poort 30443 te praten naar de Google servers. Net zo min dat diezelfde Chromecast ook onversleuteld DNS, DoT, of wat voor andere methodiek dan ook op een willekeurige poort. Dit staat allemaal los van het protocol zelf. Alleen de implementaties ervan.

Vaak wordt het gebruik van een netwerk DNS-filter aangehaald (pi-hole, Adguard Home, enz) en dat je die dan met wat handige iptables-regeltjes naar je lokale service kan forceren. Ook dit heeft niks te maken met het DoH protocol. Een apparaat kan prima op een willekeurig andere poort met een custom DNS-server praten als dat wenselijk is voor dat apparaat. Het is dus hooguit weer de implementatie ervan.

Bedrijven die hun netwerken goed willen controleren zullen inderdaad iets beter hun best moeten gaan doen met transparante https-certificaten en zo met DPI controleren of er niet een apparaat is dat niet netjes praat, maar ook dat staat los van DoH. Dat zullen ze toch al moeten doen.

[NBK]

Er is wel iets mis met het protocol zelf. Het is niet te onderscheiden van 'legitiem' https verkeer.
Waarom niet gewoon SSL op DNS(SEC) implementeren?

Nou is het misschien wel te blokkeren door https verkeer naar de DNS servers van google te blokkeren maar word tijd om dat eens uit te gaan zoeken.

Het moment dat ik op een apparaat of browser DoH niet meer kan uitzetten gaat bij mij dat apparaat gewoon uit.

[Reactie gewijzigd door NBK op 24 juli 2024 12:19]

[lenwar]

Waarom niet gewoon SSL op DNS(SEC) implementeren?

Dan creëer je toch hetzelfde probleem maar dan omgekeerd. Dan kan een stuk malware op port 53 versleuteld communiceren?
De gebruikte poort staat overigens los van het protocol. Je kan DoH op iedere port laten werken. (binnen redelijkheid). Dat is dus wederom een stukje implementatie t.o.v. het protocol zelf.

Je kan met transparante on-the-fly gegenereerde SSL-certificaten een heel end komen om het verkeer te onderscheppen, controleren en om te leiden of blokkeren als dat wenselijk is.
Dat is iets wat heel veel grote bedrijven doen en is technisch niet zo heel spannend om uit te voeren. Ook iets hippere stukken firewall software (danwel transparante proxy servers) kunnen dit gewoon doen.
De software/apparaten moeten dan wel de door jouw ondertekende certificaten accepteren, dus mogelijk dat je daar tegen aan gaat lopen in het geval van een bijvoorbeeld een Chromecast. Ik weet niet hoe strak die controleren.

Wat jij een overigens een nadeel noemt van DoH dat het 'verdwijnt' tussen het reguliere https-verkeer, is voor heel mensen ook juist een voordeel. (denk bijvoorbeeld aan landen waar ze niet zo vrij zijn als in Nederland of België. Uiteraard kan je dan stellen dat je daar niks mee te maken hebt, omdat je daar niet woont, maar het is niet een regionaal gebruikt protocol )

[Anoniem: 1322]

Je kan met transparante on-the-fly gegenereerde SSL-certificaten een heel end komen om het verkeer te onderscheppen, controleren en om te leiden of blokkeren als dat wenselijk is.

En daarom zitten we nu in deze situatie.... En dit gaat in de toekomst echt niet meer werken...
Zo zal Chrome echt niet naar google.com gaan als jij er zelf even een certificaat tussen stopt. Dat was in 2014 al een no-go: nieuws: Google ontdekt valse ssl-certificaten voor Google-sites

En zo gaat er nog veel meer kapot. Er zijn zeker in de grotere bedrijven genoeg apps die aan certificate pinning doen. Ik heb in het verleden wel eens een bank app moeten troubleshooten die echt geen enkele inspectie toestond. Groot gelijk natuurlijk..

Anyway, je verhaal klopt wel. Zodra er meer aanbieders zijn zal het wel loslopen. Maar firewall SSL inspectie is gewoon een afgelopen zaak. We hebben ook veel betere oplossingen tegenwoordig. Zoals conditionele toegang, containering van applicaties en moderne virusscanners die niet enkel acteren op virusdefinities.

[Reactie gewijzigd door Anoniem: 1322 op 24 juli 2024 12:19]

[Zer0]

Je kan met transparante on-the-fly gegenereerde SSL-certificaten een heel end komen om het verkeer te onderscheppen, controleren en om te leiden of blokkeren als dat wenselijk is.

Dus een op privacy gericht protocol dwingt je privacy van je gebruikers te ondermijnen en SSL verkeer te onderscheppen?

[Zer0]

Er is niet dat een Chromecast ervan kan weerhouden om DoH op poort 30443 te praten naar de Google servers. Net zo min dat diezelfde Chromecast ook onversleuteld DNS, DoT, of wat voor andere methodiek dan ook op een willekeurige poort. Dit staat allemaal los van het protocol zelf. Alleen de implementaties ervan.

Er is wel degelijk iets wat een Chromecast tegen houd om DoH op poort 30433 te gebruiken, namelijk een goed geconfigureerde firewall. Standaard blokkeer je alle poorten die niet voor legitieme zaken gebruikt worden. Verkeer op poort 443 kun je echter niet zomaar blokkeren omdat dat ook legitiem https verkeer niet meer mogelijk is.

[lenwar]

Uiteraard klopt dat helemaal. Ik verwoordde het uiteraard wat kort door de bocht.
In de praktijk zal je echter zien dat vrijwel alle consumentenfirewalls (dus dan doel ik op de firewalls die op de ziggo-modems zitten) naar buiten toe gewoon vrijwel volledig open staan.

Echter. Als je het zou blokkeren dan doet heel die Chromecast het niet, want hij heeft dan geen DNS (over https). Dan zou je kunnen zeggen. Ik forward hem naar m'n eigen DoH-server, maar als die Chromecast de handtekening controleert van de DoH server gaat er nog steeds niks gebeuren. Want één van de belangrijkste zaken van DoH is de ondertekening van de DNS-pakketjes.

[evanuden]

Met de techniek DoH is op zich niets mis. Hoe het nu gebruikt wordt wel. Al mijn DNS info naar de VS? Daar wordt ik niet zo happy van. Er zijn een paar PowerDNS ISP`s in Nederland die DoT hebben. Dan blijft het DNS verkeer tenminste in Nederland.

[Wildfire]

Ik gebruik al jaren OpenDNS, in het verleden ondersteunden ze DNS over HTTPS niet maar dat is tegenwoordig blijkbaar veranderd: https://support.opendns.c...er-HTTPS-DoH-with-OpenDNS

Zojuist in Firefox ingesteld, voortaan in Firefox DNS over HTTPS via mijn eigen bepaalde aanbieder, OpenDNS dus

[Toet3r]

Klinkt interessant, heb ticket besteld.
Wel goed om nog om te vermelden:
In firefox op android krijg ik met geen mogelijkheid het ticket formulier ingevuld op een normale manier. Krijg als ik op invul veld ga staan geen onscreen toetsembord te zien. Moet dus elk veld los copy/pasten vanuit andere bron. Beetje irritant wel. Gelukkig is het alleen naam email en leeftijd dat je moet invuen

[Lokiban]

Met DoH werkt mijn hostfile niet meer en kom ik op Facebook, Twitter en nog meer van dat soort geblokte sites.
Dus als je hostfile niet meer werk, even DoH uitzetten en werkt weer als vanouds. Dit is voor mij de makkelijkste en snelste manier om te zien of DoH toch aan staat.

Meteen al toen Firefox met DoH uit kwam kon je zien dat Google en Cloudflare in de lijst met servers stonden om de aanvragen te verwerken. Men zette er toen al vraagtekens bij.

[streamnl]

Toen ik in mijn agenda keek of ik tijd heb, dacht eerst, "kak, dan heb ik al een Digital Meet-up staan van Tweakers, jammer".

Blijkbaar is dat dezelfde en heb ik me al eerder ingeschreven.
Het wordt tijd voor weekend...

[Anoniem: 767041]

''de controverse over dns-over-https'' dit is een leuke, vooral met nextdns.io, ze werken ook samen met firefox/mozilla, voor apple devices kan je naar https://apple.nextdns.io en een profiel downloaden voor DoH en tls. Voor android gewoon '' dns.nextdns.io '' via private dns of je kan de officiële app gebruiken

[Reactie gewijzigd door Anoniem: 767041 op 24 juli 2024 12:19]

[zvbhvb]

Lol, vpn over tor, en last but not least opendns over https.