Advertorial

Door Tweakers Partners

Dns over https maakt internet veiliger, maar tegen welke prijs?

16-07-2020 • 08:45

52

Het versleutelen van dns-verkeer is nuttig, maar ook controversieel. De beslissing van Mozilla om dns-over-https (doh) als standaard in te stellen voor de Firefox-browser werd zeker niet overal met gejuich ontvangen. SIDN, beheerder van het .nl-domein en voorvechter van een veiliger internet, kijkt kritisch naar de trend en geeft daarnaast iedereen de gelegenheid om zelf met doh te experimenteren.

Doh maakt online gaan in principe een stukje veiliger en draagt bij aan de privacybescherming van internetgebruikers, maar de gevolgen voor het domain name system (dns) zijn mogelijk ingrijpend. Verschillende grote techbedrijven hebben aangekondigd dat het op hun roadmap staat, en een aantal is al bezig met de implementatie, waaronder Google, Apple en Microsoft. Maar het is Mozilla dat met Firefox kiest voor de meest agressieve uitrol. Mozilla gebruikt doh als standaard in de Firefox-browser, waardoor deze dns-verzoeken afhandelt via door Firefox vertrouwde partijen in de VS. Een beslissing die overigens inmiddels alweer deels is teruggedraaid (doh is alleen voor gebruikers in de VS als standaard ingesteld). Toch blijven er in de wereldwijde internetgemeenschap zorgen over de implicaties.

Vertrouwde resolver

Wat is er precies aan de hand en waarom is doh zo controversieel? Het dns-protocol is al sinds 1983 het ‘telefoonboek van het internet’. Via het dns verkrijgt je browser het ip-adres waar je een website met een specifieke domeinnaam kunt vinden. Het verkeer bestaat uit een uitwisseling van vragen die je browser via een eenvoudige stub-resolver van je computer of telefoon stelt aan een recursive-server in het netwerk. Dit is meestal je internetprovider (vanaf je thuisnetwerk of voor je telefoon) of de resolver van je bedrijf. Dns-verkeer is niet versleuteld en dit is vooral op publieke wifi-netwerken een probleem. Omdat het netwerk onversleuteld is, is het voor derden mogelijk je verkeer uit te lezen, te blokkeren of te manipuleren. Doh lost dit probleem op door dns-queries te versleutelen via een beveiligde verbinding (http met tls) met een vertrouwde resolver.

Toch is de introductie van doh in Firefox vooral een reactie op een ander probleem, namelijk dat Amerikaanse Internet Service Providers (isp’s) dns-verkeer van klanten doorverkochten. “Dit vond men bij Mozilla echt niet kunnen”, legt Moritz Müller uit, research engineer bij SIDN Labs. “Daarom werd besloten dat het voor gebruikers in de VS beter en veiliger zou zijn als Firefox dns-verkeer niet naar de resolver van de lokale isp zou sturen, maar naar de resolver van Cloudflare. Met Cloudflare waren duidelijke privacyafspraken gemaakt die beter leken dan de afspraken tussen de gebruiker en de isp. Vanuit privacyoogpunt is dat een voordeel in de VS.”

Internet centraliseert verder

De VS zijn echter geen Europa, waar we betere privacywetgeving hebben in onder meer de avg. Europese isp’s mogen bijvoorbeeld niet zomaar dns-verkeer gebruiken voor marketingdoeleinden. Verschillende Europese providers blokkeren doh zelfs, zo beschreef Müller onlangs in een blogpost op sidnlabs.nl. “Als je in Europa de resolver van je isp gebruikt, is je dns-verkeer eigenlijk best goed beveiligd.” Wel is het natuurlijk zo dat het versleutelen van dns-verkeer over https het securityprobleem op publieke netwerken oplost. De doh-resolver versleutelt de query, zoekt de antwoorden en geeft deze vervolgens ook weer versleuteld terug aan je apparaat. Dit gebeurt in milliseconden, zonder merkbare gevolgen voor je internetervaring - ook op oudere en langzame apparatuur. De controverse rondom de beslissing van Firefox richtte zich aanvankelijk vooral op het doorsturen van verkeer naar een partij waar de gebruiker tot dan toe geen relatie mee had (Cloudflare). Een beweging richting centralisatie naar één of slechts enkele partijen.

