Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Google test dns-over-https bij Chrome met zes dns-providers

Google experimenteert met dns-over-https bij Chrome 78 op desktop en mobiel met in eerste instantie zes dns-providers, waaronder Google zelf. Als de dns-aanbieder van de gebruiker op de lijst staat, schakelt de browser automatisch over naar dns-over-https.

De dns-providers waarmee Google samenwerkt, zijn Cleanbrowsing, Cloudflare, DNS.SB, OpenDNS en Quad9. Deze zijn volgens het bedrijf gekozen vanwege hun ferme standpunt op het gebied van privacy en beveiliging, en hun compatibiliteit op het gebied van dns-over-https, of doh. Niet bekend is of Google de lijst wil uitbreiden. Het Nederlandse PowerDNS staat bijvoorbeeld niet op de lijst.

Bij de implementatie van Google kijkt de browser of de dns-aanbieder van de gebruiker op de lijst staat om van een doh-dienst gebruik te kunnen maken. Is dat niet het geval, dan verloopt de verbinding als vanouds. Omdat Chrome de standaard ingestelde dns-provider verkiest en alleen dns-over-https activeert als die provider dit aanbiedt, ervaren gebruikers geen problemen met door de aanbieder aangeboden functies voor parenting control en malwarebescherming, aldus Google.

Daarmee wijkt de implementatie af van die van Mozilla. Die organisatie kiest vooralsnog voor de 1.1.1.1-dns-resolver van Cloudflare en schakelt deze vanaf eind september standaard in voor Amerikaanse gebruikers.

Google test de doh-implementatie bij een fractie van de Chrome 78-gebruikers op alle ondersteunde platforms op Linux en iOS na. Op Android 9 en latere versies van het besturingssysteem kan Chrome gebruikmaken van een doh-aanbieder die door de gebruiker bij de dns-instellingen is ingesteld. ZDNet publiceerde eerder deze week de stappen die een gebruiker moet doorlopen om de desktopversie van Chrome buiten de test om van dns-over-https gebruik te laten maken.

Google en Mozilla testen het gebruik van doh uit privacy- en beveiligingsoverwegingen. De techniek versleutelt een dns-query met tls-encryptie, waardoor partijen zoals providers niet meer kunnen zien welke webpagina's specifieke gebruikers opvragen. Google wijst erop dat de techniek bijvoorbeeld voorkomt dat derde partijen bij het gebruik van publieke hotspots kunnen zien welke websites door gebruikers worden bezocht.

Door Olaf van Miltenburg

Nieuwscoördinator

11-09-2019 • 12:06

129 Linkedin Google+

Reacties (129)

Wijzig sortering
"World wide, browsers by default direct DNS queries to whatever server is configured, meaning whoever operates said server has the ability to see users' queries"

DoH doet daar echt niets aan.
Vraag me wel af hoe het vastgesteld wordt.

Standaard worden op thuis routers die router IP als DNS doorgegeven. De router resolved dan verder (naar de ISP, Google, of whatever).

Wanneer Chrome naar IP van je netwerk adapter kijkt, dan zal je nooit profiteren hiervan, want een DoT of DoH is er niet voor je thuisrouter.

Dit betekent dat Chrome een externe (soort van) leak-test moet doen om te zien waar uiteindelijk je DNS verzoek terecht komt.

Dit is de reden waarom ik in de DHCP zelf rechtstreeks de externe DNS publiceer.
ik snap het hele punt van 'queries inzien' al helemaal niet.

Dat is momenteel gewoon ook het geval, over UDP DNS. Waarom doet iedereen er ineens zo moeilijk over.
Jij kan op je werklaptop zomaar de hostsfile aanpassen? |:(
Jij gaat op je werklaptop zomaar naar onbekende IP adresjes? 8)7
Jij gaat gewoon naar onbekende IP adressen zonder ze even op te zoeken? _/-\o_
Pornhub ip ranges zijn niet geblokkeerd in de firewall?

