Google zet dns-over-https aan in Chrome voor Android

Google stelt dns-over-https voortaan ook standaard in op Chrome voor Android. Vanaf versie 85 versleutelt de browser al het verkeer als de dns-provider dat ondersteunt. Ook wordt het mogelijk om zelf een alternatieve dns-provider te selecteren.

Google schrijft in een blogpost dat het zijn implementatie van dns-over-https standaard inschakelt op Chrome 85 voor Android. Google noemt die implementatie Secure DNS. Volgens het bedrijf werkt de mobiele versie ervan hetzelfde als op de desktop. Daar experimenteert het al mee sinds september vorig jaar. Sinds Chrome 83 staat dns-over-https standaard aan in de desktopversie.

Met Secure DNS worden dns-queries standaard versleuteld als de huidige dns-provider van de gebruiker dat ondersteunt. Als de provider het niet ondersteunt, wat op dit moment voor de meeste isp's nog geldt, worden de queries gewoon in plain text verzonden. Google heeft een lijst met dns-resolvers opgesteld waarbij de queries versleuteld worden. Op die manier worden eigen resolvers, zoals die van bedrijfsnetwerken, niet overruled.

Het wordt daarnaast mogelijk voor de gebruiker om handmatig een dns-resolver in te stellen via de instellingen in Chrome. Dat kan een custom resolver zijn, maar ook een provider, zoals Google zelf, Cloudflare of Quad9. In de instellingen is het ook mogelijk dns-over-https uit te zetten. De functie geldt alleen voor Android. Wanneer DoH op iOS uitkomt, is nog niet bekend.

Bij dns-over-https worden dns-queries standaard versleuteld. Dat is in theorie veiliger, maar experts zijn ook sceptisch, omdat private partijen zo meer informatie over gebruikers kunnen krijgen. Tweakers schreef vorig jaar een uitgebreid achtergrondartikel over de voors en tegens van DoH.

Reacties (75)

Dat is in theorie veiliger, maar experts zijn ook sceptisch, omdat private partijen zo meer informatie over gebruikers kunnen krijgen.