Het gevaar van deze centralisatie is vooral het ‘wat als’. Wat als deze partijen niet beschikbaar zijn? En hoe zijn we beveiligd tegen machtsmisbruik door deze partijen? Wie zich zorgen maakt over latency doordat een Amerikaanse partij internetverkeer afhandelt: daar hoeft geen sprake van te zijn. “Cloudflare heeft wel meer resolvers dan eentje in de VS, het heeft een Anycast-serverinfrastructuur verspreid over de wereld. Wat betekent dat je dns-query in Nederland waarschijnlijk in een Amsterdams datacenter uitkomt.” Overigens heeft Firefox, dat het systeem voor de VS nu wel standaard aan het uitrollen is, in reactie op de kritiek inmiddels meer vertrouwde doh-resolvers aangesloten dan alleen Cloudflare. Dit zijn onder meer Next DNS en - ironisch genoeg - de Amerikaanse ISP-provider Comcast, waarmee specifieke afspraken zijn gemaakt over privacyvoorwaarden.

Experimenteren met het protocol

Als gebruiker kun je zelf je resolver kiezen, maar de default is bij Firefox een van de bovenstaande partijen. Müller: “Je kunt dit zelf instellen via het instellingenmenu. Dit vind je in de Nederlandse versie onder ‘Opties’, ‘Algemeen’, ‘Netwerkinstellingen’ en dan de knop ‘DNS over HTTPS inschakelen’. Je kunt het daar aanzetten en een partij uitkiezen, maar ook zelf een ip-adres of url invullen van een doh-resolver. Bijvoorbeeld onze eigen experimentele doh-dienst bij SIDN Labs.”

Er zijn verschillende redenen waarom je dit als gebruiker zou doen. Je zit bijvoorbeeld op een publiek netwerk. Het kan ook zijn dat je een netwerkbeheerder bent en blacklists gebruikt van malafide domeinnamen om ‘slecht’ netwerkverkeer op je dns-resolver te filteren. Müller: “Met onze doh-resolver kun je dan testen in hoeverre de beveiliging het nog doet als een gebruiker binnen het netwerk doh op zijn of haar browser aanzet. Als je de tool Wireshark gebruikt om je netwerkverkeer te monitoren, dan zie je, als je doh in je browser aanzet, bijna geen dns-verkeer meer over poort 53 (doh-verkeer gaat via poort 443, waar al het https-verkeer gebruik van maakt, red.)”. Niet meer zomaar af te luisteren dus, al geef je bij gebruik van doh toch ook nog op verschillende manieren wat informatie weg. Dus helemaal perfect is het nog niet. “Iemand anders kan bijvoorbeeld nog steeds zien naar welke servernaam je verbindt, maar daar wordt aan gewerkt via ESNI. Als je echt niet wilt dat iemand anders ziet wat je doet op het internet, heb je een vpn nodig en moet je al je verkeer versturen naar een server die je vertrouwt en bij voorkeur onder jouw volledige controle staat.”

Zoals gezegd is Mozilla niet de enige partij die bezig is met doh. Zo is het ook mogelijk om doh te gebruiken met Google Chrome, dat een lijst hanteert van vertrouwde resolvers die gebruikers in hun besturingssysteem kunnen configureren. Als een gebruiker een van deze resolvers gebruikt om plain text dns-queries te versturen, zal Chrome automatisch de verbinding upgraden naar doh. Ook Microsoft test in Windows het automatisch upgraden van de verbinding naar de in het besturingssysteem ingestelde resolver, als die doh ondersteunt. Apple, dat zich de laatste jaren steeds meer positioneert als pleitbezorger van privacy, heeft een heel eigen aanpak met IoS, iPadOS en MacOS, vertelt Müller. “Op hun Developer Conference kondigden zij onlangs aan doh te gaan ondersteunen. Zo kun je als app-ontwikkelaar bijvoorbeeld zelf resolvers hiervoor instellen, of je kunt in de toekomst zelf een doh-resolver voor het hele systeem kiezen.”