[Reactie gewijzigd door Tokkes op 12 september 2019 19:59]

Nee, bedankt dat je direct alles in het ridicule trekt.
Wat denk je nou....

Ik zat op mijn werklaptop, waarop ik een VM en een VPN draai, en in die VM heb ik natuurlijk niet de hosts file aangepast...Ik wilde het IP adres Googlen, door het te selecteren, en dan met rechtermuis tweede optie te klikken.

Normaal staat daar, als je iets selecteert "Google doorzoeken op".
Nu, omdat het geïnterpreteerd werd als adres werd dat automatisch "Ga naar".
Daar had ik in de muscle memory geen rekening mee gehouden.

En nee Pornhub is niet geblokkeerd in de Firewall, blijkt.
Nee, bedankt dat je direct alles in het ridicule trekt.
Wat denk je nou....
wel, gezien veel comments, en sommige forum posts - het is goed genoeg mogelijk.
Natuurlijk heeft DNS met de getoonde pagina te maken, DUH

Er werd echter het volgende geschreven:
"Elke browser zou dezelfde pagina moeten laten zien. Dat is dus niet meer zo."

En als je een normale DNS server gebruikt, (je provider, Google, etc) is dat ook zo.
Dus dat "dit gedoe" gefilterd internet oplevert is onzin, want dan doet de DNS niet wat hij zou moeten doen.
Dat is toch al lang niet meer zo, in België (weet niet of het voor Nederland ook zo is) worden een hoop "illegale sites" geresolved naar bijvoorbeeld (http://networkmsg.telenet.be/blocked/fccu/ als je Telenet klant bent). pas je DNS server aan en dat probleem is van de baan...
Daar heb je gelijk in.
Hierbij doet de DNS dus niet wat deze zou moeten doen.
Maar daar heeft "dit gedoe" niets mee te maken.
... (weet niet of het voor Nederland ook zo is) ...
In Nederland krijgt men voor bepaalde sites een provider pagina te zien dat de site geblokkeerd is. Zie ook: https://www.tele2.nl/pira...-geblokkeerde-subdomeinenBijvoorbeeld een grote download site voor magnets (vroeger torrent bestanden).

[Reactie gewijzigd door Roel911 op 11 september 2019 21:56]

DNS heeft alles met de getoonde pagina te maken. Zet de volgende regel maar eens in je hostsfile:
66.254.114.41 tweakers.net
Dan krijg ik, zoals het hoort:
NET::ERR_CERT_COMMON_NAME_INVALID
;)

De servers van pornhub hebben namelijk niet (de private key van) het certificaat van tweakers.net.
Als de beheerder van de DNS server besluit dat een query wel een ander resultaat oplevert dan die van je provider dan kan dat gewoon.
Nee, dat kan dus niet. Althans, niet als er HTTPS gebruikt wordt, en daar zijn Chrome en Firefox (met hulp van Let's Encrypt) hard voor aan het pushen.

Begrijp me niet verkeerd, je hebt gelijk met de privacy-zorgen (de DNS providers ziet welke sites je bezoekt), en blokkeren (verkeerd DNS resultaat teruggeven) is inderdaad ook mogelijk.

Maar daadwerkelijk een andere pagina weergeven kan op dit moment niet zolang HTTPS geforceerd wordt, en dat is steeds meer het geval.
Een partij als Google is zelf CA. En tuurlijk, ze zullen vast geen fratsen van dat kaliber uithalen. Toch?

Alles van A tot Z is straks Google, wie reguleert dat?
Een partij als Google is zelf CA. En tuurlijk, ze zullen vast geen fratsen van dat kaliber uithalen. Toch?
Klopt, en in theorie kan Google daarmee een pagina vervalsen als ze ook DNS in handen hebben natuurlijk. Ze zouden wel geband worden van andere CA root trust stores, want dit is tegen de regels voor CAs.

Maar waarom zouden ze dat doen? Als Google zo graag wil aanpassen wat je ziet, dan kunnen ze dat natuurlijk gewoon in Chrome zelf vervalsen; geen DNS-over-HTTP of certificaat-vervalsing nodig.
Het gaat in dit geval niet over de private key, maar juist over de public key ;-)
Het gaat in dit geval niet over de private key, maar juist over de public key ;-)
Nee, het gaat om de private key. Om te bewijzen dat je browser met https://tweakers.net/ praat moeten de webservers van Tweakers de private key van het certificaat hebben. En die hebben de PornHub servers niet (hoop ik).

