Dank je EFF, maar mijn DNS oplossing is al gedecentraliseerd. Dat XS4All kan zien welke domeinen en bijbehorende IP adressen ik allemaal bezoek, vind ik niet zo interessant. Verder als de infrastructuur van XS4All komen mijn DNS lookups niet.

Mijn gevoelens hierover zijn gemengd. We hebben in de nabije toekomst wederom een Amerikaanse DNS provider die alle handjes onder controle houdt. Zeer eng, want we weten allemaal dat de partijen mbv gag orders gewoon onder de invloed van de FBI staan en niets zal minder waar zijn dan dat. En aan de andere kant lijkt het een beetje op wonderolie omdat alles "veilig" zou moeten zijn. Mijn grootste bezwaar is dat DoH (volgens mij) alleen maar https bevat en niet zaken zoals ssh en bittorrent. Dat lijkt mij een filosofie die niet de protocollen van de OSI bevatten en dat lijkt mij een serieus bezwaar.

Xs4all vertrouw ik er wel mee, maar als die straks door de rechter gedwongen worden om weer extra zaken te censureren moet ik toch weer om ze heenwerken zoals nu met The Pirate Bay, die via Tor gelukkig nog goed bereikbaar is. Een (buitenlands) bedrijf dat Nederlandse opsporingsdiensten de middelvinger geeft als ze om gegevens vragen is dan natuurlijk ideaal.

Lijkt me geen goede zaak om maar van alles te verstoppen in https, omdat het dan encrypted is, en toch makkelijk.
Maakt de noodzaak om https te onderscheppen, om te kijken wat nu allemaal weer doorheen loopt, alleen maar groter.
Laat browsers, en vooral, Firefox, zich maar bezig houden met hoe geef ik zo weinig mogelijk prijs over welke browser en het gebruikte systeem je gebruikt, en toch een goede webpagina te laten zien.

In mijn optiek is het niet de browser die deze keuze moet maken, maar het os zelf. De browser behoort hier standaard af te blijven als een gebruiker niet expliciet een andere keuze maakt. Als een gebruiker andere privacy wil moet hij dat op systeemniveau regelen voor alle dns requests en niet alleen binnen een browser.

Leuk, maar het is m.i. geen oplossing voor het omschreven probleem. Het voorkomt niet dat een handvol bedrijven de dns-verzoeken van miljarden gebruikers zullen verwerken. Providers kunnen ook met DoH nog steeds zien welke domeinen een klant bezoekt. Het enige verschil is dat het DNS verzoek encrypted over de lijn gaat, wat sniffing lastiger maakt.
Dit is een goed voorbeeld van beleidsmakers die geen kennis van zaken hebben en de plank finaal mis slaan.

Dit is een beetje dom, net als dat "DoH" een beetje dom is. Want inderdaad, als iedereen aan de "DoH" gaat dan komen dus alle aanvragen bij de "DoH"-aanbieders terecht. Goh. Dus moet iedereen het maar ondersteunen, bijvoorbeeld je ISP. Maar wacht even, "DoH" beschermt dus wel tegen meekijkers onderweg maar niet tegen meekijkers op het "DoH"-eindpunt. En als jouw ISP dat "DoH"-eindpunt ter beschikking stelt beschermt "DoH" dus tegen meekijkers op het eigen ISP-netwerk. En dat kan de ISP ook wel anders oplossen, bijvoorbeeld met "ports security" op de switches. Minder werk, hetzelfde resultaat.

Dus waar denkt de EFF nou helemaal dat "DoH" bij ISPs goed voor is? Waar moet het tegen beschermen?

Wat mij betreft is "DoH" dan ook vooral een vehikel van webaapjes die denken "meer https is altijd beter", en laat dat nu net niet het geval zijn. Lijkt me dat de EFF hier beter zou moeten weten, in plaats van zich te verlagen tot goedkoop met alweer een webjostibandmuziekje meelopen.

Was dat EFF niet die organisatie die de eu copyright regelgeving wilde aanpassen? En dat komend van een land waar trademarks zijn op hypelinks and tot voor kort "happy birthday to you"