Wie controleert het internet?

De hele saga rondom de invoering van het nieuwe protocol roept de vraag op wie er eigenlijk bepaalt waar ons internetverkeer naartoe gaat. Welke controle heeft Nederland en Europa eigenlijk over ‘ons’ deel van het internet? Müller: “Tot op zekere hoogte is die er wel, maar dan wel via de politiek. Uiteindelijk is het verhaal rondom doh te technisch voor een gemiddelde gebruiker. Dat betekent dat er op een hoger niveau iets moet gebeuren en dat Europa invloed moet uitoefenen op grote techpartijen.” De roep om regulering van browsers klinkt steeds sterker. Tegelijkertijd volgt SIDN de ontwikkeling van doh op de voet, door het verrichten van internetmetingen en het informeren van internetgebruikers. Ook moedigt SIDN gebruikers aan vooral zelf te experimenteren en een opinie te vormen.

Moritz schetst het doel van SIDN: “Wij willen het Nederlandse publiek een objectief beeld over doh geven. Er zijn weinig partijen in de markt die zich hiervoor inzetten. DNS is een belangrijk maar vaak onderschat protocol, en er zijn weinig partijen die waken over de veiligheid en privacy. Wij vinden privacy belangrijk en daarin is doh een goede stap, maar niet zonder meer. Het kan in bepaalde situaties veiliger zijn, bijvoorbeeld als je in een netwerk zit dat je niet vertrouwt, maar het kan ook een zorgvuldig beveiligingsbeleid binnen een bedrijf omzeilen en dus ondermijnen. We begrijpen waar doh vandaan komt en het is goed dat partijen in de markt zich ermee bezighouden. Maar er zijn ook (neutrale) partijen nodig, zoals SIDN, die toezien op dat proces, zodat alle belangen op een objectieve manier worden meegenomen en tegen elkaar kunnen worden afgewogen”.

Webinar SIDN: Internet of Things

Op donderdag 3 september organiseert SIDN van 15.00 – 16.00 uur het interactieve webinar: ‘Internet of Things: kansen, keerzijdes én oplossingsrichtingen’. Hierin bespreken we de context van de IoT-problemen en bediscussiëren we de verschillende mogelijke oplossingen. Lijkt je dit interessant? Lees meer en meld je gratis aan.

Dit artikel is geen redactioneel artikel, maar een advertorial. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen, daar zullen collega's aanwezig zijn om jouw vragen en/of opmerkingen te bespreken/beantwoorden.

Reacties (52)

52
51
29
6
0
22
Wijzig sortering
Voor velen onder ons, die pihole (vandaag trouwens pihole v5.1.1 gereleased) gebruiken, of een gelijkaardige oplossing, is DoH een nachtmerrie. Door het gebruik van DoH verlies je alle controle over de verbindingen met externe partijen, die devices kunnen maken.
Om een en ander toch een beetje onder controle proberen te houden, ben ik sinds een paar maanden bezig met het verzamelen van de gegevens van DoH providers. Je kan hier de IPv4 en IPv6 addressen van een aantal DoH servers vinden.
Voor diegenen die een compatible firewall hebben, is het de bedoeling (als je DoH will blocken) firewall rules te maken, die port 443 naar deze IP's blocked, block nooit alle poorten, een aantal van de IPs worden ook gebruikt om de reguliere DNS service (port 53) te hosten, sommige worden zelfs gebruikt om ook content te hosten.

Om een en ander gemakkelijker te maken, heb ik een handleiding gemaakt om dit op te zetten op pfsense, feedback geeft aan dat het ook mogelijk is op OPNsense.