De public key van https://tweakers.net/ kan iedereen triviaal aankomen, die staat namelijk gewoon in het certificaat. Hier, ik heb hem zelfs:
Modulus (4096 bits):
D2 AF 8F C4 1F C5 24 E3 04 8A CB 47 C5 CF 16 B4 D9 7E EC 1A 80 EE 0A D0 A8 A2 7E B3 B4 E6 16 DD DD 9F 82 18 83 C7 3E 8B EE 17 0F D0 CE 67 3D 0C 23 59 5F 54 BA FB E0 D3 5C 1F 5B 15 EA 9C 2A C9 3A C0 5D 46 43 F7 88 D0 9A C9 82 14 5F BF 2F 2A BD E0 A9 25 27 69 C1 87 18 B4 44 3E 7A AC 8A 4F E9 50 60 B5 5C B3 D8 0D 7C E3 06 68 63 6E C2 CC 4F AD A2 7F A7 5B E7 22 AC AF 07 C4 C9 D4 BA 14 97 AE D5 31 9B 6D D0 7F 28 B7 1B 5A 5D 45 CB F6 75 7F D5 1A EF 67 9E 5D 57 E8 0F 73 C3 C8 68 25 9D 7C 56 D3 C4 C9 40 04 00 04 AF E6 41 9D 96 AF 89 47 51 24 B2 82 E2 57 F9 A8 D3 C5 9F 0C 17 35 56 AD AB 36 51 B3 36 B3 69 FA CE 04 31 AC 30 F2 DA 9F C3 94 F6 C7 D0 B8 48 07 FC 33 51 3D 9D EB D2 F9 9B DE 1D 4A BD EB 1B FE 56 2D 4D D5 21 CB 14 F9 51 79 98 54 D7 FA 39 D0 29 AF 37 E5 EF ED EE FE 20 C6 0D 7C BE 39 94 F7 C0 0A CE EE EE 24 55 C8 22 97 F4 A6 F1 93 16 BA 6E F8 13 C9 1E 1C C8 C9 E1 48 5D 96 89 D2 B7 1D 37 B6 94 8F 91 D5 11 B4 8E 79 1B F4 F3 B6 D6 D3 30 D9 71 EB 45 31 1E E3 74 C6 29 81 A8 80 AB 90 B4 CC D5 A3 CD 00 C1 93 3B 20 5D 38 EB BE 9B 62 16 05 44 6E 91 64 17 E0 C3 84 D8 48 8B 09 57 01 D9 D3 7F FD 37 E7 66 70 9C 24 A7 7C 4F 97 6C 6A E3 E2 4D 11 F2 58 F8 6A A4 9B A0 F9 A7 13 1A 86 01 34 69 13 FC D7 66 22 DB 53 41 C2 9D AC 35 DA 0B B5 C1 FC 36 32 DD 4F E7 A5 45 86 06 8F EC BC 99 AB 37 B1 86 A7 E7 33 1D C7 4E 29 07 59 C0 35 F9 70 85 93 11 E9 DF 7E 97 9D DD 46 3F 9B D8 D4 DC 50 2D AB 58 56 5A 7F 64 73 63 BE 98 FE 5C 3F 49 C2 7A F3 44 E1 CE E9 DB B5 94 1D 54 96 50 B8 1B F9 A3 C3 EF D2 E3 0C F5 46 B7 6E 37 19 FD 14 18 67 41 69 72 A3