OT
En dat huidige meerdere dns verruilen voor, 1 cloudflare. Zijn ze daar dronken ofzo? Heeft er niet iemand 600k over om eens wat tegengewicht in de schaal te leggen????

Het gaat niet alleen om de vertrouwelijkheid, maar ook om de integriteit. Met name in Brazilië lijkt het criminelen vaak te lukken om (op afstand) de DNS-server-instellingen in modem/routers te wijzigen in hun eigen DNS-servers, waardoor gebruikers op phishingsites uitkomen waarna o.a. hun bankrekening kan worden geplunderd.

Meer info: Google DNS-changer router malware Brazil en/of zie https://www.zdnet.com/article/brazil-is-at-the-forefront-of-a-new-type-of-router-attack/.

Kwetsbare routers vind je echter in allen landen, en bij public WiFi moet je ook maar afwachten hoe betrouwbaar DNS is (als je een VPN gebruikt met een geconfigureerde domeinnaam i.p.v. IP-adres heb je die DNS minstens eenmaal nodig).

Overigens heb ik in https://www.security.nl/posting/623445/Firefox+gaat+DNS-over-HTTPS+in+Verenigde+Staten+inschakelen#posting624178 info toegevoegd over hoe intranetbeheerders het gebruik van Firefox-DoH kunnen blokkeren.

Met de change van Firefox dus niet meer. Dan zal het eerst naar Cloudflare gaan, behalve als je dat zelf uitzet.

En daar is "DoH" de oplossing voor? Lijkt nog steeds heel erg op "we snappen het niet want we zijn webaapjes dus gooien we er maar https tegenaan en alles wordt beter". Een soort eurocratische "wij als EU falen dus de oplossing is meer EU"-"oplossing" dus.

Ook mooi dat DNSsec dat integriteitsverhaal had moeten leveren maar dat lukt ook maar niet. Net als dat IPv6 al jaaaaaaren geleden de adresdepletie had moeten oplossen maar dat lukt ook maar heel erg mondjesmaat, nu het echt een onmiddelijk probleem aan het worden is. Met andere woorden, de "architecten van het internet" lukt het niet echt meer nog echte problemen op te lossen. Maar de problemen zijn langzamerhand wel zichtbaar. Dus klooien de prutsers maar wat aan met de halvegare "oplossingen" die ze nog net wel weten te bedenken. Wat een armoe.

Ik lees net in RFC 8484 dat er geen padding is in het huidige protocol. Dit betekent dat aan de lengte van een DoH verzoek, kan worden gezien hoeveel tekens het domein is wat opgezocht wordt.

Ook zie ik niet in de RFC hoe een DoH server verschilt van een gewone webserver, waar een Let's Encrypt certificaat voor kan worden aangevraagd. Als de DoH server eenmaal onder controle is van criminelen, kunnen ze elk IP adres teruggeven wat ze willen. Tenzij DNSSEC wordt gebruikt, maar dat wordt bij DoH op de server gecontroleerd in plaats van door de client zelf.

Ik heb steeds als ik mij verdiep in DoH het gevoel, wtf, welk probleem wordt hier opgelost? Ik kom er niet uit.

Krijgt CloudFlare nu niet te veel macht?
#sockpuppet

Okay jongens, OpenBSD zet DoH in Firefox standaard uit.

https://undeadly.org/cgi?action=article;sid=20190911113856

In het hoofdstukje "security considerations" noemen ze het niet toepassen van padding wel degelijk als zwakte, en ze verwijzen naar compression en padding in de RFC 7540 (HTTP/2) en naar de experimentele RFC 8467 (Padding Policies for Extension Mechanisms for DNS). Het is dus niet zo dat ze het over het hoofd hebben gezien.

Het is ook niet zo dat RFC 8484 het gebruik ervan blokkeert. Als de makers van een browser of DNS-software gemotiveerd zijn om DoH te ondersteunen dan levert die motivatie ook een reden op om HTTP/2, compression en padding toe te passen.