De uitzonderiingen (exceptions) zijn belangrijk, linuxquestions.org bijvoorbeeld zal heel traag laden, zonder deze uitzondering.

Nieuwe lijst, niet vermeld in het document? meld hier.
Probleem hier is dat alle google diensten tevens DoH servers zijn. Dit is niet te blocken.
De youtube server is dus tevens DoH. Block je poort 443 voor deze server\DoH ben je tevens de content kwijt. Dit is voor de firewall settings het grootste probleem.
in de lijst zijn 8.8.8.8, 8.8.4.4 en de IPv6 equivalenten opgenomen. Ik gebruik deze methode al een paar maand, en heb tot op heden geen problemen ondevonden met YouTube of andere diensten van google (probeer zo weinig mogelijk google services te gebruiken, maar ja, android...)

Zels al zou je statement correct zijn (voorbeeld?), daarvoor heb ik de exceptions sectie toegevoegd, e.g. block alles, allow sommige op specifieke devices.
Daarom vind ik het ook een slecht idee. Je kunt met doh geen advertenties meer blokkeren omdat je eigen dns server omzeild wordt 😢
Ik gebruik dan zelf pfblockerng op pfsense en die krijgt, als dit de standaard wordt geen requests meer om te verwerken. In pfsense heb ik dns over tls naar 1.1.1.1 en 1.0.0.1 ingesteld en daarmee ook beveiliging gerealiseerd. Ik hou je blocklist in de gaten.

Ik kan je pdf niet openen, waarom gebruik je niet de wiki mogelijkheid van Github?

[Reactie gewijzigd door Mozart op 23 juli 2024 09:32]

Bekend probleem, om een of andere duistere reden word users.telenet.be geblocked door een heleboel lijsten. effe whitelisten, problem opgelost.
Alle scripts en lijsten staan op GitHub, de docs (pdf) op de webserver (voor mij makkelijker qua updates).
DoH blijft zover ik weet altijd slechts een optie.

Met DoH zouden namelijk veel andere dingen de soep inlopen, bijvoorbeeld DNS voor het opzoeken van lokale diensten (o.a. intranetsites) binnen een groot bedrijfsnetwerk.

In theorie kunnen clients altijd buiten de DNS instellingen om DoH gebruiken. Maar dat valt niet te controleren, want ze kunnen hier prima een custom implementatie voor schrijven, een server maken die DNS requests afhandelt over HTTP/HTTPS/een geheel ander protocol is namelijk behoorlijk makkelijk.

Ik zie de baten van DoH blokkeren in een netwerk dus niet zo in, behalve als je websites wilt blokkeren voor gebruikers die deze websites willen bezoeken, bijvoorbeeld in een school- of werkomgeving met apparaten die je niet zelf beheert. En ook dan is het slechts een lompe oplossing, die makkelijk omzeilt kan worden.
Ik zie de baten van DoH blokkeren in een netwerk dus niet zo in...

Het doel is vooral om devices die stiekem DoH gebruiken te blocken. Een IOT komt waarschijnlijk met een hardcoded DoH server toe, kan zelf geen DoH service schrijven, en zal een well known DoH service proberen te gebruiken, die niet de ene dag wel, de volgende dag niet meer, beschikbaar is.

Devices die DoH proberen te gebruiken vallen binnen de korste keren door de mand, lees hier en hier, om maar twee recente voorbeelden aan te halen.

De oplossing, waar iedereen zit op te wachten, is SURICATA en / of SNORT. Een aantal, voor thuis gebruikers niet te betalen, devices kunnen het al tegenhouden, voor mij voorlopig dus maar een blocklist.

Maar, vrij land, geen DoH blocklist gebruiken, feel free...
Dit staat natuurlijk semi-los van DoH. Een willekeurige applicatie kan DNS/DoH/DoT/whatever praten op een willekeurige poort als hij dat wilt. Weinig mensen hebben hun uitgaande firewalls gesloten staan. (bedrijven willen dit nog wel doen middels proxyservers, om zo meer controle te krijgen)

