Microsoft implementeert dns-over-https in Insider Previews van Windows 10

Microsoft maakt dns-over-https voor het eerst beschikbaar in Windows 10. Het bedrijf kondigde vorig jaar al aan dat het DoH in het besturingssysteem zou implementeren. Een eerste testversie is nu beschikbaar in een Insider Preview.

Gebruikers kunnen dns-over-https voorlopig alleen handmatig inschakelen door dat zelf aan te passen in de registry. Daarvoor moeten ze op de meest recente Insider Preview-build zitten. Dat is Build 19628. Gebruikers moeten in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters registry key een nieuwe Dword-waarde aanmaken genaamd EnableAutoDoh.

Het gaat voorlopig nog om een test, schrijft Microsoft. Als de functie straks in normale builds van het besturingssysteem zit, is het niet meer mogelijk die via de registry aan te passen. Dat moet dan via de instellingen.

Gebruikers moeten zelf in het Configuratiescherm instellen welke dns-server ze willen gebruiken. DoH in Windows 10 werkt met dns-providers Cloudflare, Google en Quad9. Om te wisselen tussen DoH-provider moeten gebruikers de dns-service herstarten. Dat kan volgens Microsoft het best door de hele computer opnieuw op te starten.

Microsoft kondigde vorig jaar al aan dat het dns-over-https wilde implementeren in het besturingssysteem. Op termijn moeten de dns-instellingen makkelijker beschikbaar komen voor gebruikers. Het bedrijf heeft nog niet uitgelegd in welke fases dat moet gebeuren. Op termijn moet Windows 10 ook dns-over-tls ondersteunen.

Bij dns-over-https worden, zoals de naam al voorspelt, dns-queries versleuteld. Normaal gesproken maakt een besturingssysteem gebruik van de dns-instellingen van het netwerk, wat de isp regelt bij individuele gebruikers. Dns-over-https zorgt ervoor dat dns-verkeer niet meer via de provider loopt, wat in theorie anoniemer zou zijn. De implementatie is echter controversieel: veel experts zeggen dat daarmee de privacy van gebruikers slechts wordt verplaatst naar een andere, commerciële partij. Verschillende grote bedrijven zoals Mozilla en Google implementeren dns-over-https inmiddels in hun browsers. Tweakers schreef vorig jaar uitgebreid achtergrondverhaal over dns-over-https.

Reacties (99)