Er zijn ook redenen om het geen onderdeel van RFC 8484 te maken, lijkt me. Het is wel zo efficiënt om niet opnieuw het wiel uit te vinden maar te verwijzen naar andere RFC's waarin die aspecten van het probleem al worden aangepakt. Waarom maakt men HTTP/2 met padding dan niet verplicht? Vermoedelijk omdat versleuteling zonder padding nog altijd beter is dan geen versleuteling. En RFC 8467 is nog experimenteel, een proposed standaard kan onmogelijk een standaard worden als hij afhankelijk is van iets dat nog in zo'n pril stadium verkeert. En die experimentele RFC haalt men vermoedelijk niet even in, het vergt namelijk denkwerk en tijd om dingen degelijk uit te werken, zeker bij het goed toepassen van encryptie.

Ik snap niet wat je met die laatste opmerking bedoelt. DNSSEC en DoH zijn onafhankelijke technieken die verschillende problemen oplossen. Ik zie niet in wat DoH verandert aan DNSSEC, en ook niet waarom DoH problemen zou moeten oplossen die al door DNSSEC worden opgelost.

Ik heb het idee dat je verwarring voortkomt uit de verwachting dat DoH in een klap alles oplost. Het lost niet meer op dan het versleutelen van de inhoud van DNS-queries zodat ze niet af te luisteren zijn en zodat de browser weet dat hij echt de bedoelde DoH-server raadpleegt. Het is geen totaaloplossing maar een bouwsteen. DNSSEC is een andere bouwsteen, HTTP/2 is een bouwsteen die compression en padding ondersteunt, RFC 8467 is een bouwsteen die uitwerkt hoe je dat bij DNS-queries goed toepast.

Een degelijke implementatie voor domain name queries maken bestaat niet uit het toepassen van één allesomvattende bouwsteen maar uit het toepassen van een heel assortiment bouwstenen, net zo goed als een huis niet alleen uit zijn fundering of alleen zijn muren of alleen het dak bestaat, maar uit al die onderdelen (en meer). De verantwoordelijkheid voor een goede implementatie ligt bij de makers van de software, het is aan hun om alle bouwstenen die benodigd zijn voor een degelijk product toe te passen.

DNS hoort niet over poort 80 of 443 te gaan - dat moet versleuteld en verifieerbaar (gesigned) te gebeuren. Veilig dus - over eigen protocollen. DoH gaat meer problemen doen ontstaan - dan dat het gaat oplossen. Zowel Mozilla als Google zijn overenthousiast - de reactie van het EFF verraadt al dat het te laat is - en dat men enkel nog de schade kan beperken.
Wat ik 20 jaar geleden over rijke inhoud van mails heb gezegd - en over het kapen van het web om er vanalles mee te doen waarvoor het niet diende - dat is totnogtoe uitgekomen. Het heeft eigenlijk heel lang geduurd.
DoH wordt één grote security-nachtmerrie - en eigenlijk is er al een eerste malware uit die DoH misbruikt om z'n eigen dns-en te gebruiken. Bekamp zoiets maar 's. Mogelijks kom je er zelfs niet met DPI.
Het enige wat ons zou kunnen redden is dat de overheden DoH simpelweg en snel gaan verbieden.

Misschien mis ik nog het overzicht over RFC 8484, maar in hoofdstuk 9 staat:


Ik lees dit als de keuze voor DNSSEC voor end-to-end verificatie van domain lookups. Of (Xor) het gebruik van het AD bit met DoH.

Een standaard als DoH zou sowieso meer security moeten verplichten met MUST in plaats van het aan de browser (Chrome) en aan de DoH server over te laten of ze er samen uitkomen.

Ik lees erin dat ze broddelwerk geleverd hebben en dat achteraf ook maar in de RFC toegegeven hebben. Lang leve de eerlijkheid maar dat is geen substituut voor goed werken of nuttig onderdeel van een oplossing zijn.

Alleen werkt het niet als je daarmee een security ding bouwt dat op voorhand al lek is. Daar helpt geen "oh dat kunnen we later altijd nog toevoegen" tegen, dat is gewoon een hoop bullshit voor de show en niet iets dat problemen oplost. Hooguit oplevert.

Leuke stroman, maar net als de anoniem waar je op reageerde zie ik niet wat het wel oplost.