Het feit dat bijvoorbeeld Firefox is geconfigureerd om DoH te praten (mits zo geconfigureerd) op poort 443 naar een voorgeconfigureerde server, betekend niet dat DoH een slecht idee is. Of DoH in je thuisnetwerk nodig is, is misschien te bediscussiëren. DoH kan Man in the Middle aanvallen moeilijker maken. Je kan er dus ook voor kiezen om een tool als AdGuard Home te gebruiken in je eigen netwerk. Die praat zowel aan de voorkant als de achterkant native DoH en DoT zo je wilt.

Je kan dan dus Firefox, Android, of welk ander systeem dat DoH praat dan gewoon met AdGuard Home laten praten, en dan heb je alsnog de voordelen van advertentieblokkades voor je netwerk.

Dit neemt natuurlijk niet weg, dat een willekeurige applicatie toch 'stiekem' DoH naar een ander adres kan praten. Als een applicatie zo is geprogrammeerd, is er een redelijke kans dat die dan ook niet 'netjes' op poort 443 gaat praten. Als je echt volledige controle op je netwerk richting het internet wil, zal je iets van een proxy-server moeten neerzetten, die dynamisch certificaten genereerd. Dan kan je per transactie kijken of het een DoH of een regulier https pakketje is.
Anoniem: 323326 @jpgview17 juli 2020 07:29
Wat bedoel je met:
verlies je alle controle over de verbindingen met externe partijen, die devices kunnen maken.
Als je pihole of adguard draait dan kan je toch nog steeds deze controle behouden?
Wanneer een device DoH (of DoT) gebruikt loopt het verkeer (de DNS requests) niet langer langs pihole, en hebben adlists en / of regexes die je in pihole hebt gedefineerd geen invloed meer op dat device.

Enige manier om dit op te lossen is een locale DoH server voor pihole te plaatsen, e.g.

client (DoH) -> local DoH server -> pihole -> unbound (of gelijk welke oplossing die je als final resolver wil gebruiken)

Helaas heb ik nog geen goede oplossing gevonden voor een locale DoH server, er zijn er wel een paar, maar:
- well maintained?
- stable?
- single binary, installed as a service (not a python or other script language)?
- additional load on system (pi Zero)?
Anoniem: 323326 @jpgview24 juli 2020 16:53
Ah zo, ik run een eigen DOH + DOT server. 2 opties heb je:
1. android weg > pihole
Veel meer eigen mogelijkheden en ik heb een gist met vrij veel commands om het pretty much in een keer klaar te krijgen: https://gist.github.com/b...0b7e8111d5f1b1a9d02d147c7

2. Apple weg > adguard
Via freek zijn ansible (die nog niet perfect is maar wel goed werkt) heb je alles 1 een zonder gedoe en genoeg opties om aan te passen via de gui > https://github.com/Freekers/ansible-adguard
"De controverse rondom de beslissing van Firefox richtte zich aanvankelijk vooral op het doorsturen van verkeer naar een partij waar de gebruiker tot dan toe geen relatie mee had (Cloudflare). Een beweging richting centralisatie naar één of slechts enkele partijen."
Oke maar als je dus gewoon DNS over https doet (maar dan gewoon zoals het nu al werkt) dan is er niets aan de hand toch? Dan ben je en beter beschermd en je kunt gewoon nog steeds elke DNS (die https biedt) gebruiken.

Als doh breedt wordt gedragen zijn die lijstjes ook niet meer nodig, net als nu vrijwel elke website bereikbaar is via https.

[Reactie gewijzigd door Drexz op 23 juli 2024 09:32]