Public Exponent (24 bits):
01 00 01

[Reactie gewijzigd door deadinspace op 13 september 2019 09:24]

Eh...

Het betrof zijn uitleg van de foutmelding: NET::ERR_CERT_COMMON_NAME_INVALID

JIj als client kunt de private key niet checken (duh).

Die kun je dus alleen checken op de public key die aan jou gegeven wordt ter identificatie :+
Nee, wat Firefox doet is zelfs erger (het standaard instellen, gelukkig alleen in de VS voorlopig).

[Reactie gewijzigd door Lethalis op 11 september 2019 14:44]

Onzin. Dan moet je de reacties op het Firefox artikel eens lezen. Die waren helemaal niet zo positief. Ik heb na het lezen van dat artikel gelijk iets in de about:config veranderd om het helemaal uit te zetten.

Maar behalve dat, zelfs al zou er bij Google artikelen meer geklaagd worden over privacy: dat heeft Google helemaal aan zichzelf te danken. Mozilla is over het algemeen veel privacy-vriendelijker. Alhoewel ik net niet eens ben met Mozilla’s keuze, snap ik wel dat het voor bepaalde gebruikers de privacy kan vergroten. Vooral voor Amerikanen met een ISP die hun DNS requests datamined... (volgens mij is dat in NL niet gebruikelijk, ik ken geen ISP waarvan bewezen is dat ze het doen)

[Reactie gewijzigd door kozue op 11 september 2019 17:58]

Als je de DNS van google nu gebruikt dan is dit al zo. Ik heb vaak genoeg gehad met gebruik van Google DNS dat een dev omgeving van een website ineens geindexeerd stond in de search. Ik kon niet anders concluderen dat Google DNS in combinatie met Google Search werkt.
Daarom gebruik ik de Google DNS ook niet. Sowieso gebruik ik mijn eigen DNS server (resolver op PfSense).

Nooit gezeur met DNS servers die down zijn :) En zonder dat Google elke DNS query van mij indexeert.

Website suggesties zet ik ook altijd uit... zodat dingen die ik in de adresbalk intik ook niet bij Google eindigen.

Maar goed, als het allemaal zo doorgaat, stap ik wel over op open source Chromium. Dan heb ik er alle controle over.

En daar heb ik desnoods ook wel 5 uur lang zelf compileren voor over ;)

[Reactie gewijzigd door Lethalis op 11 september 2019 14:50]

Als je de DNS van je ISP gebruikt, en wat vroeger zo bij Ziggo / voorheen @ home zo was, dan kon je er vanuitgaan dat iedere zondag websites gewoon zienbaar trager waren. Mijn conclusie is dat de openbare DNS van die ISP een extreem veel aantal DNS queries voor hun kiezen kreeg en daarom de neiging naar een andere (en wel snellere) DNS wenselijk was. Of gewoon de First / Secundaire omwisselen met elkaar.

Maar dit applaudiseer ik eigenlijk toe, dat ook de websites en URL's die je bezoekt over DNS 'beschermd' zijn. We hoeven ons niet langer meer te verbergen achter een TOR als het allemaal echt zo spannend en secret moet zijn.
blijf dan maar al ver weg van chrome, 8.8.8.8 en 8.8.4.4 en alle andere alternatieve DNS-providers dan die van je provider
Ik draai dan ook mijn eigen DNS server.

Chrome niet gebruiken is moeilijker. Om de simpele reden dat ik nooit echt vriendjes met Firefox ben geworden en te arm ben om een Mac te kopen.

Over Edge wil ik niet eens praten.
Kijk eens naar Vivaldi?
En waar resolved jouw DNS server naar toe? Naar een andere DNS-server? Of rechtstreeks naar de root-servers van alle tld's?
Onze staat geeft jouw gegevens met het grootste gemak aan de VS.
Google anders op 5 eyes, 9 eyes en 14 eyes.
Dat geloof ik zomaar.