Je kan wel roepen dat het niet alles oplost maar vertel nu eerst eens of het ook maar iets oplost en wat dat dan is.

Dat is leuk, voorzover PKI-certificaten ook te vertrouwen zijn, maar is alleen maar zinnig als je het lokale netwerk niet vertrouwd. Dat maakt de oproep om "providers" DoH-servers ter beschikking te stellen vrij onzinnig. Want gaan ISPs voor externen dan DoH-servers beschikbaar stellen? Waarom zouden ze dat nou doen?

Dus wie zijn die providers dan? google, facebook, cloudflare, akamai, etc.? Wat?

En dan nog heb je als bijvoorbeeld met je smartphone roamende externe gebruiker geen ruk aan DoH, want je moet nu dus blind een derde partij vertrouwen dat'ie je niet zit voor te liegen. Want jouw device doet de DNSsec-verificatie niet meer, dat doet de DoH-server, die je op z'n mooie Let's-encrypt-certificaat mag geloven.

Ik zie vooral webaapjes die allerlei wielen hoekig en kantig heruitvinden en eigenlijk zelf ook niet weten hoe die nieuwelijk "verbeterde" wielen dan nuttig in moeten zetten. Het verhaal klopt gewoon niet.

En dit raakt kant nog wal. Je kan niet gewoon een blik bouwstenen opentrekken en vertellen "bouw maar iets, dan krijg je vast wel iets degelijks".