Oke maar als je dus gewoon DNS over https doet (maar dan gewoon zoals het nu al werkt) dan is er niets aan de hand toch? Dan ben je en beter beschermd en je kunt gewoon nog steeds elke DNS (die https biedt) gebruiken.
Een groot probleem met doh lijkt te zijn dat vele partijen die software maken zelf gaan bepalen welke DNS er gebruikt gaat worden. In het artikel wordt Firefox aangehaald die zelfstandig de DNS instellingen van je OS negeert. Het lijkt er op dat andere partijen dat ook willen gaan doen. Allemaal in het kader van 'veiligheid' en 'privacy'. Maar ondertussen verlies je wel de controle over welke partijen jouw DNS queries te zien krijgen.

Nou gaan er ook geluiden op dat als je zelf een DNS server draait, je een speciaal record daar in op kunt nemen en dat doh clients die dan zullen respecteren. Maar het probleem blijft. Software kan (gaat?) de DNS instellingen van je OS negeren en dat is een fundamenteel probleem.

[Reactie gewijzigd door Blorgg op 23 juli 2024 09:32]

Chrome negeerde (of negeert nog steeds) je dns instellingen iig onder Android als je asynchrone requests aan had/hebt staan waardoor een pi-hole ook niet werkt dus FF is niet de enige hoor.
Weet niet of de reden bij Chrome dezelfde is, of gewoon om het door je digitale strot duwen van ads zeker moet stellen.
Maar dan kun je nog in je firewall externe DNS servers blokkeren. Voor de software blijft er dan niets anders over dan je OS DNS instellingen te accepteren.
Bij DoH zal dat niet meer mogelijk zijn.
Bij doh is dat zelfs de enige manier om te blokkeren: ip adres op poort 443 tegenhouden.
Het ging me er echter om dat software soms niet doet wat je verwacht of instelt.
Dat is opzich een goed punt, maar dat staat eigenlijk los van doh, dat zouden ze in theorie nu al kunnen doen met de huidige DNS oplossing.
Ja, dat kan nu ook, maar dat is nu ook heel simpel te blokkeren door verkeer op poort 53 naar buiten te beperken. Het probleem van DoH is dat dit zich voordoet als normaal https verkeer, en dus niet te beperken/blokkeren is zonder dat ander verkeer daar last van heeft.
Ja, je kunt de zone "use-application-dns.net" opnemen. Maar dat werkt vziw alleen voor Firefox en niet per definitie voor alles dat DNSoHTTP doet.
Maar wat gebeurt er dan als je een DNS gebruikt met een familie filter, zoals OpenDNS ? Kan een browser die dan negeren en alsnog allerlei content tonen die je niet wilt ?
Maar wat gebeurt er dan als je een DNS gebruikt met een familie filter, zoals OpenDNS ? Kan een browser die dan negeren en alsnog allerlei content tonen die je niet wilt ?
Dat is precies wat er gebeurd als software de DNS instellingen van je OS negeert.
In welke zin ben je dan beter beschermd? Het enige verschil netwerktechnisch gezien is dat dns verkeer niet meer zichtbaar is in een netwerkscan. Als voorbeeld. Bij een wifi verbinding kan niemand op dat zelfde netwerk meer zien waar je dns aanvragen naar toe gaan. Alle overige netwerk verbindingen komen gewoon langs.
Surf je naar tweakers.net, zie je de dns aanvraag voor tweakers.net niet meer. Maar vervolgens wel het verkeer naar een ip van tweakers.net.
Maar achter een IP-adres kunnen véél websites hangen. Denk maar aan Azure, Amazon, Cloudflare, ...
De opgevraagde domein is unencrypted in te zien. Er moet namelijk eerst een Host header gestuurd worden alvorens de webserver weet welk SSL certificaat gebruikt moet gaan worden.
Daarvoor hebben ze encrypted SNI uitgevonden. Geen idee in hoeverre dat al supported is overal, maar in ieder geval Cloudflare doet dat al een tijdje https://blog.cloudflare.com/encrypted-sni/.
Ja, dat is een extension op TLS 1.3. Dat wordt nog niet veel ondersteund.
Bovendien vereist dat een toevoeging in de DNS zone, wat het geheel best complex maakt.