Is dit het verschil tussen een openbare request (die ook bij private bedrijven komen) en gesloten (waarbij de buitenwereld niets ziet?

En ik begreep dat hiermee software als Pi-Hole niet meer werken. Ze zijn in feite een middle man die niet bij de versleutelde data kunnen. Wat betekent dit voor trackers (en voor de liefhebber ads)?

Het staat er een beetje raar beschreven. Op dit moment zijn er slechts een handje vol DNS-servers die DoH ondersteunen. Door één van die DNS-servers te gebruiken, geef je dus effectief al je DNS-verzoeken aan één partij. Dit staat op zich los van DoH zelf. Het zegt alleen iets over de beschikbaarheid ervan.

Stel dat je ISP straks ook DoH gaat ondersteunen, dan valt dat argument weg. Uiteraard kan je er voor kiezen op je eigen Recursor te gebruiken (iets als bind of unbound), maar dan gaat sowieso alles onversleuteld het internet op. (los van hoe belangrijk je dat vindt).

Pi-hole (effectief dnsmasq) is geen DoH server. Als je dus pi-hole wilt blijven gebruiken, dan werkt dat dus niet met DoH. Programma's als AdGuard Home of dnscrypt-proxy2 zijn wel een DoH servers. (dit zijn ook dns-servers met een blocklist net als pi-hole)

Uiteraard kan je er voor kiezen op je eigen Recursor te gebruiken (iets als bind of unbound), maar dan gaat sowieso alles onversleuteld het internet op. (los van hoe belangrijk je dat vindt).

Maar unbound gebruikt toch Dot (dns over tls), dan is dit toch versleuteld? Of geldt dit dan alleen voor de verbinding en niet voor de data? Is dat het verschil?

Unbound kan DoT praten naar de achterkant, maar (zover ik weet) niet aan de voorkant. (Dus van je pc, naar de Unbound server. Meestal vindt men dat minder belangrijk)

Jouw PC praat onversleuteld naar Unbound, en Unbound kan versleuteld met bijvoorbeeld Google of Cloudflare praten. Als je Unbound echter gebruikt als recursor gebruikt (dus dat hij zelf de root name servers afgaat en heel de rambam), dan praat hij onversleuteld, omdat de standaard dns-protocollen vooralsnog onversleuteld zijn.


Verder:
Stel dat je een mechanisme als pi-hole gebruikt, dan heb je een paar keuzes:

- pi-hole zelf met onversleutelde upstream dns-server laten praten (omdat dnsmasq/pihole het niet zelf kan). Dit is het standaardgedrag zover bij mij bekend.
- pi-hole onversleuteld met een DoH proxy laten praten, zoals dnscrypt-proxy2 of cloudflared, die op z'n eigen beurt versleuteld met een upstream (DoT of DoH) dns-server praat.
- pi-hole met een recursor laten praten, die vervolgens onversleuteld met root name servers e.d. gaat praten. (dit zie je bij Tweakers veel gebeuren. Je bent dan niet afhankelijk van één DNS-provider, die dan al jouw DNS-verzoeken voorbij ziet komen, maar het is dan allemaal niet versleuteld)

Unbound kan zowel optie 2 als 3 zijn, maar niet beide tegelijk.
Echter. Als je toch al een mechanisme als unbound gebruikt, heb je eigenlijk de rest van pi-hole niet meer nodig, omdat unbound ook met dns-blokkeerlijsten kan werken. (alleen mis je dan een GUI, en moet je mogelijk zelf wat in elkaar smurfen om de blokkeerlijsten bij te werken, maar waarschijnlijk zijn daar wel scriptjes voor gemaakt door mensen)

Stel dat je geen recursor wil gebruiken, maar wel DoH/DoT, dan kan je ook bijvoorbeeld AdGuard Home gebruiken in plaats van pi-hole. Dit is net zoiets als pi-hole, maar dan in één binary. (dus geen aparte webserver/dnsserver installatie met een zooi php-packages, enz. enz. enz.) AdGuard Home praat zelf zowel aan de voorkant als aan de achterkant DoH en/of DoT en is z'n eigen webserver die ook nog is https kan praten out of the box.

Stel dat je ISP straks ook DoH gaat ondersteunen, dan valt dat argument weg. Uiteraard kan je er voor kiezen op je eigen Recursor te gebruiken (iets als bind of unbound), maar dan gaat sowieso alles onversleuteld het internet op. (los van hoe belangrijk je dat vindt).

Hier thuis gaat inderdaad alles via unbound onversleuteld het internet op. Ik vind het veel belangrijker om van zo weinig mogelijk centrale diensten gebruik te maken, zeker als het om basic infrastructuur als DNS gaat. Al je DNS-verzoeken bij een commerciele partij leggen zie ik helaas vaker gebeuren, ook onder tweakers, en ik vraag mij af of mensen zich wel bewust zijn van de implicaties. Hetzelfde geldt overigens voor het gebruik van een commerciele VPN-dienst. Je legt opeens een heleboel gegevens in handen van een partij waar je verder geen enkele relatie mee hebt i.t.t. bijv je eigen ISP.

Het is en blijft een afweging. Idealiter zou er inderdaad een mechanisme zijn dat zowel decentraal als versleuteld is.

ik vraag mij af of mensen zich wel bewust zijn van de implicaties.

Welke (voorbeelden van) implicaties doel je hier precies op?

In je thuis situatie gaan al je dns request naar je provider. Als je DoH aanzet gaat al je verkeer naar 1 (nu nog commerciële) partij. In de praktijk ziet die commerciële partij welke dns naam je opvraagt. Daarna ziet je internet provider jou verbinden naar een IP adres (wat vaak bij een specifieke DNS naam hoort)

DoH is dus niet perse voordelig m.b.t. privacy

Natuurlijk is de situatie heel anders voor mobiele gebruikers die nooit thuis zijn en continue verbinden naar publieke wifi hotspots

Nee, doh zoals google het toevoegt werkt alleen maar met hun eigen whitelist aan dns servers, toevallig ook die van henzelf.

In plaats van enkele providers met dns servers per land, die geen interesse hebben in je dns-records, krijgt google/cloudflare etc nu de alle requests van mensen met deze feature aan (bijna alle chrome gebruikers dus). Dan zijn de requests niet meer te onderscheppen, maar tegelijkertijd komen alle aanvragen en dus data bij google.

Het is vooral schijnveiligheid, en een mooie databron voor Google.

Snap dat ze het aan zetten, dan omzeilen ze Pi Hole achtige oplossingen en kunnen ze nog meer van je data graaien...
Tijd voor een http(s) proxy in huis bij Android gebruikers

Nee, want ze blijven je huidige dns-instellingen gebruiken en als die ingestelde dns-server DoH ondersteund, dan wordt dat gebruikt, en anders blijft het onversleuteld. Stel dat je dus AdGuard Home zou gebruiken ipv pi-hole (wat ook een dns-server met blocklist is), dan kan je wel DoH gebruiken en nog steeds advertenties blokkeren.

Wat een onzin. Google zet dit aan omdat Amerikaanse internetproviders DNS-verkeer onderscheppen en redirecten. Als je op je telefoon 1.1.1.1 instelt, sturen sommige ISPs bijvoorbeeld het verzoek door naar hun eigen servers.

Zoals het artikel zelf aangeeft, respecteert Chrome je DNS-instellingen. Als je pihole geen DoH doet, verandert er niets. Als je pihole wel DoH doet, heb je nu het bijkomende voordeel dat je verzoeken versleuteld worden.

Google doet genoeg rare shit met onze gegevens, maar laten we geen FUD verspreiden over dit soort maatregelen.

Een HTTPS-proxy gaat trouwens niet werken, de meeste grote apps hebben onderhand certificate pinning waardoor een man-in-the-middle-aanval uitvoeren met je eigen certificaatautoriteit niet meer kan. Dit heeft tot problemen geleid in landen waar ze zoiets nationaal hebben geprobeerd af te dwingen, zoals in Kazachstan. Wil je dit voor elkaar krijgen, moet je de certificate pinning handmatig uit je apps patchen met iets als Xposed of Magisk. Het kan, maar het is omslachtig en maakt je apparaat minder veilig.

Je geeft niet aan wat bedrijven als Google zelf voor voordeel bij deze verandering hebben. Data graaien gaat allang niet meer om direct bij je gegevens kunnen maar er ook indirect voordeel bij hebben. Hoewel ik niet lees hoe Google of andere bedrijven hier voordeel bij hebben valt het helaas wel te verwachten dat de bedrijven die dns over https aanbieden dat niet puur uit liefdadigheid doen. Het kost immers heel veel geld om dit soort diensten aan te bieden. Er zal hoe dan ook dus waarschijnlijk een verdienmodel in zitten dat te maken heeft met al het extra dns verkeer dat ze ontvangen. Dat doet er niets aan af dat het in andere opzichten wel veiliger is.

Het voordeel is dat ze kunnen claimen dat hun browser veiliger is. Google wil de beste browser bouwen, anders verliezen ze weer grondgebied tegenover Edge of Safari. Ook willen ze de ISPs die dit soort onzin uitvoeren een lesje leren. Mozilla heeft eerder in Amerika DoH al aangezet, met Cloudflare als standaardserver. Ik ben het daar zelf mee oneens, maar de bescherming die je daaruit haalt heeft Google momenteel simpelweg niet. Vergeet ook niet dat in tegenstelling tot Nederlandse domeinen dingen als DNSSEC in kinderschoenen staan in Amerika.

Als je naar directe in plaats van indirecte winst wilt kijken, kun je het zien als een poging te voorkomen dat internetproviders concurrentie gaan bieden op de informatiemarkt. Providers verkopen onder andere browsegegevens en locatiegegevens aan advertentieboeren, wat naast een enorme inbreuk op je recht op privacy ook een geduchte concurrent vormt voor Google's advertentiediensten. Adverteerders willen al langer direct de informatie van Google hebben voor hun eigen gewin, en dat gaat bij providers wel. De keuze is aan jou, maar ik vertrouw Google meer dan dat ik Time Warner of AT&T vertrouw. In tegenstelling tot Amerikaanse providers, verkoopt Google bijvoorbeeld geen locatiegegevens aan bounty hunters.

Nogmaals, deze wijziging van Google (en in de toekomst ook Microsoft) voegt geen enkele afhankelijkheid van Google's servers toe, in tegenstelling tot het ontwerp dat Mozilla samen met Cloudflare gemaakt heeft. Google's servers worden niet de default zoals Mozilla dat met Cloudflare gedaan heeft. De browser zorgt puur dat encryptie van DNS-verzoeken gedaan wordt als je provider dat ondersteunt, of dat nu de DNS van Ziggo is of die van je lokale Pihole. Je kunt de DoH-server van Google gebruiken, maar dan zul je echt eerst de DNS op je telefoon naar 8.8.8.8 moeten zetten.

Laten we het dan even on topic houden bij de opmerking over data graaien. Je herhaalt dat Google er geen direct voordeel uit kan halen, maar je gaat niet in op het indirecte data graaien en de mogelijke voordelen voor Google of andere bedrijven. En dat is precies waar het verschil in kan zitten om iets te kunnen claimen over afhankelijkheid of gebruik van waardevolle dns gegevens van gebruikers. Het is nogal makkelijk om iets te beweren door er niet op in te gaan, zoals Google, de DoH dienstverleners en dit soort reacties blijven doen.

Welke data wordt er hier gegraaid? DNS gaat nu naar dns.ziggo.nl over poort 443 in plaats van poort 53, wat is het probleem daarmee?

Je noemt een zeer beperkt voorbeeld in een discussie over dns over https. Het probleem is niet een antwoord op zulke vragen kunnen geven maar hoe dns over https het datagraaien werkelijk zou stoppen door het standaard te maken.

Feit: diverse Amerikaanse internetproviders vangen DNS-verzoeken op, sturen die naar hun eigen DNS-servers en verkopen die informatie.
Feit: versleuteling van DNS-verkeer voorkomt dat je verkeer kan omsturen.

Het inschakelen van DoH zorgt dus wel degelijk voor het verminderen van datagraaien in het geval dat je ISP niet te vertrouwen is en je een andere DNS-server hebt ingesteld.

Voor dit geval is nu een oplossing uitgerold. Mensen die buiten deze categorie vallen, ondervinden geen nadeel. Ik zie eigenlijk alleen maar voordelen in deze opstelling, kun je een nadeel noemen?

Ik verkies zelf overigens DNS over TLS boven DNS over HTTPS, maar het graag erom dat het verkeer versleuteld en geverifieerd wordt.

Je feiten geven nog steeds niet aan hoe het standaard aanzetten voorkomt dat bedrijven als Google en DoH aanbieders naar data graaien en niet minder maar meer kunnen verdienen aan die data. Dat het op bepaalde manieren niet meer mogelijk zal zijn zorgt er nog niet voor dat er geen datagraaien meer is. In plaats van steeds met reacties te komen die om het probleem heen draaien, kom eens met een reactie waaruit blijkt dat Google en de DoH aanbieders niet direct of indirect naar de dns gegevens graaien om er financieel beter van te worden.

kom eens met een reactie waaruit blijkt dat Google en de DoH aanbieders niet direct of indirect naar de dns gegevens graaien om er financieel beter van te worden

Kom eens met een reactie waaruit blijkt dat dit wel het geval is? Ik kan lastig bewijzen dat iets niet zo is, net als dat ik niet kan bewijzen dat er geen theepot in een baan om de zon draait.

Ik geef je een lijst van redenen dat het voor Google voordelig is om dit te implementeren buiten het datagraaien om. Jij geeft aan dat "het helaas wel te verwachten [valt] dat de bedrijven die dns over https aanbieden dat niet puur uit liefdadigheid doen. Het kost immers heel veel geld om dit soort diensten aan te bieden", ik geef aan dat er andere redenen zijn om de standaard in te bouwen en dat het Google geen cent kost om deze feature te bouwen omdat ze zelf de DoH-infrastructuur voor deze feature niet hosten.

Kun je misschien een concreet voorbeeld geven van hoe Google financieel profiteert als het DNS-verkeer tussen jou en Ziggo versleuteld is? Kun je je onderbuikgevoel dat Google hier geld mee wil verdienen onderbouwen?

Je doet een poging om het probleem om te draaien en draait er weer omheen. Het probleem wat er is is dat datagraaien mogelijk is en ongewenst is. Niet dat de gebruiker eerst maar moet bewijzen dat er datagraaien zou zijn. Het is niet redelijk om DoH als oplossing te promoten tegen datagraaien en dat de gebruikers dan maar moeten geloven of vertrouwen dat dit wel een oplossing tegen datagraaien is tot ze het bewijzen.

Je doet een poging om het probleem om te draaien en draait er weer omheen.

Wat is het probleem dan? Ik zeg: het probleem is dat er data wordt gegraaid.

Het probleem wat er is is dat datagraaien mogelijk is en ongewenst is.

Correct.

Het is niet redelijk om DoH als oplossing te promoten tegen datagraaien en dat de gebruikers dan maar moeten geloven of vertrouwen dat dit wel een oplossing tegen datagraaien is tot ze het bewijzen.

Partijen die theoretisch je DNS-verzoeken kunnen lezen met DNS (en deze kunnen aanpassen of doorsturen) als je een verzoek doet voor tweakers.net met KPN internet (DNS 195.121.1.34): Jij, je router, je lokale POP of ATM, 6 routers/switches van KPN (gemeten met een traceroute), de KPN DNS-server, de overheid (internettap), de .NET TLD root DNS server, de tweakers DNS-server.
Partijen die theoretisch je DNS-verzoeken kunnen lezen met DoH: Jij, de KPN DNS-server, de .NET TLD root DNS server, de tweakers DNS-server.

Ik tel 9 aftappunten minder, aannemende dat de overheid passief opneemt; als deze actief data uit de logs van KPN haalt zijn het er acht.

Er zijn dus 9 plekken op het netwerk minder waar er naar data gegraaid kan worden. Is dat voldoende bewijs dat er minder datagraaien is?

Je DNS-server zal natuurlijk altijd je data krijgen, dat is onvoorkomelijk. DoH is dan ook geen oplossing voor datagraaien, het is een mitigatie om het datagraaien te verminderen.

[Reactie gewijzigd door GertMenkel op 3 september 2020 14:39]

Nog een laatste poging, dan houd ik ermee op.

Dit soort discussies heeft geen zin als je steeds maar blijft draaien met het kennelijke doel geen antwoord te geven op de vraag hoe het een oplossing tegen datagraaien is.

Het is een oplossing tegen datagraaien omdat het het aantal mogelijkheden tot datagraaien significant vermindert.

De discussie is niet hoe DoH datagraaien kan verminderen maar hoe het werkelijk datagraaien stopt.

Niemand beweert dat het alle vormen van datagraaien stopt, en dat is ook een onzinnige eis voor een DNS-protocol. Je kunt niet voorkomen dat een willekeurige server die je om informatie vraagt gegevens over je verzoek bijhoudt, analyseert en verkoopt.

Nergens is aantoonbaar dat het werkelijk minder is.

Nee, omdat de functie dus net vrijgegeven is. Hoe kun je bewijzen dat iets verandering heeft veroorzaakt als het nog niet bestaat?

ISPs in Amerika hebben protest tegen deze stap van Google aangetekend met een verkeerde bewering ("Google gaat DNS centraliseren") waarvan al bekend was dat het niet zou gebeuren (welke Google later aan het Amerikaanse Congres heeft moeten bewijzen en zelfs Google durft geen meineed te plegen) en omdat het "data competition issues" zou opleveren. Dat laatste is natuurlijk het sleutelwoord hier.

Die providers hadden echt niet geklaagd als dit geen bedreiging voor hun datagraaibusiness zou zijn geweest; het plan van Google geeft ze juist exclusief datagraairecht (itt tot dat van Mozilla). Advocaten kosten veel geld, helemaal als ze naar Congress moeten met een heel verhaal.

Feit: diverse Amerikaanse internetproviders vangen DNS-verzoeken op, sturen die naar hun eigen DNS-servers en verkopen die informatie.

Klopt, en het is nogal naïef om te denken dat dat Google niet een doorn in het oog is; die willen die informatie liever zelf. DNS-over-HTTPS geeft hun daarmee dus wel degelijk een fantastische tool om nog meer data te graaien, en ik zie een reële kans dat het over een paar jaar opeens verplicht wordt om DNS-over-HTTPS te gebruiken, of in ieder geval dat het erg lastig gemaakt wordt om het uit te zetten.

Google die iets aan de man brengt als 'privacy-bevorderend', is zoiets als Shell die claimt dat zijn benzine goed is voor het millieu.

Wat een onzin.

Nou ja...

Het is wel weer een extra stap en extra moeite die je als eindgebruiker moet doen om je pihole te laten werken.
Als ik de handleiding voor DoH op de pihole zie, is dat ook geen one click wonder.

Dat zal Google vast niet ongelegen komen.

Als je pihole geen DoH doet, zet Chrome DoH niet aan. Alleen als je DNS-server DoH doet, gaat DoH aan.

Als je op je pihole geen DoH aanzet, verandert er dus helemaal niks voor je setup.

Als je pihole geen DoH doet, zet Chrome DoH niet aan. Alleen als je DNS-server DoH doet, gaat DoH aan.

Als je op je pihole geen DoH aanzet, verandert er dus helemaal niks voor je setup.

Nog niet. Kwestie van tijd voordat Chrome gaat zeuren:

"U gebruikt geen Secure DNS provider. Wilt u veilig blijven browsen, schakel Secure DNS in. JA/NEE"

En een tijdje daarna kun je het niet meer uitschakelen en gebruikt Chrome altijd 8.8.8.8 en 8.8.4.4 als DoH resolvers en werkt je PiHole niet meer; kun je niet meer overstappen naar OpenDNS of eender welke DNS provider, enz.

< bewaarpost>

Als ze dat van plan waren met DoH, heeft Google meineed gepleegd tegen het Amerikaanse congres toen dat informeerde naar aanleiding van een protestbrief die Amerikaanse providers hebben ingestuurd uit angst voor centralisatie en "data competition".

Ik betwijfel het ten zeerste. Als dit zo is, kun je er toch niks tegen doen behalve geen Chrome gebruiken. Protesteer dan, wanneer het gevaarlijk wordt, in plaats van nu, want nu is er nog geen reden om te protesteren. Google doet het juist beter dan Mozilla, nota bene!

Die handleiding gaat over het laten resolven van adressen door de PiHole via een externe DoH provider, niet over het gebruiken van een PiHole als een DoH server in je eigen netwerk.

DoH is een voor Google cs. fantastische manier om een PiHole te omzeilen en dat is zonder enige twijfel een zeer belangrijke motivatie voor Google om het te implementeren.

Voor nu is het beste wat je kunt doen: Alle DNS servers die DoH ondersteunen te blokkeren in je firewall voor poort 443 uitgaand, zodat je browsers weer gewoon DNS gaan gebruiken en je PiHole blijft werken.

Tip, gebruik DNS66 op Android, maakt gebruik van de VPN API en nullroutet verkeer naar bepaalde IP's in plaats van op het DNS-niveau te werken. Staat volgens mij alleen in F-Droid want google vindt dat logischerwijs niet leuk.

Edit: oeps, werkt toch wel op DNS-niveau. Ik ben in de war met iets anders waarvan de naam mij ontschuet...

[Reactie gewijzigd door fl1mpie op 3 september 2020 11:08]

Hoe gaat dit werken met partijen als Pi-Hole? Want ik maak daar behoorlijk gebruik van (hele thuisnetwerk gaat via Pi-Hole qua DNS, en mijn telefoons via 4G -> VPN -> thuisnetwerk -> Pi-Hole en terug).

daar is in voorzien door het aanmaken van een zg canary domain. als je dat record opneemt in je dns server zal elk programma dat gebruik wil maken van DoH terugvallen op een "normale" DNS query.
in DNSMasq bv moet je dan in de config opnemen:

# canary-domain
server=/use-application-dns.net/

zie bv https://support.mozilla.o...ks-disable-dns-over-https voor meer info.

Google heeft dit (helaas) niet geïmplementeerd in hun oplossing:

Do you plan to support a canary domain similar to Mozilla's use-application-dns.net?
We have no plans to support this approach. We believe that our deployment model is significantly different from Mozilla's, and as a result canary domains won't be needed.

Je hebt dus met Chrome op Android als DNS-beheerder geen manier om het gedrag van de van Chrome aan te passen. De gebruiker kan dus ten alle tijden zelf een DoH DNS-server instellen.

Denk dat oplossingen als Pi Hole juist een drijfveer zijn om dit aan te zetten
Google wil 1 ding: JE DATA!
En als je dat niet wilt, moet je hun spullen niet gebruiken...

Volgens mij begrijp je het niet helemaal.

Bij DNS over HTTPS wordt je DNS request naar de DNS provider automatisch versleuteld. Biedt je DNS provider geen HTTPS over DNS aan, dan gaat je verzoek onversleuteld. Standaard pakt je browser dus altijd de provider die er gebruikt wordt, de Google DNS is op dit moment niet eens in beeld. Pas als je de Google DNS handmatig instelt, zal dit veranderen.

En onder het mom: DOH is veiliger zetten hele volksstammen dat natuurlijk aan en vaak naar de google DNS servers. Het is immers google die met deze geweldig nieuwe veilige feature komt.
Met als gevolg: extra data voor google.

Voor zover ik heb kunnen opmaken uit het artikel, staat DNS over HTTPS straks automatisch aan zonder tussenkomst van de gebruiker. In geen geval wordt daarbij automatisch verwezen naar de DNS servers van Google, TENZIJ de gebruiker dat zelf in een eerder stadium heeft ingesteld. Maar geloof me dat veruit het merendeel van de gebruikers die functie niet zelf weet te vinden in Chrome. En als ze de functie wel weten te vinden, dan zegt de term 'nameserver' ze nog niets en blijven ze er het liefst vanaf.

Dus hele volksstammen die het activeren? Nee, ik zie het niet gebeuren.

Denk dat oplossingen als Pi Hole juist een drijfveer zijn om dit aan te zetten

Onzin

Google wil 1 ding: JE DATA!

Nee geld, en daarvoor willen/gebruiken ze data maar willen ze gebruikers ook niet tegen zichzelf in het harnas jagen, dus nee er is wel degelijk een balans in wat ze zelf denken te kunnen doen zonder mensen van zich af te stoten...

En als je dat niet wilt, moet je hun spullen niet gebruiken...

Dat geldt voor alles

Nee geld, en daarvoor willen/gebruiken ze data maar willen ze gebruikers ook niet tegen zichzelf in het harnas jagen, dus nee er is wel degelijk een balans in wat ze zelf denken te kunnen doen zonder mensen van zich af te stoten...

Het klopt, maar volgens mij is het praktisch gezien nauwelijks een rem. Als mensen niet weten wat er gebeurt of er toch niet onderuit kunnen dan kan er ook geen sprake zijn van een balans.

Daarom vind ik het zo belangrijk dat er transparantie is en dat er keuze is.
Transparantie zodat mensen weten wat er met hun dat gebeurt en wat voor gevolgen dat kan hebben. Dat is lastig want volgens mij is er niemand op deze wereld die dat echt overziet (zowel in postieve als in negatieve zin), maar meer transparant dan het nu is hoeft niet zo moeilijk te zijn.
Keuze zodat mensen een alternatief hebben. Je kan wel weten dat er lood in je drinkwater zit, maar als je niks anders hebt dan zul je het toch drinken.

Dat alles om te zeggen dat ik niet zo veel vertrouwen heb in die balans. Mensen weten niet wat er met hun data gebeurt. Als je informatie krijgt is die vaag en abstract in de vorm van "alles kan met onze 'partners' gedeeld worden voor 'doelen' ".
En echte realistische alternatieven zijn er niet. Er zijn wel andere appstores, maar de meeste applicaties zitten daar gewoon niet in en normale mensen kunnen daar niks aan veranderen.

Ben het zeker eens dat dingen duidelijker kunnen en dus zichzelf beter balanceren (dat leg je mooi uit). Maar er werd gedaan of het ongeremt allemaal maar kan maar dat is natuurlijk gewoon klinkklare onzin.

Van mij mag de EU de AVG ook breder trekken naar alle persoonlijke gegevens (dus niet alleen persoonsgegevens). Het is natuurlijk aan de overheden om die grensgevallen of achtergrondprocessen die jij en ik niet (perse) zien te controleren en daar voor ons in klaar te staan!

Maar er werd gedaan of het ongeremt allemaal maar kan maar dat is natuurlijk gewoon klinkklare onzin.

Welke remmen zijn er? Niet de GDPR, als je gebruik maakt van de software van Google stem je er mee in dat je ze toestemming geeft om je data te verwerken. Ze hebben honderden pagina's aan tekst nodig om uit te leggen wat ze allemaal met je data doen. Ik kan met niet voorstellen dat er daarna nog veel beperkingen over zijn.

Overigens is het onder de GDPR momenteel niet eens toegestaan om data over te dragen aan bedrijven in de VS. Sinds Privacy Shield onderuit is gehaald is er gewoon geen wettelijk toegestane manier om dat te doen. Er zou enorme paniek moeten zijn omdat alle bedrijven opeens hun data weg moeten halen bij Google, Amazon, Microsoft, Apple en al die ander bedrijven*.
Daar merk ik eigenlijk niks van. Dat zegt mij genoeg over hoe streng de regels worden nageleefd.

* er wordt wat gemauwd over SCC's waaronder het wel zou zijn toegestaan. Dat is niet er wat in het vonnis staat. De rechter waarschuwt juist dat die SCC's waarschijnlijk ook niet door de beugel kunnen. Bedrijven grijpen het aan door te zeggen dat de rechter die SCC's niet heeft verboden en dat ze dus zijn toegestaan.

Dat zegt mij genoeg over hoe streng de regels worden nageleefd

Nee, dat zegt dat er bij de AP mensen zitten die hun hersenen gebruiken.

Op het moment dat privacy shield onderuit word gehaald kunnen bedrijven onmogelijk de volgende minuut een oplossing daarvoor hebben.
Het zou volstrekt belachelijk zijn om dan ineens bedrijven te gaan beboeten. Er word door privacy officers wel degelijk nu heel hard nagedacht over mogelijke oplossingen. Maar die hebben uiteraard tijd nodig. Ieder wel denkend mens kan dat begrijpen.

Nee, dat zegt dat er bij de AP mensen zitten die hun hersenen gebruiken.

Dat is ook waar.
Maar ik had het eigenlijk over de bedrijven die de regels moeten uitvoeren, niet over de AP die de regels moet controleren.

Op het moment dat privacy shield onderuit word gehaald kunnen bedrijven onmogelijk de volgende minuut een oplossing daarvoor hebben.

Die bedrijven doen nu alsof er opeens een grote ontdekking is gedaan waardoor het opeens allemaal anders moet. Dat klopt niet. Iedereen wist al jaren dat die verdragen nogal dubieus waren. Als ze echt om hub klanten gaven (wat ik niet verwacht van een commercieel bedrijf) dan hadden ze zelf al eerder maatregelen getroffen in plaats van te wachten tot je gedwongen wordt door de wet.
Ik spreek met opzet over de vage "ze", daarmee bedoel ik alle bedrijven samen. Natuurlijk zijn er uitzonderingen die het anders (proberen te) doen, maar die zijn ook beperkt door wat de markt biedt. Zolang de bulk niet op zoek gaat naar andere oplossingen zal het voor de meeste kleine partijen niet mogelijk zijn om een ander pad te volgen omdat dit te duur is bij gebrek aan schaalvoordeel.

Het zou volstrekt belachelijk zijn om dan ineens bedrijven te gaan beboeten.

Er word door privacy officers wel degelijk nu heel hard nagedacht over mogelijke oplossingen. Maar die hebben uiteraard tijd nodig. Ieder wel denkend mens kan dat begrijpen.
[/quote]

Die privacy officers hadden jaren geleden al in actie moeten komen en op z'n minst moeten nadenken over een plan-B. Het lijkt nogal alsof ze daar nu pas mee beginnen. Ik snap dat veel van die mensen er wel eerder over nagedacht hebben maar in een organisatie zitten waar er geen ruimte voor is. Je zou de privacy officers kunnen verwijten dat ze hun bazen niet hebben kunnen overtuigen van de juiste prioriteit.

Een flink deel van die mensen (ik ken er nogal wat) lijkt vooral op zoek te zijn naar manieren om zelf zo min mogelijk te hoeven veranderen. Er zijn er ook die er anders in staan hoor, ik wil absoluut niet impliceren dat ze allemaal zo zijn. Het liefst krijgen ze een nieuw contract waar iedereen een handtekening onderzet waarna er niks hoeft te veranderen. Ze moeten haast wel want ze weten dat het niet realistisch is om te verhuizen of andere grote veranderingen door te voren, dat kan hun organisatie helemaal niet betalen.

Als dat niet kan dan kijken ze of ze hun data voortaan binnen de EU kunnen laten opslaan. Ik ken er niet een die serieus bezig is om Google én Microsoft én Amazon én Facebook én Apple én alle andere Amerikaanse bedrijven te verlaten. Daarmee is het pappen en nathouden en wachten op de volgende rechtszaak waarin wordt vastgesteld dat de Amerikanen nog steeds toegang tot onze data hebben en het dus weer niet goed is.

Ik heb liever dat we nu een keer doorbijten en het goed gaan regelen dan dat er een nieuwe juridische constructie wordt opgetuigd om de huidige praktijken wettelijk gezien goed te keuren.

En hoe verdient Google geld? voor meer dan 90% met data. Ik zou van iemand met een Google-label naast zijn naam wel verwacht dat hij dat zou weten.

Dat geldt voor alles

Bij Google, ook bij Facebook, ligt dat wel iets anders en is het simpelweg gebruiken van hun diensten niet voldoende om uit hun vangnet te blijven. Je zult zelf allerlei maatregelen moeten treffen, zoals een PiHole, om je data zoveel mogelijk binnen boord te houden

Nou, Google wil vooral IEDEREENS data. Jouw data an sich is helemaal niet zo interessant voor ze. Belangrijke nuance.

Deze zal stoppen met werken omdat de browser zelf bijv. de Google DNS benaderen voor ip's die bij het domein behoren.

Normaal wordt dit afgehandeld door de DNS die je netwerk aanbied aan de host en kan je hier een pi-hole tussen zetten. Door DNS over https kan dit niet meer, behalve als je traffic naar poort 53 naar buiten blokkeerd en hem zo over je eigen DNS forceert.

[Reactie gewijzigd door rjd22 op 3 september 2020 10:16]

Deze zal stoppen met werken omdat de browser zelf bijv. de Google DNS benaderen voor ip's die bij het domein behoren.

Dat staat niet in het artikel. Chrome zal kijken of je ingestelde dns-server ook DoH praat, en dan DoH gaan praten. Als hij dit niet doet (als je bijvoorbeeld dnsmasq/pi-hole gebruikt) zal hij onversteuteld gaan praten.

Je kan daarnaast er ook voor kiezen om niet de OS-instelling te pakken, maar een eigen. En dan heb je de keus om een andere DoH provider te kiezen. Als je het beste van twee werelden wilt, dan kan je bijvoorbeeld ook pi-hole vervangen met AdGuard Home. Dit is een DoH-server die ook advertenties blokkeert.

Onjuist. De browser zal zelf de DNS benaderen die je standaard al gebruikt. In de meeste gevallen zal dat niet Google zijn.

Onjuist. Chrome gebruikt op Android inderdaad de standaard browser. En dat is in bijna alle gevallen Google. In elk geval als backup.

Zelfs met een VPN verbinding gaan die achterlijke Android apparaten om mijn eigen DNS heen als ik op de VPN bijvoorbeeld Google servers blokkeer.

Je kunt er 100% vanuit gaan dat Google er alles aan doet om zoveel mogelijk verkeer richting hun servers te routeren. Daar laten ze weer analyses op los en verdienen ze dik geld mee.

Dat blijft werken zoals het nu werkt. Dat komt omdat dnsmasq geen DoH server is. Je dns-verzoeken blijven dus onversleuteld aldus het artikel.

Met Secure DNS worden dns-queries standaard versleuteld als de huidige dns-provider van de gebruiker dat ondersteunt. Als de provider het niet ondersteunt, wat op dit moment voor de meeste isp's nog geldt, worden de queries gewoon in plain text verzonden

[Reactie gewijzigd door lenwar op 3 september 2020 10:11]

Door handmatig je DNS server in te stellen in Chrome. In het artikel staat "Het wordt daarnaast mogelijk voor de gebruiker om handmatig een dns-resolver in te stellen via de instellingen in Chrome.".

Hoewel ik blij ben met alle aandacht voor DNS-beveiliging ben ik minder enthousiast voor de keuze om het in Chrome te stoppen.

Ik zou liever hebben dat ze DNS-over-HTTPS beschikbaar maken voor heel Android dan alleen voor één applicatie. Het hele idee dat applicaties zelf DNS doen vind ik sowieso verkeerd, het is juist een functie die prima thuis hoort op OS niveau.

Ik vind applicaties die zelf DNS doen op een bepaalde manier zelfs slecht voor de beveiliging. Je zal er immers rekening mee moeten houden dat verschillende applicaties verschillende DNS-servers gaan gebruiken en daar verschillende resultaten terug gaan krijgen. Ook lastig is het voor iedereen die op de een of ander manier z'n DNS monitort, of z'n DNS-server gebruikt voor beveiliging zoals het filteren van ongewenste domeinen met een Pi-hole.

Enige tijd terug, toen we net met DNS-beveiliging begonnen, was het acceptabel om DNS-over-HTTPS als browser-plugin te implementeren. Zo kon me experimenteren met nieuwe technologie voordat het OS daar klaar voor was. Dat stadium zijn we nu wel weer voorbij. Van een partij als Firefox snap ik dan nog dat ze te weinig invloed op de OS'en hebben om daar op te rekenen, maar Chrome? Google had het net zo goed in Android kunnen stoppen als in Chrome, dan hadden alle applicaties er gebruik van kunnen maken. Als iemand iets in Android kan krijgen dan is het wel Google.

<edit>Zoals onder mij aangegeven zit het wel degelijk in Android. Dan snap ik nog minder wat ze in Chrome aan het doen zijn. Misschien voor mensen op oude Android versies. Eigenlijk denk ik dan "zorg voor updates voor die oude android versies" maar dat is makkelijker gezegd dan gedaan omdat er leveranciers tussen zitten.
</edit>

Er is nog wel een argument te maken dat de API's en interfaces niet geschikt zijn om aan een applicatie te laten weten dat er gebruik wordt gemaakt van veilige DNS, maar ook daar is juist Google in een uitstekende positie om daar iets aan te veranderen.

Misschien is het deel van de strategie van Google om steeds meer via de app store te doen in plaats van via Android, en het zo steeds moeilijker te maken om die appstore (en bijhorende services) te weigeren.

[Reactie gewijzigd door CAPSLOCK2000 op 3 september 2020 10:46]

Dat kan toch bij geavanceerde netwerk instellingen Privé-DNS.

Precies, Android doet al lang systeembreed dns over https. Je kunt dat bijvoorbeeld configureren met de Adguard dns voor adblocking, al vraag ik mij af hoe handig het is om je verkeer via een Russische DNS te sturen.

AdGuard zit op Cyprus, althans hq. Verder staan hun servers verspreid over de wereld, maar Rusland zie ik er niet bij.

https://adguard.com/en/adguard-dns/overview.html

[Reactie gewijzigd door Mr. Freeze op 3 september 2020 11:30]

Je kunt ook voor deze DNS servers kiezen.

https://public-pihole.com/ (is geen pi-hole maar AdGuard Home)

Goh, interessant, je heb gelijk. Dan snap ik niet wat ze nog met Chrome aan het doen zijn.

Google is ook niet een groot bedrijf met overal dezelfde mening.
Vanuit android is de gedachte blijkbaar dat gebruikers dat zelf moeten instellen en standaard de voorkeur van het lokaal gebruikte netwerk belangrijker is.
Vanuit chrome willen ze voor de eigen app dat niet de systeemvoorkeur belangrijker is maar keuze van de chrome ontwikkelaars voor doh, tenzij de gebruiker uit zichzelf een andere keuze maakt.

Sterker nog, het risico dat er malware apps met verwijzingen naar een rogue DNS server ontstaan is aanzienlijk. De ironie: met secure DNS wordt je versleuteld naar malware geleid die vervolgens je hele systeem kapen.

Ik zie niet in hoe het gebruik van secure DNS de risico's rondom malware apps significant veranderen. Een malware app kan je ook zonder DNS direct naar malware sturen. Of het de malware lukt om je systeem over te nemen hangt af van de sandbox en welke permissies de gebruiker de app geeft.

Ik zou liever hebben dat ze DNS-over-HTTPS beschikbaar maken voor heel Android dan alleen voor één applicatie. Het hele idee dat applicaties zelf DNS doen vind ik sowieso verkeerd, het is juist een functie die prima thuis hoort op OS niveau.

Helemaal met je eens. Het typische is, is dat het al in Android zit. (ze noemen het Privé-DNS). Het is alleen wat minder uitgewerkt dan hoe het nu in Chrome is. Effectief stel je een DoH-server in die voor alles gebruikt wordt. (je kan helaas geen onderscheid maken tussen mobiel en wifi)

Ik zou liever hebben dat ze DNS-over-HTTPS beschikbaar maken voor heel Android dan alleen voor één applicatie. Het hele idee dat applicaties zelf DNS doen vind ik sowieso verkeerd, het is juist een functie die prima thuis hoort op OS niveau.

DNS over TLS (DoT) is beschikbaar sinds Android 9.0 en Chrome houdt er rekening mee:

Chrome will automatically switch to DNS-over-HTTPS if your current DNS provider is known to support it. This also applies to your current Android Private DNS (DNS-over-TLS) if you have configured one. This approach means that we can preserve any extra services offered by your DNS service provider, such as family-safe filtering, and therefore avoid breaking user expectations. In this automatic mode, Chrome will also fall back to the regular DNS service of the user’s current provider (including DNS-over-TLS if configured), in order to avoid any disruption, while periodically retrying to secure the DNS communication.

Ik wilde eingelijk bijna net dezelfde post neerpennen :-)