Alleen Google en consorten maken er ook meteen gebruik van op een commerciële manier.
Latency is het belangrijkste in ieder netwerk. Je gebruikt dus altijd de DNS servers van je eigen provider.
Wanneer je een **** provider hebt en geen gebruik wilt maken van hun DNS servers dan is CloudFlare meestal de best optie. Zie ook: https://www.dnsperf.com/
Gezien CloudFlare ook een goede privacy policy heeft gebruik ik deze vaak als fallback.

Wil je zelf testen dan kan dat met deze tool:
https://www.grc.com/dns/benchmark.htm
Wij draaien PfSense met de DNS resolver. Dat is in feite gewoon een geïntegreerde DNS server.

Draai ik thuis ook. Als je een managed switch met vlan tagging hebt, kun je van elke NUC een router maken.
Hoe gaat dit icm Pihole?
Ik heb Pihole draaien welke 1.1.1.1 en 8.8.8.8 en OpenDNS gebruikt als resolvers.
Maar m'n PC/browser gebruikt natuurlijk de Pihole als DNS.
Gaat dit dns verkeer dan alsnog over HTTPS (al dan niet vanaf Pihole)?
De implementatie van chrome zal gewoon blijven gaan zoals het nu gaat (je pihole zal gewoon dns server blijven en die blijft gewoon zijn data via poort 53 naar cloudflare of Google sturen). Gebruik je echter Firefox dan zal die je pihole straks compleet bypasssen en gooit hij al je dns verkeer via DoH naar 1.1.1.1.

Maar in de volgende release van je pihole zal er voor gezorgd worden dat de DoH van Firefox uitgezet wordt. Een update is dan voldoende.
Maar in de volgende release van je pihole zal er voor gezorgd worden dat de DoH van Firefox uitgezet wordt. Een update is dan voldoende.
Bron? Volgens mij moet je in Firefox network.trr.mode op 5 zetten om DoH nu (en in de toekomst) uit te schakelen.
Net pihole v4.3.2 (gisteren gereleased) geinstalleerd van scratch (nieuwe installatie). De firefox fix is NIET opgenomen in deze release. Het is dus nog steeds noodzakelijk de setting manueel toe te voegen!!!

meer info, zie forum post...
Ja dat heb ik zeker gelezen maar ik zeg al dat is de eerste stap, daarna wordt ook dat genegeerd.
Dat heb je voor een (groot) deel ook zelf nog in de hand.
Als jij verkeer op poort 853 blokkeert, dan werkt DoH al niet meer voor zover ik begrepen heb.

In dat geval wordt dan alsnog teruggevallen op de wel bereikbare DNS Servers die gebruik maken van poort 53.
DoH werkt over port 443 ;-) e.g. zoals https ook over werkt

zie: https://labs.ripe.net/Mem...-dns-over-https-explained (en dan onderaan). --> Experimenting with DOH

[Reactie gewijzigd door Dutch2007 op 11 september 2019 16:16]

Ah wacht, DoT werkt over 853 inderdaad ...

In dat geval kan het internet (op termijn) nog wel eens flink gaan veranderen als browsermakers gaan bepalen hoe maar vooral ook WIE als resolver gaan fungeren.
Vreemde gang van zaken. Negeert firefox dan gewoon de ingestelde dns-setting in je netwerkomgeving? Ik neem aan dat je dat dan kunt aanpassen?
Ja, dat kan inderdaad makkelijk. Ik verwacht ook uiteindelijk via policies
Je kunt een eigen DoH server instellen of DoH uitzetten. Ook wordt DoH in Firefox uitgeschakeld als de beheerder van de lokale DNS-server een NXDOMAIN antwoord op een bepaalde domeinquery instelt.
Met Chrome for business kun je de ingebouwde DNS client uitschakelen.
Ik vraag me af hoe Chrome weet welke DNS-server(s) ik gebruik. Ik dacht altijd dat er een request bij het OS gedaan werd en dat de browser dus niet zelf de server benaderd.
Ook aangezien een hosts-file op systeem werkt in een browser.