@Anoniem gisteren 17:16 en 19:21: ook ik heb grote twijfels of "DoH voor iedereen" op basis van opt-out een goed idee is (zie https://www.security.nl/posting/623445/Firefox+gaat+DNS-over-HTTPS+in+Verenigde+Staten+inschakelen#posting623463 en mijn aanvullende bijdragen in die thread), maar er zijn scenario's waarin DoH voordelen biedt.

Mijn grootste bezwaar tegen de Mozilla-aanpak van DoH is de concentratie bij 1 (of enkele) providers, wat dat betreft ben ik het helemaal eens met de EFF. M.b.t. padding: dat hoort op het niveau van TLS (of de toegepaste ciphers daaronder) geregeld te zijn.

Is er nog geen decentraal mesh netwerk based DNS server oplossing waar we onze Pi-hole naar toe kunnen laten verwijzen?

DNS is zelf gecentraliseerd (de root) ook al is het gedistribueerd (SOA RRs, etc.), dus daar maak je niet even wat anders van. En 'mesh' en 'decentraal' blijken toch altijd weer lastiger om echt goed te doen, dus wordt er maar weer gecentraliseerd. Kijk maar in de winkel naar wat er daar allemaal 'mesh' heet te zijn.

Blijft het protocol zo niet aangeleverd, compleet met vooraf door surveillance te gebruiken/misbruiken zwakheden al ingebouwd.

Om de een of andere reden wil men geen veiligheid voor alle eindgebruikers, alleen in naam. Je smartphone gaat maar drie jaar mee, ook om die reden All is holed on purpose.
luntrus

Als ik de reacties op tweakers.net eens lees is dat wel duidelijk: de cesurerende en meekijkende systeembeheerders bij bedrijven worden buitenspel gezet. En dat ligt bij tweakers.net natuurlijk slecht omdat die groep daar zwaar vertegenwoordigd is.

tweakers.net zit vooral vol met gamers die verder ook niet al teveel van de materie snappen; zolang hun ping maar laag is en de spelletjes het lekker doen vinden ze het wel best. Dan nog, de meeste systeembeheerders hebben wel wat beters te doen dan jouw email te lezen (gebruik eens wat kommas en punten, joh!) dus als ze "censureren en meekijken" dan is dat meestal omdat het management dat wil. Uitzonderingen daargelaten.

En ook als niet-meelezende systeembeheerder is het vrij vervelend om software op je (bedrijfs)netwerk te hebben die gewoon niet luistert naar wat je vertelt. "Gebruik deze DNS recursors, hebben we speciaal voor dit netwerk opgezet" 'haha nee ik pak wel die van google' is al vervelend genoeg. Dan ook nog eens extra-inefficient via DoH, dat is gewoon de middelvinger opsteken.

Je kan best beargumenteren dat het geen slecht idee is om je eigen DNS-instellingen te prefereren op een vijandig netwerk (*kuch* zekere telcos *kuch*, vooral Amerikaanse, maar alice/hansenet kon er ook wat van bijvoorbeeld, wellicht publieke wifi), is het dan weer niet zo handig dat heruitgevonden met een laag extra web-poep erom tot de goudstandaard te verheffen voor alles en iedereen in elke situatie.

Maargoed als jij toch wil beargumenteren dat DoH wel een goed idee zou zijn, waarom doe je dat dan niet?

Het is een standaard die specificeert hoe DNS-requests over HTTPS kunnen worden uitgevoerd. Waarom is het lek als het niet meer beschrijft dan hoe DNS-requests over HTTPS kunnen worden uitgevoerd?

Een stroman is het veranderen van een uitspraak van iemand in een andere uitspraak en vervolgens de uitspraak die je zelf hebt bedacht bestrijden. Lees eens waar de zin mee begint: "Ik heb het idee dat...". Daarmee legde ik de ander geen woorden in de mond maar schreef ik dat ik de indruk had daar het misverstand zat. Dat is geen stroman.

Ik heb trouwens de indruk dat jij net zo hard verwacht dat DoH veel meer oplost dan het doet. DoH is niet op voorhand lek omdat het niet alle lekken dicht, DoH is helemaal niet bedoeld om alle lekken te dichten. Wat een standaard doet is beschrijven hoe iets gedaan wordt. Zo'n document op zich dwingt niemand zich eraan te houden, het is geen natuurwet die onmogelijk te vermijden is. Het is een hulpmiddel waarmee softwaremakers makkelijker bereiken dat hun software met die van andere softwaremakers kan communiceren, omdat ze zich op hetzelfde doel richten in plaats van allemaal het wiel op hun eigen manier uit te vinden.

Hier vind ik je post behoorlijk bizar worden. Je citeert er direct achteraan wat ik verteld heb. Waarom vind je dat ik eerst maar iets moet vertellen wat ik al verteld heb?
Dat je er een negatief oordeel over hebt neemt niet weg dat ik aangegeven heb wat het oplost.
Mensen gaan niet alleen vanuit hun eigen huis het internet op. Er zijn allerlei situaties waarin je via het netwerk van een ander het internet opgaat en dat netwerk is mogelijk onbetrouwbaar. Versleuteling van DNS voegt daar net zo goed wat toe als versleuteling van de HTTP-requests naar websites die zo bezocht worden. Heb je werkelijk zoveel moeite om je scenario's voor te stellen waar versleuteling toegevoegde waarde kan hebben?

Het beeld dat jij kennelijk meent te lezen in wat ik schreef, "bouw maar iets, dan krijg je vast wel iets degelijks", dát raakt kant noch wal. Die standaards zijn geen uitgewerkte software, het zijn bouwstenen voor de specificatie van software. Als een leverancier zegt DNSSEC en DoH te ondersteunen dan gebruikt hij die RFC's als specificatie voor die implementatie. Het is niet "bouw maar iets", het is "bouw iets strikt volgens deze specificatie".

Ik vind het volkomen terecht dat een standaard zich beperkt tot datgene waar het een standaard voor is. Het is niet aan degenen die beschrijven hoe je een DNS-querie over HTTPS kan leiden om ook eisen dat DNSSEC wordt toegepast. Dat is niet waar zij zich op concentreren, en het is aan de makers van software en de gebruikers ervan om af te wegen wat wel en niet volstaat.

@17:37: Ik gok dat DNSSEC helemaal vergeten gaat worden zodra DoH default is bij alle browsers. En dat is jammer want ik zie het nut van het E2E PKI controleren van DNS requests wel.

Het nut van encryptie van DNS requests zie ik niet zo. Je kan immers niet de IP adressen in je TCP/IP fragmenten gaan verbergen. Dus het is bij een Open WiFi toch wel duidelijk waar je verbinding mee maakt. Dat is geen groot geheim (of je zou voor alles TOR moeten gaan gebruiken).