Net zoals je zegt is het een spijtige zaak dat applicaties zelf een andere DNS server zouden proberen te gebruiken. Dat wordt verwarrend en gevaarlijk. Ook dit soort zaken proberen te blokkeren op firewall niveau wordt moeilijk want het gaat gewoon over 443.

Zeker als bedrijf kan dit vrij lastig worden : als je op je bedrijf gewoon de DNS server (via TLS) kan uitrollen naar al je clients, dan zou je je firewall IP kunnen doorgeven, daarop filtering van botnets en kwaadaardige domeinen uitvoeren, en dan verder sturen over het internet via TLS. Eb alles blijft dan ook netjes overal geencrypteerd.

Maar als applicaties zoals Chrome dan op de achtergrond een andere DNS server beginnen gebruiken, haalt dat uiteraard je security model onderuit.

Jammer dat Chrome anders moet zijn:

Do you plan to support a canary domain similar to Mozilla's use-application-dns.net?
We have no plans to support this approach. We believe that our deployment model is significantly different from Mozilla's, and as a result canary domains won't be needed.

Het is ook een beetje een zwak argument. Het doel van de Canary domain, is om het gedrag makkelijker centraal uit te zetten. (om te helpen voorkomen dat werknemers zelf instellingen gaan doen).

NextDNS is ook een top oplossing voor ad blocking.
Heb je ook op heel je telefoon of tablet geen reclame, ipv alleen de Chrome browser