En dan heeft het ook alleen zin wanneer DNS volledig encrypted is, dus gebruik van DNSoHTTP.

Kortom, ik zie dit nog geen storm lopen.

[Reactie gewijzigd door Tozz op 23 juli 2024 09:32]

Het enige verschil netwerktechnisch gezien is dat dns verkeer niet meer zichtbaar is in een netwerkscan.
Dat niet alleen; het is ook niet meer te manipuleren door kwaadwillenden. Neem bijvoorbeeld Google Public DNS (8.8.8.8). Dat is een resolver die DNSSEC-validatie doet. Het pad tussen een eindgebruiker en 8.8.8.8 kan behoorlijk lang zijn en is onbeschermd. Dus na DNSSEC-validatie, kan een kwaadwillende alsnog het DNS-antwoord manipuleren en een gebruiker naar een valse omgeving leiden.

DoH (en DoT) lost dit probleem van de 'onbeschermde last mile' op.
Werkt dit dan ook automatisch over TLS 1.3, of is dat aan de DNS provider om te configureren? Stel dat je als provider TLS 1.1 kiest, dan ben je minder veilig dan dat je denkt.

Wat ik me nou afvraag is: De titel is: tegen welke prijs, de prijs is dan dat er minder providers overblijven?
Er blijven enkele providers over, en ga er maar vanuit dat dit voor 3kwart van de internetgebruikers gewoon de dns servers van gogole gaat worden. Het hele probleem van DoH is dat al je verkeer, itt tradiotneel dns, over 1 server loopt, en dat gaat volledig richting de kant van grote partijen zoals Google
Vergeet niet dat 1.1.1.1 er ook nog is en die zal niet maarzo weg gaan.
Is dit niet de dns resolver van cloudflare?
TLS 1.1 staat al op de nominatie om afgevoerd te worden. (net als TLS 1.0)

TLS 1.2 is momenteel het minimum.
Omdat het netwerk onversleuteld is, is het voor derden mogelijk je verkeer uit te lezen, te blokkeren of te manipuleren. Doh lost dit probleem op
Kleine voetnoot, het beschermen tegen manipuleren is natuurlijk ook mogelijk met DNSSEC.
Kleine voetnoot, het beschermen tegen manipuleren is natuurlijk ook mogelijk met DNSSEC.
Alleen als je DNSSEC-validatie op de client doet. Als een lokale resolver de validatie doet (en wat is "lokaal", als die resolver 1.1.1.1, 8.8.8.8 of 9.9.9.9 is?) is het pad tussen resolver en client nog steeds onbeschermd en kwetsbaar.
Je kan ook een eigen resolver runnen voor de eigen apparaten.
Dan werkt DNSSEC wel, en is ook DoT/DoH een papieren kwestie.

Echter is de manier van "privacyverbeteren" dmv. DoH effectief een verslechtering.
tov. bv. een pi-hole.

[Reactie gewijzigd door tweaknico op 23 juli 2024 09:32]

DoH vanuit de browser kan, maar er is ook nog DNS over TLS DoT (vanuit de router). Als de ISP dit ondersteund (In Nederland o.a. XS4ALL) dan wordt het DNS verkeer tussen de router thuis en de DNS server bij de provider ook versleuteld. https://tools.ietf.org/html/rfc7858 De DNS server van de ISP blijft gewoon zijn werk doen en al het DNS verkeer (ook van de IOT devices ) is versleuteld op het publieke internet.

Groet,

AVM GmbH for ICT

Eric
Ik prefereer ook deze oplossing boven HTTP onnodig ergens bij te betrekken puur om (consumenten/mkb) firewalling te omzeilen. Duurdere firewalls kunnen toch het onderscheid tussen regulier en DOH op 443.

[Reactie gewijzigd door analog_ op 23 juli 2024 09:32]