Voordat men begint over beveiliging in grote organisaties, die afhankelijk zijn van leesbare DNS queries naar eigen servers: ongetwijfeld is de uiteindelijke implementatie uit te schakelen via een policy. Voor bedrijven verandert er dus niets, mits zij goed omgaan met BYOD (niet toestaan, of gescheiden van het eigen netwerk en acceptatie van de risico's die dit meebrengt).

Deze techniek is met name bedoeld om standaard aan te hebben voor de rest van de wereld, die niet genieten van gemonitorde DNS verzoeken met de beste bedoelingen.

[Reactie gewijzigd door The Zep Man op 14 mei 2020 09:58]

Waarbij de rest van de wereld dan niet slaat op mensen met een PiHole, een router met dnsmasq of hosts-based filtering, etc. Ik gebruik het zelf op mijn Ubiquiti router (je weet wel - die uit de Best Buy Guide van deze week ), en dat bevalt geweldig goed. Maar DNS over HTTPS gaat 't 'm dan niet worden...

PiHole ondersteund DoH via cloudflared. Zo even uit mijn hoofd is er ook DNS encryptie mogelijk op ubiquiti devices, alleen niet via de GUI en daarmee niet 'gebruiksvriendelijk'. Kan zijn dat ik er naast zit hoor, dan slik ik mn woorden in.

Hoe kun je dat wel aanzetten dan?

30 seconden op google: https://bendews.com/posts/implement-dns-over-https/

Dit doet precies niet wat er gevraagd is. Dit zorgt ervoor dat je DoH als upstream kan gebruiken in PiHole, terwijl de vraag is hoe je zelf DoH kan draaien via PiHole.

[Reactie gewijzigd door dcm360 op 14 mei 2020 10:50]

Ik reageerde hierop:
"Zo even uit mijn hoofd is er ook DNS encryptie mogelijk op ubiquiti devices, alleen niet via de GUI en daarmee niet 'gebruiksvriendelijk'. Kan zijn dat ik er naast zit hoor, dan slik ik mn woorden in."
En niet op het Pihole gedeelte van de vraag.

Dat was niet helemaal duidelijk, want de handleiding die je link gaat op beiden in

Ook voor de USG geldt hetzelfde punt: de handleiding laat je DoH gebruiken voor requests upstream, maar biedt niet de mogelijkheid om zelf DoH-requests af te handelen. Aangezien je verbonden clients nog steeds geen DoH kan laten gebruiken (met je eigen resolver), lost dit het probleem maar half op.

Dat was niet helemaal duidelijk, want de handleiding die je link gaat op beiden in

Klopt, het was ook een dubbele vraag/opmerking.

Maar waarom zou je thuis, tussen je pc en router, DoH willen gebruiken? Als je vanaf je router een beveiligde verbinding hebt naar je DNS server is het toch voldoende? Of snap ik het nu verkeerd?

Je zou het als methode kunnen inzetten om altijd jouw eigen dns-server te gebruiken. Wellicht niet een erg gebruikelijke use-case als ik het zo bedenk. Al vind ik dat de use-case voor DoH in Nederland ook wel matig, ik stuur mijn dns-queries persoonlijk liever op naar mn provider dan naar een service beheerd door een Amerikaanse commerciële partij.

PiHole (dnsmasq met een schilletje) ondersteund geen DoH. Je kan PiHole vervangen met het lichtere Adguard Home. Die ondersteund het wel. De installatie is één binary plaatsen. Het heeft één configuratiebestand en kan ook via een webinterface bediend/configureerd worden.

https://github.com/AdguardTeam/AdGuardHome

Ik heb het zelf sinds kort op een Ubiquiti USG3 router draaien. Werkt goed. Al loop ik tegen één bugje aan, waardoor ik hem op router achter de ingebouwde dnsmasq moet zetten. Ik heb in de Github een issue aangemaakt:

https://github.com/AdguardTeam/AdGuardHome/issues/1668

Je kunt de Debian-repositories op een EdgeRouter inladen en dan Unbound installeren. Dat is allemaal op Google te vinden.

Waarbij de rest van de wereld dan niet slaat op mensen met een PiHole, een router met dnsmasq of hosts-based filtering, etc. Ik gebruik het zelf op mijn Ubiquiti router (je weet wel - die uit de Best Buy Guide van deze week ), en dat bevalt geweldig goed.

Daarmee bedoelde ik de massa. De mensen die niet weten wat DNS is, en dat ook niet willen weten.

Controleer ook je browsers dubbel. Die kunnen zelf DoH inschakelen/afhandelen.

[Reactie gewijzigd door The Zep Man op 14 mei 2020 09:56]

Kan Pihole ook DOH requests aan?
Ik heb dnsnext.io op die manier ook draaien. De meeste query's gaan via DOH.
Alleen de Fritzbox thuis kan nog geen DOH, maar bijna alle interne devices wel.
Lekker makkelijk: thuis, werk, onderweg allemaal via dezelfde veilige DNS oplossing.

Ik heb al een tijdje dnscrypt-proxy op m'n Ubiquiti USG3 router draaien. Een paar dagen geleden vervangen door Adguard Home. Werkt allemaal goed. Er zit wel een bugje in AGH waardoor hij op een andere poort moet draaien (en de ingebouwde dnsmasq hem dus moet aanroepen)

https://github.com/AdguardTeam/AdGuardHome/issues/1668

Zowel dnscrypt-proxy als Adguard Home kunnen als 'lokale DoH server' draaien. (dus DoH in je LAN, en de verzoeken worden dan doorgestuurd naar bijvoorbeeld Cloudflare, of net hoe je het instelt)

Voordat men begint over beveiliging in grote organisaties, die afhankelijk zijn van leesbare DNS queries naar eigen servers: ongetwijfeld is de uiteindelijke implementatie uit te schakelen via een policy. Voor bedrijven verandert er dus niets, mits zij goed omgaan met BYOD (niet toestaan, of gescheiden van het eigen netwerk en acceptatie van de risico's die dit meebrengt).

Ondersteuning betekent niet dat je het moet gebruiken, of dat de "standaard" DNS niet meer zou werken.

Als je als bedrijf zonodig DNS queries zou willen monitoren (ik zou zo even niet weten wat je daarmee zou bereiken, behalve onderzoek als het kalf al verdronken is), is er dus helemaal niets aan de hand. Je forceert je clients naar je eigen DNS server en firewallt alles wat naar poort 53 ruikt. (En nee, dat is geen beveiliging).

Deze techniek is met name bedoeld om standaard aan te hebben voor de rest van de wereld, die niet genieten van gemonitorde DNS verzoeken met de beste bedoelingen.

Eerlijk gezegd vind ik dit een vrij enge uitspraak. Ik zou niet weten waarom je DNS verzoeken gemonitord zou willen hebben, ook niet "met de beste bedoelingen".

Ik zou niet weten waarom je DNS verzoeken gemonitord zou willen hebben, ook niet "met de beste bedoelingen"

phishing.

Met alle respect, maar met DNS-monitoring los je geen phising op en je voorkomt het er ook niet mee. Je kan het hooguit detecteren. Phising activiteiten ontwikkelen zo snel, het is niet strategisch om alleen je pijlen te blijven richten op iets wat je moeilijk bij kan houden. Phising gaat over zoveel domeinen, is zo dynamisch, dat je eigenlijk gewoon moet accepteren dat je altijd achter de feiten aan blijft lopen.

Ja, je kan een maatregel treffen door DNS-queries te filteren. Maar dat zou maar een van de maatregelen moeten zijn, zeker niet de enige. En: filteren, niet monitoren.

Overigens is het wel een hardnekkige gedachte dat we alle security risico's maar op moeten lossen met techniek zoals "het monitoren van DNS-queries".

Anders gezegd, als je phising tegen wil gaan is security awareness als vele malen effectiever bewezen.

Met alle respect, maar met DNS-monitoring los je geen phising op en je voorkomt het er ook niet mee.

Nee, maar het helpt wel reactief, voor bijvoorbeeld forensisch onderzoek. Reactieve beveiliging is ook een laag van beveiliging.

Daarnaast kan ik mij voorstellen dat bedrijven graag onverwacht gedrag van computers (bijvoorbeeld geïnfecteerd met malware) wilt kunnen monitoren. Het gaat er dan niet om wat een individueel bezoekt.

Er is niets fout aan het verwerken van DNS queries van eigen infrastructuur, zolang dat maar met en binnen een vooraf gedefinieerde doelstelling plaatsvindt.

[Reactie gewijzigd door The Zep Man op 14 mei 2020 17:53]

[...]
Nee, maar het help wel reactief, voor bijvoorbeeld forensisch onderzoek. Reactieve beveiliging is ook een laag van beveiliging.

Daarnaast kan ik mij voorstellen dat bedrijven graag onverwacht gedrag van computers (bijvoorbeeld geïnfecteerd met malware) wilt kunnen monitoren. Het gaat er dan niet om wat een individueel bezoekt.

Er is niets fout aan het verwerken van DNS queries van eigen infrastructuur, zolang dat maar met en binnen een vooraf gedefinieerde doelstelling plaatsvindt.

Helemaal mee eens, maar zoals ik hierboven ook beschrijf: er zijn bepaalde maatregelen die een (veel!) hogere prioriteit zouden moeten hebben dan "DNS monitoring". Er wordt gesuggereerd dat DNS monitoring zo'n beetje de heilige graal is van informatie beveiliging, althans, zo komt het op mij over, en dat lijkt mij niet juist.

Tot slot zou je je wel moeten afvragen (vind ik) of het bewaren van DNS logs niet een risico op zichzelf wordt versus de afweging wat het oplevert qua informatie. Ik denk dat dit per organisatie heel sterk kan verschillen en dat het zomaar een hele dure oefening zou kunnen worden om het echt goed te doen.

Die gegevens van wat het bedrijf zoal bezoekt (dus niet de individuen) kan ook heel interessant zijn voor personen die niet zoveel goeds in de zin hebben...kortom, zoals alles met security: afwegen.

Ik zou niet weten waarom je DNS verzoeken gemonitord zou willen hebben, ook niet "met de beste bedoelingen"

is wat anders dan

Helemaal mee eens, maar zoals ik hierboven ook beschrijf: er zijn bepaalde maatregelen die een (veel!) hogere prioriteit zouden moeten hebben dan "DNS monitoring".

DNS monitoring is een onderdeel van veel EDR oplossingen. @The Zep Man slaat de spijker op zijn kop.
Het is niet kwalijk te nemen dat mensen bepaalde uitspraken doen door gebrekkige kennis, niemand weet alles binnen de IT wereld.

althans, zo komt het op mij over, en dat lijkt mij niet juist

Helaas is dat een aanname en kan ik je gerust stellen dat in de enterprise wereld, gezien de fundamentele werking van DNS, het een heel belangrijk onderdeel blijft. Niet alleen monitoren, ook het veiligstellen. DNS over een encrypted verbinding is daarom ook een zeer goede vooruitgang. Dat neemt de use case voor monitoring niet weg.
Met een correcte inrichting is dit overigens prima te combineren. Menig reverse proxy en/of CASB oplossing doen soortgelijke handelingen. Mocht je vinden dat http(s) verkeer (ook) niet gemonitored/geinspecteerd moet worden wil ik graag de discussie daarover met je aan gaan

Met een correcte inrichting is dit overigens prima te combineren. Menig reverse proxy en/of CASB oplossing doen soortgelijke handelingen. Mocht je vinden dat http(s) verkeer (ook) niet gemonitored/geinspecteerd moet worden wil ik graag de discussie daarover met je aan gaan

Binnen een zakelijke omgeving is er op zich weinig mis met automatisch monitoren op malware usw. zolang verantwoordelijke medewerkers maar niet carte blanche inzage krijgen in alles wat andere medewerkers doen. (Valt onder privè gebruik van zakelijk internet, waar geloof ik nog steeds privacy-waarborgen op horen te zitten.)

Waar ik wel absoluut een godvergeten rothekel aan heb, is wanneer dit soort monitoring je request of response aanpast.

ESET's live monitoring doet dit bijvoorbeeld. Alles wat met Gzip of Brotli gecomprimeerd binnenkomt, decomprimeren ze uiteraard om het te monitoren. Maar daarna sturen ze dus ook hun aangepaste gedecompromieerde resultaat door, ipv het origineel. Dat nekt bijv. de Google Lighthouse performance measurement tooling in de Chrome developer tools. Alles licht rood op, omdat je overal 'vergeten bent' compressie aan te zetten.

[Reactie gewijzigd door R4gnax op 14 mei 2020 17:34]

CylanceOPTICS gaat daar wat beter mee om

Onderzoek als het kalf al verdronken is kan uitermate nuttig zijn, als je daarmee kan voorkomen dat binnen de kortste keren de hele veestapel in de sloot ligt. Goede beveiliging van een netwerk houdt niet alleen een strenge toegangscontrole bij de voordeur in, maar ook controle op wat er binnen gebeurd. En DNS verteld best veel over het gedrag van een aangesloten systeem, en kan vaak ook inzicht geven of er bepaalde malware geïnstalleerd is. Enkel DNS-monitoring gebruiken is natuurlijk geen oplossing, maar een totaaloplossing zonder DNS-monitoring kan een blinde hoek opleveren.

Het voorkomen dat de veestapel in de sloot duikt hoor je m.i. te doen met proactieve security awareness.

Als je bang bent dat jouw hele bedrijf op een phising mailtje gaat klikken, zou ik daar beginnen (en zeker niet met DNS logging).

Een blinde hoek zonder DNS-logging, wellicht. Het ligt eraan welke maatregelen nog meer toegepast worden en hoe die in balans zijn met DNS-logging. Als het (door de andere maatregelen) niet zo effectief meer kan zijn, dan zou ik eerder overwegen om niet te loggen. Alle informatie die je opslaat vormt gelijktijdig weer een nieuw risico, waarvoor potentieel nieuwe maatregelen nodig zijn.

Overigens, blinde hoeken blijf je altijd houden. Informatie beveiliging zal altijd een kat en muis spel blijven.

[Reactie gewijzigd door EnigmA-X op 14 mei 2020 11:48]

Het voorkomen dat de veestapel in de sloot duikt hoor je m.i. te doen met proactieve security awareness.

Ah, security awareness. Dat klinkt heel erg mooi, maar met alleen awareness kom je er natuurlijk niet. Naast dat het nut van awareness ophoudt als een machine in het interne netwerk al geïnfecteerd is, dan is de prioriteit om dat te weten. Bijvoorbeeld door het netwerkgedrag van aangesloten machines in de gaten te houden.

Als je bang bent dat jouw hele bedrijf op een phising mailtje gaat klikken, zou ik daar beginnen (en zeker niet met DNS logging).

Dat is een drogreden. Je moet eerst a doen voordat je aan b begint, werkt alleen als a een vereiste is voor b. In dit geval werken beiden onafhankelijk van elkaar. Je moet er én voor zorgen dat mensen weten dat ze niet op rare linkjes moeten klikken, én je moet er voor zorgen dat je kan meten dat mensen niet op rare linkjes klikken. Beiden zullen niet waterdicht zijn, maar kunnen mogelijk (naast verdere maatregelen) elkaars blinde vlekken afdekken.

[Reactie gewijzigd door dcm360 op 14 mei 2020 11:57]

Dit is precies wat ik zeg, maar met de nuance op security awareness welke minstens net zo belangrijk is (maar totaal onderbelicht blijft).

De indruk in dit draadje ontstaat nu dat de informatie beveiliging overboord dreigt te gaan door DoH en DNS logging de heilige graal is en dat top prioriteit zou moeten hebben. Ik vind die gedachtengang totaal verkeerd. Als je goed bezig bent met informatie beveiliging, ben je op veel gebieden en op verschillende lagen bezig en is het prima mogelijk om passende maatregelen voor DoH te treffen (in plaats van als een kudde te gaan blaten dat DNS logging zo verschrikkelijk heilig is).

Dat is toch een ruim genuanceerder verhaal dan:

Eerlijk gezegd vind ik dit een vrij enge uitspraak. Ik zou niet weten waarom je DNS verzoeken gemonitord zou willen hebben, ook niet "met de beste bedoelingen".

Hierin ontbreekt daadwerkelijk elke nuance. Die nuance probeer ik met mijn reacties toe te voegen.

Overigens ben ik wel benieuwd naar de passende maatregelen voor DoH Het punt is namelijk, dat monitoring (niet strikt noodzakelijk hetzelfde als logging) van DNS-verkeer een toevoeging is aan het totaalplaatje, en dat DoH die mogelijkheden lijkt te ontnemen. Mocht je vinden dat ik met de kudde aan het meeblaten ben is de discussie overigens wel klaar en mag je eerst uit je ivoren toren komen.

[Reactie gewijzigd door dcm360 op 14 mei 2020 12:10]

Dat is toch een ruim genuanceerder verhaal dan:

[...]

Hierin ontbreekt daadwerkelijk elke nuance. Die nuance probeer ik met mijn reacties toe te voegen.

Overigens ben ik wel benieuwd naar de passende maatregelen voor DoH Het punt is namelijk, dat monitoring (niet strikt noodzakelijk hetzelfde als logging) van DNS-verkeer een toevoeging is aan het totaalplaatje, en dat DoH die mogelijkheden lijkt te ontnemen. Mocht je vinden dat ik met de kudde aan het meeblaten ben is de discussie overigens wel klaar en mag je eerst uit je ivoren toren komen.

Allereerst was die uitspraak in een andere context en niet aan jou gericht. Als je de alinea leest die ik daarboven schrijf, zie je weldegelijk dezelfde nuance als mijn vorige reactie.

Volgens mij zijn we allemaal gewoon betrokken en actief aan het discussiëren over een onderwerp. Als jij daarmee wilt stoppen omdat je denkt dat iemand een bepaald beeld van jou zou hebben, is dat uiteraard jouw keuze. Ik discussieer graag nog even met je door (voor de duidelijkheid).

[...]


Allereerst was die uitspraak in een andere context en niet aan jou gericht. Als je de alinea leest die ik daarboven schrijf, zie je weldegelijk dezelfde nuance als mijn vorige reactie.

Sorry, die nuance komt dan niet over. Dat het van origine niet aan mij gericht is, doet weinig af aan de vervolgdiscussie die je vervolgens wel met mij aan het houden bent.

Volgens mij zijn we allemaal gewoon betrokken en actief aan het discussiëren over een onderwerp. Als jij daarmee wilt stoppen omdat je denkt dat iemand een bepaald beeld van jou zou hebben, is dat uiteraard jouw keuze. Ik discussieer graag nog even met je door (voor de duidelijkheid).

In dat geval zie ik graag nog een inhoudelijk reactie op mijn stelling, en minder reactie op wat ik niet geschreven heb

Ok, dat kan

Als ik het goed begrijp ben je benieuwd naar mijn reactie op passende maatregelen voor DoH. Ik denk dat die niet anders zouden moeten zijn dan de maatregelen voor "normale" (lees: unencrypted) DNS-verkeer.

Dat gezegd hebbende, een maatregel neem je (na analyse) op een bepaald risico. In deze context ging het over phising. Als je dan tot de conclusie komt dat je DoH wilt beperken, in de zin van dat je alles via eigen DNS-infrastructuur wilt kunnen monitoren, dan zou je wat mij betreft aan deze maatregelen kunnen denken:

• DoH servers uitdelen via DHCP-optie
• Malware detectie tool verplicht installeren
• Bekende public DoH servers filteren in de firewall
• Conditional access tot belangrijke diensten (CRM,Office365, etc) via client certificates
• Belangrijke diensten die via publieke netwerken bereikbaar zijn verplicht voorzien van MFA
• Meer security awareness

Verder zou je als organisatie sowieso moeten overwegen, als BYOC een standaard is geworden, om voor bepaalde zaken werkplekken in de cloud in te richten, die wel goed manageable zijn.

Wij doen malware filtering op dns niveau. Dat is een hele effectieve manier om de meeste rommel buiten te houden of onwerkzaam te maken.

Als je DNS queries kan monitoren ..
Kun je voordat er iets gebeurd het al voorkomen.
Niet voor het nazoeken in logging, maar voor het proactief blokkeren

Op het moment dat er een query plaatsvindt voor het ophalen van een onbetrouwbare bestemming kun je deze al afvangen en hiermee problemen voorkomen.

En forceren naar je eigen DNS server ?
Er zijn genoeg manieren (bewust en onbewust) om je clients je eigen DNS server te laten omzeilen en zo schade aan te richten.
Waarbij het nu helemaal feest wordt als dit ook nog eens poortje 443 is
Ga je die ook blokkeren ?

Als je DNS queries kan monitoren ..
Kun je voordat er iets gebeurd het al voorkomen.
Niet voor het nazoeken in logging, maar voor het proactief blokkeren

Hoe kan je iets voorkomen, voordat je weet wat er gaat plaatsvinden? Je kan niet proactief blokkeren, zonder dat je weet wat je moet blokkeren. Zoals gezegd, phising is een heel dynamisch iets, niet alle verzoeken gaan naar *.phising.com

Proactief blokkeren - ook wel filteren - kan dus alleen maar je weet wat je wilt voorkomen. Met monitoring alleen leer je dat niet.

Op het moment dat er een query plaatsvindt voor het ophalen van een onbetrouwbare bestemming kun je deze al afvangen en hiermee problemen voorkomen.

Daar heb je dan een "blacklist" voor nodig (of "whitelist") en dan is het dus filteren, niet alleen DNS queries monitoren.

En forceren naar je eigen DNS server ?
Er zijn genoeg manieren (bewust en onbewust) om je clients je eigen DNS server te laten omzeilen en zo schade aan te richten.
Waarbij het nu helemaal feest wordt als dit ook nog eens poortje 443 is
Ga je die ook blokkeren ?

Dat is exact wat ik bedoel en waarom monitoren van DNS-queries tamelijk nutteloos is. Filteren kan je doen, maar behalve poort 443 kan dat op zo'n beetje iedere andere poort. Malware die nog unencrypted port 53 gebruikt voor DNS (of dat uberhaupt gebruikt) is al vrij kansloos.

De gebruiker die bewust op zoek is naar "de gaatjes" houd je zelfs niet tegen met layer-7 inspection. Een normale kantoorgebruiker (lees: bij een normaal bedrijf >90%) maakt zich echt niet druk om IP's en nameservers, het moet gewoon werken. Onbewust onbekwaam is een risico, dus daarom lijkt mij het verwijzen naar je eigen DNS-server en het blokkeren van port 53 naar buiten goed voor die "onbewust onbekwame" groep die heeft zitten kutten en toch Google's DNS heeft weten in te stellen.

Nogmaals, heb het elders ook al genoemd, phishing houd je het beste tegen met security awareness. Zeker in deze tijd waar BYOC heel populair is, moeten organisaties zich zelf ook bewust worden van die risico's.

Daarnaast lijken client certificates mij ook een stuk effectiever (zodat het gebruik van gelekte gegevens beperkt wordt en niet half rusland binnen no-time in een mailbox rondhangt). Uiteraard hoort daar ook gewoon een nette MFA oplossing bij.

Persoonlijk vind ik dat er heel sterk gereageerd wordt op een relatief niet zo'n significant verschil in de hele keten. Ja, als je security awareness, client certificates, MFA, malware detectie, etc tot in de puntjes hebt ingericht, dan zou je hierover heel diep na kunnen gaan denken.

Tot die tijd kan je af met wat standaard maatregelen op dat gebied en je veel beter focussen op security awareness, client certificates, MFA en malware detectie. Ik denk dat we allemaal wel weten dat dit ongeveer 80-90% van de bedrijven dit niet goed is ingericht (en dan gaat "DNS monitoring" dus ook maar bar weinig helpen).

Sterker nog. Grote organisaties kunnen nu dus DoH binnen hun netwerk gebruiken en netjes op hun eigen DoH DNS-servers monitoren, wat mij handiger lijkt dan netwerkpakketjes te snuffelen.
Ik kan me voorstellen dat ze niet blij zijn als applicaties als een internetverkenner zelf gaan DoH'en, maar als je echt strak wil monitoren, zal je dus zelf een https-proxy er tussen moeten zetten, die bijvoorbeeld transparant 'on-the-fly' certficaten genereerd voor alle domeinen die bezocht worden. (en dan heb je uiteraard je interne CA-certificaten netjes gedistribueerd)
Ditzelfde kan je uiteraard afdwingen voor BYOD-omgevingen in welke vorm dan ook.

Ik gebruik thuis als test een DoH-DNS-server, eerst in de vorm van dnscrypt-proxy, nu aan het testen met Adguard Home. Uiteraard slechts 'omdat het kan', en ik kan me voorstellen dat grote organisaties andere eisen hebben

"de rest van de wereld, die niet genieten van gemonitorde DNS verzoeken met de beste bedoelingen"

Los van een aantal geisoleerde gevallen vrees ik juist dat DoH voor meer problemen gaat zorgen dan het claimt op te lossen. Nu gebeuren DNS-verzoeken vrij decentraal. Elke provider heeft eigen DNS-servers staan. Als ik thuis online ga, gebruik ik een andere server dan zodra m'n telefoon overgaat op 4G bijv. DoH zorgt er juist voor dat alle DNS requests die een systeem doen altijd bij dezelfde partij terechtkomen. Vaak zijn dat ook nog commerciele partijen die geld verdienen aan data ipv aan een dienst.

Commerciele VPN-diensten zijn niet anders. Je kunt je afvragen of het wel zo verstandig is om al je dataverkeer via een enkele commerciele partij te laten verlopen. Bovendien zit je dan met heel veel andere gebruikers op hetzelfde netwerk wat weer andere security issues met zich meebrengt.

DoH is allang beschikbaar voor de paar mensen die er echt baat bij hebben. Het breed beschikbaar maken en in bepaalde gevallen ook nog standaard aanzetten voor nieuwe gebruikers (Firefox!) is een kwalijke zaak. DoH is niets anders dan een verdere centralisering van een wereldwijd web dat juist decentraal was opgezet en had moeten blijven.

[Reactie gewijzigd door Anoniem: 1330988 op 14 mei 2020 10:48]

Vaak zijn dat ook nog commerciele partijen die geld verdienen aan data ipv aan een dienst.

Dan gebruik je Quad9, die ook door Microsoft ondersteund wordt in deze testimplementatie. Dat is in ieder geval je eigen keuze.

[Reactie gewijzigd door The Zep Man op 14 mei 2020 10:59]

Grote organisaties die daar "afhankelijk" van zijn kunnen dit efficienter oplossen. Mocht jouw organisatie daar een van zijn stuur ik je graag een vrijblijvende offerte

Ik ben met name benieuwd naar BYOD waarbij er ingelogd moet worden op publieke netwerken (je weet wel, waarbij je even op OK moet klikken van de voorwaarden of een toegangscode moet intikken). Die werken doorgaans door de DNS query af te vangen en te replyen dat je naar de controller moet browsen om ergens op te klikken.

Nu zijn captive portals sowieso niet mijn favoriet, maar sommige organisaties willen daar niet omheen. En om dan gelijk op de plaatselijke DNS server de work-around (je kan op de DNS server een override configureren, een device met DoH zal dat domein regulier checken en op basis van de reply van de lokale DNS server DoH uit- danwel inschakelen) te configureren kost soms veel werk als je meerdere netwerken te beheren hebt plus dat je heel DoH maar uitschakelt omwille van de captive portal.

Wat gek dat Mozilla en in dit geval Microsoft niet kijken naar recursive DNS. Dat lijkt me een stukje anoniemer dan DoH.

Vanuit een Amerikaans perspectief snap ik het wel. Daar hebben ISPs daadwerkelijk een extra omzetstroom via de online advertentie markt. Als consument kan je niet opt-outen. Das gek en daarom is Mozilla DoH gaan bieden, wat inderdaad slechts voor versleuteling zorgt van consument tot (DoH) DNS provider. De enige die de pineut is, is je Amerikaanse ISP, maar je nieuwe DNS provider ziet alles wat je ISP eerst zag.
Voor de VS is dit juist geen enkel probleem want het lost dus het opt-out probleem op en dat was in elk geval het doel van Mozilla.

Maar om "de wereld" van meer privacy te voorzien bij DNS verzoeken ontkom je niet aan recursive DNS. Thuis op je server of NAS of RPi eenvoudig te regelen via Unbound+PiHole.

Inderdaad Pihole met een paar filters is niet genoeg veiligheid.
Wel als recursive DNS server instellen.
Zie https://docs.pi-hole.net/guides/unbound/ voor zij die het nog niet hebben.

Bedankt, zeer waardevolle link, erg duidelijk!

Dns-over-https zorgt ervoor dat dns-verkeer niet meer via de provider loopt, wat in theorie anoniemer zou zijn.

In principe zouden providers toch prima DNS over https kunnen bieden? Het verbaast mij eigenlijk dat niet juist providers hier op zijn ingesprongen voor ze het initiatief aan OS'en verliezen binnenkort. Het lijkt mij dat het niet moeilijk was geweest om ook DNS over https info in de modem/router op te slaan, je moet enkel een standaard zien af te spreken over hoe deze informatie over het netwerk wordt gedeeld.

De grote tech companies sluiten steeds verder de ISPs uit in de strijd voor data door encryptie overal doorheen te drukken. Aan de ene kant natuurlijk erg goed omdat er zo meer privacy is, aan de andere kant verstoort het wel weer de big data markt en dat is ook niet goed voor de consumenten uiteindelijk. Beetje kiezen tussen twee kwaden (waar ik dan toch neig voor privacy te gaan).

Het probleem is dat providers dan niet meer kunnen zien wat je doet. Dat heeft voor hen weinig voordelen, behalve dat ze misschien kunnen schermen met "kijk ons eens goed voor je privacy zijn". Tegelijkertijd hebben ze verplichtingen, zoals blokkades van illegale sites (zoals The Pirate Bay), dat gebeurt via dns. Dus dan wordt de vraag, waarom zouden ze?

Het probleem is dat providers dan niet meer kunnen zien wat je doet.

Als een provider zelf DoH aanbiedt kunnen ze prima zien wat de gebruiker bezoekt, en daarop gebaseerd blokkeren. Het is beveiliging tegen man-in-the-middle, niet man-at-the-end.

[Reactie gewijzigd door The Zep Man op 14 mei 2020 10:08]

Maar dan moet de gebruiker natuurlijk wel de DoH implementatie van de ISP willen gebruiken. En niet stiekem een andere gaan gebruiken.

Is dat heel anders dan als je nu een VPN zou gebruiken?

Lijkt mij niet.

Dat is waar maar de provider kan nog steeds zien welke sites er bezocht worden, niet dat zij daar baat bij hebben maar je maakt nog steeds een IP verbinding naar een server en die hebben allemaal reverse dns.

Tenzij de website op een gedeelte server staat. En de reverse DNS alleen maar de server naam van de hoster aangeeft en niet die van de website. Daarmee kun je niet effectief blokkeren.

Blokkeren kan altijd want je kunt het verkeer naar dat IP blokkeren. Bij shared hosting zouden ze idd niet zeker weten welke site je bezoekt maar er is wel achter te komen wat er allemaal op die host draait natuurlijk. Hoe het ook bekijkt...DoT of DoH is meer bedoeld om een man in the middle tegen te gaan dan om privacy redenen.

Denk jij nou echt dat als ik een DoH request doe naar Cloudfare, dat Cloudfare niet kan zien op hun server welke querie ik heb gedaan? De server is het encryptie endpoint en alles wat daarachter zit is gewoon zichtbaar. Of dacht je dat Tweakers niet in hun Apache log files kan zien welke IP adressen welke content opvragen omdat jullie https gebruiken?

Dat zeg ik toch nergens? Vanuit Cloudflare, een commerciële partij, vind ik dat ook logisch. Voor een isp is er minder reden het te implementeren.

Dat zeg je wel:

Het probleem is dat providers dan niet meer kunnen zien wat je doet.

Ze kunnen het prima zien als ze zelf DoH server zouden hebben, en ze zouden dan nog steeds hun wettelijke DNS blokkades kunnen doen, dus niet waarom zouden ze, maar waarom zouden ze niet?

En zoals je hieronder zet, in NL zijn ISP's absoluut geen nutsvoorziening. Dat ze als zodanig gebruikt worden door de consument laat onverlet dat het commerciele partijen zijn, net als Cloudfare of ISP's in de VS. Maar ze dienen zich uiteraard wel aan de AVG te houden. Stellen dat het nutsvoorzieningen zijn ipv commerciele partijen is je kop in het zand steken.

er zijn weinig niet commerciële ISP's :-)

In Nederland zijn isp's vooral een nutsvoorziening. Die geven het verkeer door, klaar.

In Nederland zijn isp's vooral een nutsvoorziening. Die geven het verkeer door, klaar.

Dus bijv. Ziggo is een niet-commerciële partij die geen overwegingen over investeringen; klant-tevredenheid; etc. hoeft te maken?

Mss. bedoel je eerder een B2B vs een B2C commerciële partij.

[Reactie gewijzigd door R4gnax op 14 mei 2020 13:11]

Nee uiteraard zijn ze wel commercieel, nutsbedrijf bedoel ik vooral als je het afzet tegenover Amerikaanse isp's.

Nee uiteraard zijn ze wel commercieel, nutsbedrijf bedoel ik vooral als je het afzet tegenover Amerikaanse isp's.

Dan bedoel je dus; een bedrijf wat zich aan wettelijke voorschriften inzake privacy van consumenten dient te houden vs een bedrijf wat dat niet hoeft (of voldoende poen heeft om simpelweg maling aan boetes te hebben).

Overigens heeft - ik dacht - Californië ook een soort AVG-light in het leven geroepen welke de verkoop van uit dit soort passieve monitoring verzamelde gegevens verbiedt of sterk aan banden legt.

[Reactie gewijzigd door R4gnax op 14 mei 2020 13:18]

Zoiets inderdaad. En heb ik even een mooi artikel voor je

Oh man; ook echt precies dezelfde term ook nog.

Voor communicatie gelden in Nederland strenge regels dat ze in principe niets met de inhoud van de communicatie van de klanten te maken hebben (naast wettelijke plichten zoals blokkades). Tenzij de klant er expliciet om vraagt om bepaalde gegevens voor een specifiek doel te verwerken, zoals extra beveiliging.
Het gaat dus niet alleen om commercieel zijn maar ook om wat een bedrijf wettelijk kan en moet.

Het probleem is dat providers dan niet meer kunnen zien wat je doet.

Volgens mij was dat precies wat je zei...

Nee, dat geloof ik niet.

@TijsZonderH gaf aan dat jouw ISP jouw DNS verkeer niet meer kan zien wanneer je DoH van een andere partij zoals Cloudflare gebruikt.

@TijsZonderH zei NIET dat Cloudflare het DNS request in dat geval zelf niet zou zien. Ook niet dat de ISP het niet zou kunnen zien (als ze het zelf zouden aanbieden en jij dat zou gebruiken). Hij stelde wel dat het weinig voordelen biedt voor de ISP.

[Reactie gewijzigd door EnigmA-X op 14 mei 2020 11:55]

Hij zegt:
Het probleem is dat providers dan niet meer kunnen zien wat je doet. Dat heeft voor hen weinig voordelen, behalve dat ze misschien kunnen schermen met "kijk ons eens goed voor je privacy zijn". Tegelijkertijd hebben ze verplichtingen, zoals blokkades van illegale sites (zoals The Pirate Bay), dat gebeurt via dns. Dus dan wordt de vraag, waarom zouden ze?

Dus: Het het heeft geen voordelen voor een provider om het te doen behalve als je wilt schermen met wij zijn goed voor de privacy. Dus waarom zouden ze.

Volgens mij zegt hij gewoon dat providers het niet meer kunnen zien als ze dat zouden invoeren, daarom doen ze het niet...

Waarom zouden Ziggo/KPN/T-Mobile etc gaan investeren in een DNS server. Dat levert hen niets op en kost alleen geld. Als er andere partijen zijn die die taak van hen wilt overnemen, zijn ze alleen maar blij.
Kans is groot dat de uptime van de DNS er nog beter wordt ook nog als het extern belegt wordt, dus vanuit hun oogpunt alleen maar voordelen.

Ze hebben al DNS servers. Iedere ISP biedt DNS aan haar gebruikers. Het is de meest essentiële dienstverlening die geboden kan worden naast de verbinding zelf, omdat je zonder domweg nergens komt. (als je niet toevallig een DNS server ingesteld hebt).

DoH is vooral in het leven geroepen omdat men als de dood is dat amerikaanse ISP's gegevens over hun gebruikers gaan doorverkopen. Iplv dat ze daar nou fatsoenlijke privacy wetgeving aannemen, zoals wij hier hebben, nee, er moeten draconische technische aanpassingen komen, die anders helemaal niet nodig waren geweest.

Als je privacy wilt, kun je thuis ook gewoon een caching nameserver neerzetten. Ziet vrijwel niemand wat je doet, tenzij ze heel doelgericht je lijn gaan sniffen. (wat ISP's hier niet doen uit zichzelf)

ISPs investeren in DNS-services. Dat doen de meeste ISPs al sinds ze bestaan. Redenen om dat te doen zijn niet alleen van commerciële betekenis. Het heeft ook te maken met service, stabiliteit, inzicht en wettelijke verplichtingen.
Je geeft bij je opmerkingen dat het beter zou worden verder ook geen sterke onderbouwing door te verwijzen naar extern beleggen. Extern beleggen zegt op zich alleen wie het uitvoert, dat staat los van de kwaliteit of beter worden.

Jammer dat het (weer) cloudflafre en Google zijn die in het lijstje staan.
Als ik al voor DoH zou kiezen, zou ik voor Quad9 gaan. Dat is de enige non-profit organisatie die op dit moment dus gebruikt kan worden. Die andere twee verzamelen al zo veel informatie van internet gebruikers, daar hoeft DNS verkeer niet nog eens bij te komen.
Encrypted of niet, logs kunnen ook geanalyseerd worden (timestamp X, browser met id Y, doet een DNS verzoek, in DNS server is te zien dat op timestampX+1ms zone Q is opgevraagd).

Ik snap heel goed dat er providers zijn die niet te vertrouwen zijn (zeker in landen met een totalitair beleid), maar ik vertrouw XS4All toch wat meer dan Google of Cloudflare....

In Amerika is DoH dan ook veel populairder. Hier zijn isp's een soort nutsvoorziening, maar in de VS mogen sommige providers je dataverkeer doorverkopen en dan wordt het veel aantrekkelijker om je queries via andere partijen te laten lopen - zelfs als dat Cloudflare of Google is. Nederlanders vertrouwen hun isp meer, in Amerika juist niet.

Dus is er voor een gebruiker in de USA weinig voordeel te halen.
Of je queries worden verkocht door je ISP, of door Cloudflare/Google. Als ik in de USA zou wonen, zou ik ze alledrie evenveel net zoveel vertrouwen als ik google nu doe (lees: Niet).

De enige die dus op dit moment interessant zou zijn om in de USA te gebruiken is Quad9. Dat is een non-profit organisatie die gesteund wordt door een aantal grote jongens (o.a. IBM, de PCA en de GCA). Van een dergelijke stichting zijn vaak de financien ook openbaar, dus zou het inzhctelijk moeten zijn of zij geld verdienen aan het doorverkopen van DoH data.

Cloudflare en Google verkopen je data niet op dezelfde manier door aan adverteerders zoals isp's dat doen.

Klopt. De ISP verkoopt de data aan derde partijen, Cloudflare en Google gebruiken de data (samen met alle andere data die ze van je hebben) om een profiel van je te bouwen, en dat profiel wordt gebruikt om een hogere prijs aan adverteerders te kunnen vragen (want groter profiel == meer relevante advertenties).

Verschil is dus dat bij een ISP de data wordt doorverkocht, waar Google en Cloudflare deze zelf houden. Maar de data wordt hoe dan ook gebruikt (of misbruikt zo je wilt) voor advertentiedoeleinden.

Ik meen gelezen te hebben dat, als je aangemerkt wil worden als publieke DoH server, je niets mag doen met die data.

Van cloudflare geloof ik dat ook wel (hun businessmodel is niet data verkopen).... google ben ik wat minder zeker over, die zouden zomaar een profiel kunnen bouwen. Daarom gebruik ik ook niet chrome, dat ding kletst mij te snel met 8.8.8.8, terwijl ik hier intern een prima nameserver heb.

En als de ISP's deze data verkopen is Google ongetwijfeld één van de afnemers.
Door DoH te stimuleren naar hun eigen servers kunnen ze daarmee een kostenpost schrappen. Slimme truuk a lá Scarface. (cutting the middle man)

Geeft inderdaad wel een beetje de zwakte aan van het systeem nu.

Of je gebruikt een beveiligde dienst van een commercieel bedrijf dat overzees gevestigd is, of je gebruikt een onbeveiligde dienst van een Nederlands bedrijf welke naar de Nederlanse wet moet luisteren.

Er zijn nog wel wat meer mogelijkheden (zoals al eerder genoemd zelf een DNS server gaan hosten, of een Pi-Hole gebruiken).
Je kunt ook andere (non-us-based) DNS servers gebruiken, hier een lijstje.

Heb het argument dat je het vertrouwen verplaatst nooit gesnapt: zonder encrypted DNS kan je provider zowiezo al zien welke quarries je maakt, net als de dns provider ze ziet. met encrypted DNS ziet alleen de dns provider het nog.

En daarna verbindt je alsnog naar ip 213.239.154.30 en kunnen ze, met een beetje goeie tool, alsnog zien waar je naartoe gaat


Non-authoritative answer:
Name: www.tweakers.net
Address: 213.239.154.30

Tja, encrypted dns is ook maar een onderdeel van de puzzel. eerst hebben we alle webtraffic versleuteld met HTTPS. Als volgt versleutelen we nu over de dns querries. En als laatste stap kunnen we ook encrypted SNI uitrollen. Hierdoor zou alleen het ip traffic zichtbaar blijven. Maar wetende hoeveel sites tegenwoordig hosting en ip addressen delen, zegt het vaak ook niet alles. Yes, encrypted DNS lost niet alles op, maar het is wel een belangrijke stap in het encrypten van het internet.

De plek waar de impementatie hoort te zijn, absoluut niet in de browser. Dit moet op systeemniveau geregeld worden. Het werken met voorgeschreven lijsten van DNS-servers gaat wel tegen het gedecentraliseerde principe van DNS in. Is er al een extensie aan DHCP om ook DoH-servers voor te schrijven aan clients? Uitendelijk moet dit nog steeds gewoon aan de netwerkbeheerder overgelaten worden. En in principe zou dat prima een DoH-server van de provider kunnen zijn. Dat ze daar in de VS wat meer moeite mee hebben snap ik maar ze zouden wel iets verder mogen kijken dan hun neus lang is - ik vertrouw mijn provider een stuk meer met mijn data dan Cloudflare of Google.

Yep, DHCP opties voor DoH in draft: https://tools.ietf.org/html/draft-peterson-doh-dhcp-00

[Reactie gewijzigd door EnigmA-X op 14 mei 2020 11:41]

Ik durf te beargumenteren dat mozilla's push er voorgezorgt heeft om de bal te laten rollen. encrypted dns had al jaren moeten gebeuren, maar er gebeurde absolut niets op OS gebied, Dus besloot mozilla het zelf maar te doen.

Bij dns-over-https worden, zoals de naam al voorspelt, dns-queries versleuteld. Normaal gesproken maakt een besturingssysteem gebruik van de dns-instellingen van het netwerk, wat de isp regelt bij individuele gebruikers. Dns-over-https zorgt ervoor dat dns-verkeer niet meer via de provider loopt, wat in theorie anoniemer zou zijn. De implementatie is echter controversieel: veel experts zeggen dat daarmee de privacy van gebruikers slechts wordt verplaatst naar een andere, commerciële partij.

Er is geen verschil tussen je DNS instellen op 1.1.1.1 en https://cloudflare-dns.com/dns-query. In beide gevallen gebruik je niet langer de DNS server van je provider. Grote verschil is dat met de eerste je provider gewoon kan meekijken door te snoopen op zijn netwerk en dan alsnog ziet welke DNS queries je uitvoert en je met de tweede doordat het encryptie gebruikt ook dat onmogelijk maakt.

Deze zogenaamde experts hebben dus geen punt hier, aangezien vele gebruikers als vanwege performance servers als 1.1.1.1 (Cloudfare) en 8.8.8.8 (Google) gebruiken.omdat ze vaak sneller zijn als de servers van de providers.

Zelf zal ik het niet zo snel gebruiken, niet op de client zelf dan: mijn clients krijgen via DHCP de DNS server op mijn Synology mee, ivm lokale hosts. Voor adressen die niet lokaal resolved kunnen worden gaat de Synology vervolgens naar AdGuard Home, die via DoH een request doet bij Cloudfare.

kun je op je modem van je provider instellen dat je via DOH gaat ipv via een IP adres?

Nee, meestal niet. Tenzij je een modem/router heeft wat DoH ondersteund. Het is namelijk geen IP adres maar een URL.

Wat ik niet zo goed begrijp. Hier mee gaat het juist toch makkelijker worden voor special interest partijen om DNS aan te bieden met een bepaald oogmerk. Dat commerciëlen partijen nu een eerste aanzet geven, betekent toch niet dat dit voor altijd zo moet zijn. Echter een innovatie moet er wel eerst door heen zijn. Voordat de techniek gebruikt kan worden.

Persoonlijk vind ik het wel een goed idee dat de partij die je het netwerk levert. Niet verplicht de partij is die je ook diensten levert als telefoon, TV, email of zelfs DNS. Laat maar lekker lostrekken van elkaar zodat je meer concurrentie krijgt.

Uit het oogpunt van beveiliging snijdt het HTTPS-mes aan twee kanten. Ongewenst meegluren wordt in elk geval lastig gemaakt. Maar dat geldt ook voor figuren met duistere bedoelingen; bijvoorbeeld het binnensmokkelen van malware wordt hiermee ook makkelijker... Dus of DoH brengt waarvoor het is bedoeld.....

Mooi dat het gewoon je huidige DNS server pakt en deze niet lijkt te overschrijven. Het zou helemaal mooi zijn als er bij de uiteindelijke release gewoon gekeken wordt of de DNS server die je ingesteld hebt ook DoH ondersteund en dat hij dan automatisch overschakelt in plaats van met een whitelist te werken.