Hmmm zojuist een update en DoH stond niet aan, heb deze zelf eens aangezet en gekozen voor 1.1.1.1

Is zien wat dat geeft

Wat ik me afvraag is wat de toegevoegde waarde van DoH is als je al een DNS over TLS server hebt ingesteld. Zal Chrome ondanks dat verkeer al wordt versleuteld toch nog eens DoH gaan gebruiken? In dat geval is er geen privacy- of securityvoordeel om van te spreken maar heb je wel het effect dat apps en de browser andere DNS-records krijgen, wat enorme verwarring kan veroorzaken bij storingen.

Die twee zaken hebben helemaal niks met elkaar te maken.
Stel dat er niks versleuteld is, en de internetverkenner een andere DNS-server gebruikt dan de rest van het besturingssysteem, dan heb je exact hetzelfde probleem.

Ik ben het met je eens dat het op z'n minst een vreemde gewaarwording is, dat Google zowel in Android als in Chrome apart van elkaar versleuteld DNS-verkeer laat instellen.
Dat Mozilla dat doet met Firefox snap ik ergens nog wel, omdat zij geen invloed op het besturingssysteem uitoefenen, maar dat Google het met Chrome op Android doet vind ik ook vreemd.

Die twee zaken hebben helemaal niks met elkaar te maken.

