image

EFF roept providers op om DNS-over-HTTPS te ondersteunen

vrijdag 13 september 2019, 10:41 door Redactie, 26 reacties

De Amerikaanse burgerrechtenbeweging EFF heeft internetproviders wereldwijd opgeroepen om DNS-over-HTTPS te gaan ondersteunen. Dit moet voorkomen dat straks een handvol bedrijven de dns-verzoeken van miljarden gebruikers zullen verwerken en er een gecentraliseerd ecosysteem ontstaat.

Bij het opvragen van de locatie van een domeinnaam wordt een verzoek naar een dns-server gestuurd. In veel gevallen maken internetgebruikers gebruik van de dns-server van hun eigen internetprovider. Een probleem met dns-verzoeken is dat ze het ip-adres, of een groot deel hiervan, van de gebruiker bevatten, alsmede de opgevraagde domeinnaam. De verzoeken zijn daarnaast onversleuteld, zodat allerlei partijen die onderweg kunnen inzien of veranderen. DoH moet dit probleem verhelpen door een versleutelde verbinding voor dns-verzoeken te gebruiken.

Volgens de EFF kan DoH de privacy van internetgebruikers enorm verbeteren. Er is echter ook kritiek op de technologie. Zo is Mozilla van plan om voor de DoH-implementatie binnen Firefox de dns-servers van internetbedrijf Cloudflare te gebruiken. Zodoende zal straks het dns-verkeer van alle Firefoxgebruikers via één partij lopen. De EFF stelt dat de dns-aanbieders die browserontwikkelaars zoals Google en Mozilla voor hun browser kiezen deze partijen meer macht geven en het mogelijk voor deze partijen maken om gebruikers te monitoren en censureren.

Om te voorkomen dat er door DNS-over-HTTPS een sterk centraliserend effect ontstaat roept de EFF internetproviders daarom op om DoH zelf te gaan ondersteunen. Zodoende hebben gebruikers de security- en privacyvoordelen van de technologie, terwijl ze tegelijkertijd de keuze hebben om de dns-servers van hun eigen provider te blijven gebruiken. Verschillende providers, waaronder het Britse Faelix, zijn inmiddels begonnen om DoH te ondersteunen.

"DoH moet op zo'n manier worden uitgerold dat het de rechten van gebruikers respecteert. Browsers moeten transparant zijn over wie toegang tot de dns-data heeft en gebruikers de keuze geven om hun eigen dns-aanbieder te kiezen", aldus Max Hunter van de EFF, die toevoegt dat internetproviders DoH ook moeten gaan ondersteunen om zo een gedecentraliseerd ecosysteem in stand te houden.

Reacties (26)
13-09-2019, 10:51 door Anoniem
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.
13-09-2019, 11:29 door [Account Verwijderd]
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.
13-09-2019, 11:34 door johanw
Door Anoniem: 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.
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.
13-09-2019, 12:44 door Anoniem
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.
13-09-2019, 14:04 door Briolet
Browsers moeten transparant zijn over wie toegang tot de dns-data heeft en gebruikers de keuze geven om hun eigen dns-aanbieder te kiezen",

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.
13-09-2019, 14:18 door Anoniem
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.
13-09-2019, 14:23 door Anoniem
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.
13-09-2019, 14:45 door Anoniem
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????
13-09-2019, 15:42 door Erik van Straten - Bijgewerkt: 13-09-2019, 15:47
Door Anoniem :Het enige verschil is dat het DNS verzoek encrypted over de lijn gaat, wat sniffing lastiger maakt.
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.
13-09-2019, 16:02 door Anoniem
Door Anoniem: 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.

Met de change van Firefox dus niet meer. Dan zal het eerst naar Cloudflare gaan, behalve als je dat zelf uitzet.
13-09-2019, 17:16 door Anoniem
Door Erik van Straten:
Door Anoniem :Het enige verschil is dat het DNS verzoek encrypted over de lijn gaat, wat sniffing lastiger maakt.
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.
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.
13-09-2019, 19:21 door Anoniem
Door Erik van Straten:
Door Anoniem :Het enige verschil is dat het DNS verzoek encrypted over de lijn gaat, wat sniffing lastiger maakt.
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.

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.
13-09-2019, 20:25 door Anoniem
Krijgt CloudFlare nu niet te veel macht?
#sockpuppet
14-09-2019, 04:34 door [Account Verwijderd] - Bijgewerkt: 14-09-2019, 04:35
Okay jongens, OpenBSD zet DoH in Firefox standaard uit.

https://undeadly.org/cgi?action=article;sid=20190911113856
14-09-2019, 05:58 door Anoniem
Door Anoniem: 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.
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.

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 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 steeds als ik mij verdiep in DoH het gevoel, wtf, welk probleem wordt hier opgelost? Ik kom er niet uit.
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.
14-09-2019, 10:25 door Anoniem
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.
14-09-2019, 11:07 door Anoniem
Door Anoniem:
Door Anoniem: 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 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.

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

The HTTPS connection provides transport security for the interaction
between the DoH server and client, but it does not provide the
response integrity of DNS data provided by DNSSEC. DNSSEC and DoH
are independent and fully compatible protocols, each solving
different problems. The use of one does not diminish the need nor
the usefulness of the other. It is the choice of a client to either
perform full DNSSEC validation of answers or to trust the DoH server
to do DNSSEC validation and inspect the AD (Authentic Data) bit in
the returned message to determine whether an answer was authentic or
not. As noted in Section 4.2, different response media types will
provide more or less information from a DNS response, so this choice
may be affected by the response media type.

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.
14-09-2019, 12:07 door Anoniem
Door Anoniem:
Door Anoniem: 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.
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.
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.

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.
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.

Ik heb steeds als ik mij verdiep in DoH het gevoel, wtf, welk probleem wordt hier opgelost? Ik kom er niet uit.
Ik heb het idee dat je verwarring voortkomt uit de verwachting dat DoH in een klap alles oplost.
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.

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.
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.

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.
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.

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.
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".
14-09-2019, 13:17 door Erik van Straten
@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.
15-09-2019, 09:28 door Anoniem
Is er nog geen decentraal mesh netwerk based DNS server oplossing waar we onze Pi-hole naar toe kunnen laten verwijzen?
15-09-2019, 10:34 door Anoniem
Door Anoniem: 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.
15-09-2019, 12:44 door Anoniem
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
15-09-2019, 14:44 door johanw
Door Anoniem:Ik heb steeds als ik mij verdiep in DoH het gevoel, wtf, welk probleem wordt hier opgelost? Ik kom er niet uit.
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.
15-09-2019, 15:51 door Anoniem
Door johanw:
Door Anoniem:Ik heb steeds als ik mij verdiep in DoH het gevoel, wtf, welk probleem wordt hier opgelost? Ik kom er niet uit.
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?
15-09-2019, 17:37 door Anoniem
Door Anoniem: 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.
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?

Ik heb het idee dat je verwarring voortkomt uit de verwachting dat DoH in een klap alles oplost.
Leuke stroman, maar net als de anoniem waar je op reageerde zie ik niet wat het wel oplost.
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.

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.
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?
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.
Dat is leuk, voorzover PKI-certificaten ook te vertrouwen zijn, maar is alleen maar zinnig als je het lokale netwerk niet vertrouwd.
Dat je er een negatief oordeel over hebt neemt niet weg dat ik aangegeven heb wat het oplost.
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?
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?

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".
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.
16-09-2019, 08:41 door Anoniem
@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).
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.