Dus als Chrome kan weten welke servers ik gebruik zullen ze misschien een DNS request doen waarop de verschillende DNS-providers anders reageren?
Meh, waarom doen ze niet zoiets?

Check of huidige DNS DOH ondersteunt, zo ja dan hup gaan met die banaan. Zo niet, pak een DOH provider uit de lijst.

Lijkt mij een beetje onnodig moeilijk doen om ook verplicht te stellen dat de DOH provider ook normale DNS ondersteunt. Wat zijn de andere criteria, of ze wel bonen koffie hebben daar? :Y)

[Reactie gewijzigd door Ventieldopje op 11 september 2019 12:28]

PowerDNS levert software, geen publieke dienst. Ja, er is een publiek bereikbare DoH resolver, voor testing purposes om te stimuleren dat mensen met DoH via dnsdist aan de slag gaan.
we are also offering our own experimental DoH service through https://doh.powerdns.org
Voor implementatie in een browser/device zijn er andere garanties nodig natuurlijk.
DNS over TLS is gewoon nog iets minder volwassen, dat zal de end game wel worden denk ik zo.
De reden voor dns over https is vooral voor alles wat onderweg wordt meegelezen. Als je dns via het dns protocol gebruikt, dan kan iedereen dat heel eenvoudig mee lezen op basis van het poort nummer en het verzoek/antwoord. In het slechtste geval kan het worden onderschept en beantwoord met iets heel anders dan van de echte dns server.

Zodra je dns over https gebruikt kan onderweg niet eens gezien worden dat het dns verkeer is. Alleen het feit dat het naar een dns-over-https provider gaat geeft een idee. Maar dan moet het nog worden uitgepakt om de gewenste info te krijgen en daar is de s in https de volgende horde die genomen moet worden.

Hier in Europa en vooral in NL zijn de dns servers van de providers goed te vertrouwen. In andere delen van de wereld is dat vaak minder. Als je dan een andere dns server gebruikt zou de provider of ieder ander ergens onderweg dat signaal kunnen oppakken en zelf beantwoorden zonder dat je het door hebt.
Ik gebruik Blokada om advertenties te weren op mijn telefoon. Bij het lezen van dit bericht vroeg ik me af of die blijft werken met dit soort technieken. Heb ik het goed dat dit straks dan nog steeds werkt omdat Blokada lokaal draait op mijn telefoon en dus al de uitgaande calls blokkeert nog voordat die geresolved zijn door een DNS service?
Kan je hiermee dan voorkomen dat uw werkgever ziet naar waar je surft?
En omgekeerd: kan je als werkgever dit tegenhouden zodat je nog altijd ziet naar waar iedereen surft?
Ja, dat voorkomt dat je werkgever ziet waar je naar surft..

waarschijnlijk kan je werkgever dit tegen houden door instellingen in Chrome te managen en het instellen van DoH uit te zetten. Niet elke werkgever doet dat.

Ik geloof trouwens niet de meeste werkgevers het internet gebruik van werknemers in de gaten houden. Dit zullen ze pas doen wanneer daar reden voor is dan heb je denk ik een ander probleem (maar dat staat los van je vraag).
Het heeft ook geen zin. Niemand verbindt z'n telefoon nog met bedrijfsnetwerken. Met ongelimiteerde 4G abonnementen kun je veel sneller internetten dan over Wireless Fidelity. Via MDM kun je veel dingen niet monitoren.
Je werkgever kan er natuurlijk altijd voor kiezen om verkeer binnen het bedrijf via hun eigen DNS server te laten verlopen en te forwarden naar aan DNS server buiten het bedrijf. Al dan niet met DoH.
De zaak kan dit blokkeren door het http en https verkeer naar de dns providers te blokkeren, zoals ze mogelijk ook porno en zo blokkeren.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Smartphones

'14 '15 '16 '17 2018

Tweakers vormt samen met Tweakers Elect, Hardware Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True