Daar ben ik het niet mee eens. Het Android-team van Google heeft DNS over TLS ingeschakeld om dezelfde redenen als dat het Chrome-team DoH heeft aangezet. Nu doen ze het dus dubbelop.

Een voorbeeld vanuit een firewall/security perspectief.

"Smart Devices" gebruiken vaak ingebakken DNS servers. Veelal 8.8.8.8, waarmee een lokale Pi-Hole of soortgelijke worden omzeild.
Met firewall rules kun je Clients alleen laten toestaan de lokale Pi-Hole toestaan op poort 53.
DNS over TLS is te blokkeren door poort 853 te blokkeren. DNS over HTTPS is niet te blokkeren, want uitgaand HTTPS (443) verkeer wordt over het algemeen toegestaan.

Je kunt wel een eigen lijst maken met alle publieke DNS servers welke DoH ondersteunen, en deze vervolgens blokkeren. Heb dit getest en dat werkt. Denk bijvoorbeeld aan de OpenDNS oplossing van Firefox.

Er zijn meerdere mogelijkheden om security van thuis/werk te verhogen. DNS is altijd een mooie en makkelijke manier geweest. DoH is wat mij betreft een doorn in het oog. Dan prefereer ik DoT.
Laag7 inspectie is in mijn optiek geen optie, dit in verband met de certificaten rompslomp.

edit - oeps, nog niet helemaal wakker mag weg

[Reactie gewijzigd door Steef op 3 september 2020 10:12]