Betekent dit dan ook dat het niet meer mogelijk is voor ISPs om domeinen te blokkeren?
Betekent dit dan ook dat het niet meer mogelijk is voor ISPs om domeinen te blokkeren?
Ja en nee. DNS-wise wordt blokkade lastiger ja. Maar de ISP kan nog steeds op IP-adres niveau blokkeren (wat bijvoorbeeld gebeurt met The Piratebay).
Bij wijze van test even geprobeerd om in Firefox mijn DNS over HTTPS via Cloudfare te laten lopen. Bij dnsleak.com is nog steeds alles rood, hij geeft Cloudfare aan én mijn provider. Is dat omdat ze wel kunnen zien dat ik naar Cloudfare verbinding maak maar dan vervolgens niet welke site ik opzoek?
De test verstuurd een request naar hun eigen server die uniek is voor jouw browser/sessie.
Ik snap de bedenkingen bij DoH en hoe dit soms misschien wat agressief wordt uitgerold. Maar het grootste probleem is misschien eerder het DNS systeem zelf. Na de snowdenonthullingen is er een grote stap gemaakt om alles te beveiligen met versleuteling behalve echt met het DNS systeem, DNS verkeer is bleef onversleuteld. Dat heeft misschien z'n redenen gehad die men als goed of slecht kan beoordelen, dat blijft een mening. Besturingssystemen bleven achter met de ondersteuning van versleuteld DNS verkeer, al verschilt dat nog per besturingssysteem. En ook de internetproviders zijn laks met het ondersteunen van versleuteld DNS verkeer, oa DoH of DNSoverTLS. Dus dat sommige partijen nu het heft in eigen handen hebben genomen is misschien net het zetje wat het nodig had, besturingssystemen ondersteunen of gaan het ondersteunen en sommige providers worden ook wakker. Het zal nog wel even duren, maar door het doorduwen van DoH komen er eindelijk de nodige veranderingen.
Het zou inderdaad wel expliciet aangegeven mogen worden van wie een advertorial komt, maar door het SIDN-logo boven het artikel en de vele verwijzingen naar SIDN lijkt me dat in dit geval niet heel moeilijk te gokken.

[Reactie gewijzigd door Onno op 23 juli 2024 09:32]

Het is dat je zegt dat er een logo van SIDN boven staat, ik had dat gemist, ik zag alleen linksboven "Door Tweakers Partners". Dat in combinatie met de inhoud lijkt het voor mij een gebalanceerd artikel. Voor mij is niet duidelijk wat hiervan het advertentie-gedeelte is, waardoor ik weer aan de gebalanceerdheid twijfel.
Er staat duidelijk advertorial, daarmee is toch gegeven dat ervoor is betaald? Ik vind dit een van de weinige recente advertorials waar ik iets van heb opgedaan (anders dan jeuk en bulten), omdat het verder strekt dan reclame alleen.
Dat staat er toch heel duidelijk?
Imho zou Tweakers in het vervolg bij ieder artikel moeten vermelden of het betaald is voor het artikel.

Dat is nu precies wat we doen. We zullen nooit laten betalen voor artikelen en er geen advertorial of andere duidelijke vermelding bij zetten. In die zin kun je er dus blind vanuit gaan dat advertorials zoals o.a. deze tot stand zijn gekomen in samenwerking met de partner en dat er voor betaald is. Om precies te zijn voor de productie en voor het bereik. Daar staat tegenover dat je er net zo blind vanuit kunt gaan dat voor alle andere content op Tweakers niet betaald is. Zo simpel is het en zal het ook blijven.
Dan had aangeven dat Sidn de auteur is. Nu staat er Tweakers partners wat in het midden laat of Tweakers hier aan meegeschreven heeft.
Tweakers schrijft hier aan mee, maar niet de redactie, die is namelijk volstrekt onafhankelijk. We hebben een aantal (freelance) schrijvers die commerciële content maken voor Tweakers, in opdracht van ons en namens de klant.
Correctie: Het is een contractie van Advertisement en Editorial.
Ik denk niet dat de editor (tweakers redactie) een woord gewijzigd heeft.

Op dit item kan niet meer gereageerd worden.