NSA waarschuwt voor risico's van dns-over-https voor bedrijfsnetwerken

De Amerikaanse veiligheidsdienst NSA waarschuwt bedrijven voor het gebruik van dns-over-https. Volgens de NSA zitten er veel risico's aan DoH waardoor bedrijven de controle kunnen verliezen over hun dns-verkeer. De dienst raadt bedrijven aan daarom goed op te letten.

De National Security Agency waarschuwt voor de implementatie van dns-over-https in een bulletin aan het Amerikaanse bedrijfsleven. De veiligheidsdienst zet daarin de voor- en nadelen van DoH op een rij. "Nu versleutelde dns-verzoeken steeds populairder worden moeten netwerkbeheerders goed begrijpen hoe ze dat op hun eigen netwerken moeten implementeren", schrijft de dienst.

In het bulletin legt de NSA uit wat DoH is en wat de voordelen ervan zijn, maar een significant deel gaat over de mogelijke risico's. Zo waarschuwt de NSA voor een 'vals gevoel van veiligheid', de mogelijkheid om dns-monitoring te omzeilen en de gevaren van een verkeerde configuratie. "Hoewel dns-over-https goed voor meer privacy voor thuisgebruikers zorgt, kan het in enterprise-omgevingen risico's opleveren als het niet juist is geïmplementeerd", zegt de NSA. De dienst raadt bedrijven daarom aan goed te kijken naar die implementatie, zodat bedrijven alleen de resolver gebruiken van het bedrijf zelf.

De NSA zegt dat DoH op veel lokale apparaten makkelijk in te stellen is, maar dat steeds meer losse software of apparatuur ook van DoH gebruik maakt en dat beheerders daarop moeten letten door alternatieve resolvers uit te schakelen of te blokkeren.

Bij dns-over-https worden dns-verzoeken versleuteld. Dat is in theorie goed voor de privacy van gebruikers omdat bijvoorbeeld providers de verzoeken niet meer kunnen uitlezen, maar de verzoeken gaan in plaats daarvan juist langs commerciële partijen zoals Google of CloudFlare en leveren zo mogelijk juist meer privacyrisico's op. Steeds meer verschillende softwaremakers implementeren hun eigen versie van DoH, maar door al die verschillende implementaties is het moeilijk centraal toezicht te houden. Zo heeft Google in Chrome een andere implementatie dan Microsoft die het direct via het besturingssysteem regelt, en gebruikt Apple ook weer een eigen implementatie. Tweakers schreef in 2019 een uitgebreid achtergrondartikel over dns-over-https.

Reacties (82)

[dasiro]

als je er toch mee bezig bent als bedrijf, waarom zou je dan een externe DoH op je clients zetten ipv je eigen interne DNS er eerst tussen te steken? Op dit niveau ga je die toch zeker al hebben en dan nog kan je die eigen DNS als DoH instellen zodanig dat je nog controle hebt of heb ik het dan verkeerd voor ?

[The Zep Man]

Klopt. Als je als bedrijf niet goed (genoeg) je werkplekken beheert, zodanig dat je kan afdwingen hoe DNS gebruikt wordt, dan heb je grotere problemen dan DNS-over-HTTPS.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:05]

[Verwijderd]

Omdat bepaalde browsers (zoals FireFox) gewoon hun eigen ding doen betreft DoH. In de US staat DoH via CloudFlare gewoon default aan. En aangezien dit over HTTPS gaat, kan je dit niet zomaar filteren zonder de rest van de je HTTPS verkeer te impacteren. (IP-block is een mogelijkheid, maar ook omslachtig. Je kan moeilijk alle DoH providers gaan blacklisten).

In Europa staat dit default nog niet aan. Waarschijnlijk vanwege GDPR (Je mag niet zomaar die informatie naar een 3rd party zoals CloudFlare sturen zonder toestemming).

Klopt. Als je als bedrijf niet goed (genoeg) je werkplekken beheert, zodanig dat je kan afdwingen hoe DNS gebruikt wordt, dan heb je grotere problemen dan DNS-over-HTTPS.

Misschien moet je je eerst wat verdiepen in de problematiek, want dat is juist de grote kritiek op de beslissing van FireFox. Ze doen gewoon hun eigen ding en zetten de netwerk-admins buitenspel.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:05]

[kozue]

Je kunt natuurlijk over Firefox zeuren maar een implementatie op de manier zoals in Firefox kan natuurlijk door alle software gebruikt worden. Ook door software met slechte bedoelingen (en daar valt imho al die spyware van Google en Facebook ook onder). Via DoH kan iedere software eenvoudig langs een DNS blokkade komen en pihole-achtige constructies (of iets als OpenDNS met contentfilter) omzijlen. Daar ben ik zelf dus helemaal niet blij mee, de gedachte dat Google gewoon door kan blijven gaan met dataminen ondanks dat een flink deel van hun meuk hier op de DNS blacklist staat.
Firefox is een goed voorbeeld om bewustwording te creëren voor dit probleem. Niet alleen bij bedrijven maar ook bij privacybewuste thuisgebruikers die zich veilig voelen achter hun DNS filter. Hopelijk komen er makkelijke manieren om geheel van DoH af te komen zonder gelijk https helemaal dicht te moeten zetten (wat niet meer te doen is tegenwoordig).

[deadlock2k]

Je kunt natuurlijk over Firefox zeuren maar een implementatie op de manier zoals in Firefox kan natuurlijk door alle software gebruikt worden.

Ik snap je punt niet helemaal. DNS-resolving is simpelweg een OS-taak; van de netwerkstack en behoort gewoon niet bij client-applicaties te liggen tenzij die specifiek gemaakt zijn om te resolven zoals nslookup.

Daarnaast is de manier waarop de wijziging naar eindgebruikers gepusht is gewoon weinig transparant en het is nog maar de vraag hoeveel van de eindgebruikers daadwerkelijk snappen wat de implicatie is van iets als het DNS-beheer van je OS naar je browser over te geven.

En inderdaad, DoH bestaat maar om één reden en dat is het laatste stukje wat ze nog niet van je trackten nu wel te kunnen tracken.

[kozue]

Helemaal met je eens hoor. DNS hoort een OS taak te zijn. Maar mijn punt was juist dat software er door DoH voor kan kiezen om het OS buitenspel te zetten en zelf hun resolving te doen. Vooral software met slechte bedoelingen (zoals dataminers en advertisers) zal dat zo implementeren. Zet er een DoH client en een paar vaste IP adressen in en niemand die weet wat je achter hun rug om doet totdat ze netwerkverkeer gaan analyseren.

Ik ben dus persoonlijk van mening dat het bestaan van DoH de situatie alleen maar erger maakt voor onze privacy. Vooral van bedrijven zoals Google en Facebook die de infrastructuur hebben om alles zelf te regelen.

[deadlock2k]

Ja precies. En dan ook nog eens bakken met kaksmoezen van die grote jongens, recentelijk ook weer toen er aankondigingen gedaan werden door SURF omtrent DoH, maar ingaan op de essentie van het verhaal ho maar.

Begrijp me niet verkeerd, ik hou echt ontzettend veel van encryptie en ben ook zeker overtuigd van de nut en noodzaak ervan op een van de laatste protocollen waarbij er in de praktijk gewoon nog niets geregeld is en dat proef ik ook uit jouw reactie. Ik denk alleen dat het niet nodig is om overal altijd maar HTTP voor in te zetten met alle bijbehorende troep zoals cookies.

Dit is alleen wel een strijd die we niet gaan winnen. Maargoed, er hangt ook nog steeds een analoge ronddraaiende elektriciteitsmeter in de meterkast beneden, dus misschien kan ik ook hier wel gewoon de nukkige stijfkop blijven uithangen.

[bluewalk]

Voor veel applicaties die DoH gebruiken wordt de DNS van de DoH server gebruikt. Die zal dus eerst resolved moeten worden via de DNS resolvers die on je OS staan alvorens ze over HTTPS de query kunnen uitvoeren.

Voor PiHole is er een lijst met deze DoH DNS records om te blokkeren. Zo kan je al een boel DoH servers blokkeren, mits er natuurlijk hardcoded IP-adressen gebruikt worden zoals 1.1.1.1 van Cloudflare

[kozue]

Is dat nou juist niet dé manier die software zou gebruiken om langs DNS blokkades te komen? Hardcoded IP’s gebruiken?

Als DoH een volwaardige vervanging van klassieke DNS zou moeten zijn, zou je juist geen DNS nodig moeten hebben om je DoH server te vinden. Anders krijg je net zo’n halfbakken oplossing als SNI: via een onversleuteld request aangeven met welk domein je versleuteld wilt praten, zodat dat nog steeds getapt kan worden, ook al denk je veilig te zijn door overal HTTPS te gebruiken.

[bluewalk]

Eens, van de grotere providers zoals cloudflare zal het IP adres niet zomaar wijzigen. Van de kleinere is de kans wel groter, neemt niet weg dat het maar een halfbakken oplossing is.

Zo doen de nieuwe samsung tv's volgens mij ook zelfs DoH requests om zo het blokkeren van ads tegen te gaan (bv https://www.reddit.com/r/...lix_subverting_local_dns/)

[deadlock2k]

Voor veel applicaties die DoH gebruiken wordt de DNS van de DoH server gebruikt. Die zal dus eerst resolved moeten worden via de DNS resolvers die on je OS staan alvorens ze over HTTPS de query kunnen uitvoeren.

Hoe kom je erbij dat dat niet op IP-adres gaat net als bij normale DNS servers?

[markjanssen]

s/mits/tenzij/

[fantafriday]

Vergis je niet dat je via group policies voor applicaties als chrome en firefox gewoom settings kan afdwingen. Verder zijn er nog AV/Management cliënts die soortgelijke trucs hebben.

[Verwijderd]

Klopt, maar het is een stuk de omgekeerde wereld. Default zouden gewoon de instellingen van het OS moeten gebruikt worden. Als elke applicatie zijn eigen DNS-resolving gaat doen zijn we ver van huis.

Moeten system-admins dan policies gaan beginnen schrijven voor elke mogelijke applicatie?

[The Zep Man]

Moeten system-admins dan policies gaan beginnen schrijven voor elke mogelijke applicatie?

Voor iets zo complex als een browser? Ja.

[Verwijderd]

Voor iets triviaal als hostname-resolving? Nee.

Dit zou maar op 1 plaats moeten ingesteld worden, en applicaties zouden dit standaard moeten gebruiken. Kom, hier gaan we nu echt niet over zeveren. Hostname resolution is iets dat door een resolver dient te gebeuren die deel uitmaakt van je OS. En op een bedrijfsnetwerk wordt DNS resolving bepaald via 1 policy voor alle applicaties, geen 3.

Dat je gedrag van een browser fine-tuned via policies is normaal. Maar niet voor zaken die eigenlijk niet tot de kerntaken van een browser gebeuren.

Kijk, je hoeft me niet te geloven of zo, maar ga eens kijken hoe intern netwerk- en systeembeheer verloopt binnen een multinational organisatie met hoge security-eisen en die aan jaarlijkse audits onderworpen zijn(niet een KMO waar iedereen zijn eigen device op het bedrijfsnetwerk zet). Wat dat is het soort omgevingen waar het meestal in dit artikel over zal gaan.

Maar ja, je hebt gelijk. Wie ben ik om te zeggen wat ideaal is. Het is niet dat mijn 20 jaar ervaring als sysadmin bij zowel multinationals, banken, overheden, kmo's en startups mij enig inzicht hebben gegeven over wat werkt en wat niet? 1 van de DNS-founders, nl. Paul Vixie (developer van bind dns server) heeft zich ook al heel hard gekant tegen de beslissing van FireFox (en ook tegen DoH in het algemeen, maar dat even terzijde). Check zijn talk: https://www.youtube.com/watch?v=ZxTdEEuyxHU

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:05]

[dasiro]

ik kan me wel scenario's inbeelden waarbij je applicatiegebonden DNS-instellingen nodig hebt, bvb om bvb traffic naar je testomgeving te sturen zonder dat je heel de machine impacteert, maar uiteraard is default OS setting dan niet de enige optie die moet bestaan

[terror538]

Ik mag hopen dat je in een serieuze omgeving niet dezelfde names gebruikt voor productie als je test omgeving, en dat of je tegen test of prod aan het kletsen afhankelijk is van de nameservers die je instelt.

One off testen doe je normaal "gewoon" via je hosts file, voor (semi) vaste test omgevingen maak je gewoon een nieuwe hostname in je domein.

[dasiro]

uiteraard zijn er verschillende mogelijkheden, dit is er eentje van

[walteij]

Een goede testomgeving heeft een eigen domein en is gescheiden van de productie omgeving.
En bij voorkeur ook nog eens op een eigen hypervisor testomgeving en geen trust tussen de twee domeinen.

[wica]

Het probleem zit hem er in, dat elke applicatie zijn eigen DNS server kan kiezen.
Daar waar mallware of andere kwaad aardige software nog afhankelijk waren van de DNS die het system wist. Kunnen ze nu elke willekeuren domein met DoH server gebruiken. Poort 443 zal bijna nooit geblokkeerd worden.

[basfriends]

Is dat echt een probleem? Dynamic DNS even buiten beschouwing gelaten, DNS is toch niets meer dan een protocol om een human-readable adres om te zetten naar een TCP/IP adres? Niets staat software in de weg om via een andere route aan dat TCP/IP adres te komen. Ik begrijp in uberhaupt niet waarom bedrijven gebruikmaken van DNS blokkade achtige technieken.

De reden dat de NSA tegen DoH is is natuurlijk dat hun spytools dan niet meer werken.

[wica]

DNS is wel wat meer dan alleen domein.tld <-> IP('s)
Als je gebruik van van een TLD, heb je wereldwijde dekking, als in je kan het bij elke publieke DNS service, opvragen welke server(s) je kan benaderen met je vraag.
De DNS record is gemakkelijk aan te passen, zodat een domein die nu naar 1.1.1.1 verwijst, over een uur naar 1.2.3.4 kan verwijzen. Dus je mallware hoeft alleen maar een domein te weten ipv IP('s)

Ik begrijp in überhaupt niet waarom bedrijven gebruikmaken van DNS blokkade achtige technieken./

Het is verdomde hand op ransomware1234.com, te blokkeren om ransomware of andere vervelende dingen uit te schakelen.
Persoonlijk gebruik ik het in mijn network om o.a. bekende tracking/reclame urls te blokkeren, werk bijzonder effectief.
Bedrijven kunnen het o.a. gebruiken om te voorkomen, dat hun medewerkers naar niet gewenste websites gaan en dat software geen telemetrie kan versturen.

Maar ik heb ook een eigen DNS server draaien, om lokale dingen te hosten of werknemers intern naar een andere IP te sturen.

Door nu DNS over HTTPS (poort 443) te gaan versturen en elke programma zijn eigen DoH kan kiezen. En omdat het naar elk domein op poort 443 als gewoon HTTPS verkeer en met technieken als certificate pinning. Is het voor mij zo goed als onmogelijk om het DNS verkeer via mijn verbinding te reguleren.

De reden dat de NSA tegen DoH is is natuurlijk dat hun spytools dan niet meer werken.

Voor jun is het geen probleem zolang de grote DoH servers maar beheerd worden door Amerikaanse bedrijven of bedrijven die afhankelijk zijn van Amerika.

[GertMenkel]

Firefox doet zijn eigen ding niet als je policies instelt. Dan moet je dat wel doen, en daar kan dit een mooie wakeup call voor zijn, maar als bedrijf heb je als het goed is dat soort dingen al wel in de hand.

Ik heb zelf twee kritiekpunten op de beslissing van Mozilla, namelijk dat ze DoH boven DoT hebben verkozen en dat ze standaard de resolver van Cloudflare gebruiken in plaats van een open initiatief hiervoor te starten. Verder ben ik blij met de keuze om DoH uit te rollen, vanuit het oogpunt van de normale gebruiker is dit een behoorlijke verbetering voor zowel de privacy als de internetveiligheid.

Het "is gevaarlijk want netwerkbeheerders"-riedeltje hoorden we ook al toen TLS op begon te komen en ik vind het nog steeds geen goed argument. Als netwerkbeheerder hoor je via policies te voorkomen dat Firefox dit gedrag vertoont, of je zit in een BYOD-netwerk waar je als beheerder toch al geen grip meer hebt op het netwerk. Als DoH door je beveiliging heen komt, doen spyware en malware dat ook.

[Verwijderd]

Zie mijn opmerking hierboven. Applicaties zouden gewoon sane defaults moeten gebruiken, en dat doet FireFox hier niet (in de US).

Als morgen elke applicatie (Spotify, NetFlix, whatever...) zijn eigen DNS resolving gaat doen, en met policies moet uitgeschakeld worden, dan kunnen sys-admins hun dagen vullen om het internet af te schuimen welke policy ze nu vandaag weer moeten schrijven.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:05]

[GertMenkel]

Ik vind DoH wel een redelijke sane default voor het overgrote deel van de gebruikers eigenlijk. Vergeet niet dat Amerikaanse ISPs DNS-informatie gebruiken voor advertenties of zelfs doorverkopen. In Nederland hebben we gelukkig geen last van die onzin, maar voor Amerika vind ik het een verstandige keus.

Applicaties halen toch al hun spul van Amazon buckets dus ik weet niet wat je ermee wint om Spotify en Netflix op zo'n manier te willen blokkeren.

Ik erger me overigens kapot aan Electron-applicaties die niet in staat lijken te zijn om de certificaatopslag van het systeem waar ze op draaien te gebruiken, maar ik vind dat er een verschil is tussen een browser die zoiets implementeert en een applicatie die dit doet. Momenteel zijn er drie applicaties, namelijk Firefox, Chrome en Windows (waarbij zowel Chrome als Windows proberen DoH op de ingestelde DNS uit te voeren en anders de functie uitzetten) en ik heb nog geen bewijs gezien dat andere applicaties dat ook doen. Doen ze het wel, dan zet je ze gewoon niet in de whitelist van je bedrijf of gooi je ze van je eigen apparaat af, welke optie je dan ook beter ligt.

[Verwijderd]

Tja, daar verschillen we van mening. Ik heb jaren sys-admin werk gedaan in omgevingen waar security belangrijk was (bank-omgevingen etc..), en het is logisch om dezelfde taak (DNS in dit geval), op 1 plaats te managen dan op 3 verschillende. Het is onnodige duplicatie van werk.

Als je ooit zelf in zo'n omgeving hebt gewerkt, dan zal je wel snappen waarom.

[GertMenkel]

Ik begrijp zeker dat het onhandig is, maar in zulke omgevingen werkt men als het goed is toch met een whitelist van applicaties? Ik denk niet dat ik de Netflixapp op de werkcomputers van mijn verzekeringsbankiers zou durven toelaten als ik daar over zou gaan.

Het ding is, HTTPS gebruiken voor het omzeilen van de instellingen van systeembeheerders is niet bepaald nieuw. Waarom zou je malware via DNS naar zijn C&C laten praten, als je ook gewoon een Amazon-bucket die systeembeheer onmogelijk kan blokkeren kan gebruiken om je IP's in op te slaan? Als je namelijk S3 blokkeert, kun je net zo goed het internet helemaal afsluiten.

Het ding is, de echte gevaarlijke hackers voor banken etc. hebben natuurlijk al lang door dat DNS wordt gemonitord. DNS-management vind ik maar schijnveiligheid omdat het protocol nooit bedoeld is geweest om veiligheid te bieden. Het voelt een beetje als een camerasysteem en een metaaldetector bij je voordeur plaatsen om dan vervolgens de garage niet op slot te doen.

Juist in situaties als banken zou ik verwachten dat er wordt gewerkt door middel van een ingestelde proxy die het webverkeer inspecteert en monitort. De verkrijgbare man in the middle boxes zijn daar eigenlijk voor gebouwd. Je krijgt daar problemen mee als je ze transparant probeert te gebruiken, maar met expliciete proxy-settings van systeembeheer zal iedere normale applicatie en browser op Windows standaard al het verkeer daar doorheen proberen te duwen. Ook doet de proxy dan de DNS-lookup, wat dit probleem teniet doet. Het overige verkeer gericht aan poort 443 en 80 kun je dan direct markeren als verdacht en onderzoeken.

[Z80]

Welke verbeteringen zijn er dan voor een gebruiker binnen de EU?
Privacy? Nu komen de dns aanvragen bij de isp. Waar gaan deze in jou ogen dan uitkomen? En waarom bied dat meer privacy? Want ik neem aan dat je het protocol kent, en weet dat je een gebruiker met DoH perfect kan volgen ongeacht of deze achter een nat zit of van netwerk wisselt.
Internetveiligheid? Op welke manier wordt internet veiliger met versleutelde dns aanvragen?

[GertMenkel]

Man in the middle attacks op DNS zijn triviaal, op DoH zijn ze nagenoeg onmogelijk. Zodra je DNS hebt op een netwerk, heb je waarschijnlijk ook de mogelijkheid om via WPAD te klooien en vanaf daar wordt het alleen maar gevaarlijker. Dat is al een goed voorbeeld van die veiligheid.

Op Nederlandse universiteiten worden DNS requests gefilterd en verwerkt (heb ik gemerkt toen SURF me blockte terwijl ik onderzoek deed naar de veiligheid van applicaties), dus daar heb je al een privacyverbetering.

Ook hoeft mijn ISP niet te zien wat er in mijn DNS-verkeer gebeurt, daar heb ik mijn eigen DNS voor. Ik vertrouw T-Mobile niet zo als het aankomt op dingen als netneutraliteit, dus ik wil niet dat ze mijn DNS onderscheppen en/of loggen. De enige die mijn volledige IP te hoeven zien zijn ik en de DNS resolver (en via eDNS wordt een subnet doorgestuurd natuurlijk, maar daar kan ik weinig aan doen).

Je kunt bij DoH prima een gebruiker herkennen, maar je kunt niet zien welke pornowebsites hij opent. De volgende stap, waar ook al mee wordt geëxperimenteerd, is het versleutelen van de SNI voor HTTPS-verbindingen, waardoor gebruikers tracken zonder MitM-attack onmogelijk wordt gemaakt. Ook daarover zullen systeembeheerders in rep en roer zijn, maar ik kan zelf niet wachten tot het eindelijk de norm wordt.

[Z80]

Het veilig houden van je eigen netwerk als bedrijf of universiteit door dns filtering toe te passen is dus een privacy probleem. In mijn ogen meer een beveiligingsuitdaging.

En een isp mag geen dpi uitvoeren. En al helemaal geen onderscheid maken tussen de verschillende sites. Dit is iets dat je zelf kunt controleren/meten. Wat ook gedaan wordt door onderzoekers.

Als je in staat bent om de dns aanvragen van iemand te zien kun je ook zien waarnaar deze vervolgens heen gaat. Dus je ziet niet meer de naam, maar nog wel welke ip. Dus de firewall van de universiteit ziet nog steeds dat je naar een porno site gaat.

Ik blijf er bij . DoH geeft hier in Europa totaal geen extra veiligheid of privacy.

[tweaknico]

Door middel van TCP voorkom je de issues zoals bij een DDOS Amplified DNS attack,
waarbij een 10voud aan antwoord verkeer kan worden gegenereerd door spoofed afzender adressen in de pakketten te zetten.
DoT of DoH zijn hierbij beiden effectief.

Met DoH kun je DNS queries verbergen tussen HTTP verkeer. Voor de EU iets minder een issue.
Al hoewel we hebben hier ook een ISP(=KPN) die DPI wou inzetten om whatsapp verkeer per bericht door te gaan belasten omdat de SMS inkomsten minder werden.

Dus het is dat de wetgeving de ISP's hier een beetje eerlijker houdt dan in de VS.

[rene_fb]

(IP-block is een mogelijkheid, maar ook omslachtig. Je kan moeilijk alle DoH providers gaan blacklisten).

Puur uit interesse... Waarom is dat geen oplossing?

[Verwijderd]

IP ranges veranderen, providers verdwijnen en er komen nieuwe in de plaats... let me rephrase: het is geen gemakkelijke oplossing.

[rene_fb]

Ik ga er even vanuit dat die os'en, browsers en andere zaken die DoH servers als vast op adres hebben ingebakken.
Die moet men met de juiste lijsten toch 'gewoon' kunnen filteren?
Of mis ik ergens iets?

[ToAoM]

En je moet alle IP adressen van alle DoH servers en DoH proxy servers weten. Anders weet je nog niet zeker of iemand alternatieve name servers gebruikt om bijvoorbeeld onopgemerkt van bepaalde domeinen spullen te halen of er juist heen te sturen. Je kan het verkeer niet onderscheiden van ander https verkeer. Da's nou juist de bedoeling.

En blanket *:443 blokkeren is ook niet heel practisch.

[monotype]

Inderdaad, het is een verschuiving van een essentiele systeem-faciliteit (DNS) naar een of meer individuele applicaties, en dit is fundamenteel onwenselijk:
- beheersbaarheid: elke applicatie heeft hiervoor weer eigen configuratiemogelijkheden
- meerdere verschillende implementaties voor hetzelfde vergroot de exposure voor bugs
- het vergroot de onzekerheid aan de kant van de gebruiker: is er wel/geen DNS over HTTPS in Firefox/Lynx/IE/Chrome/Thunderbird/Outlook/$random_app ?

Het is een beetje alsof elke applicatie z'n eigen HTTPS certificate store er op na zou houden, met incoherente policies welke certificaten er wel/niet in zitten, en incoherente update policies. Dat vergroot de veiligheid ook niet bepaald.

Als het op systeemniveau afgehandeld zou worden, met een system service die DNS services via klassieke DNS OF via een DNS over HTTPS zou leveren zou er niet zoveel aan de hand zijn. De system service API's voor DNS zijn al gewoon aanwezig. DNS over HTTPS hier aan toevoegen is geen rocket science, en het zou in een klap voor alle applicaties beschikbaar zijn en beheersbaar zijn.

Het op OS niveau afhandelen zou beter zijn, maar vereist fundamentelere keuzes....

[syl765]

Het vervelende van DoH is dat bijvoorbeeld browsers zelf al DoH gaan implementeren en hiermee je lokale DNS configuratie gewoon negeren. Het is ook niet mogelijk om dit verkeer te blokkeren, outbound voor poort 443 heb je ook nodig voor je web pagina's.
Er zijn heel veel mensen die roepen dat DoH niet de oplossing is voor het veilig maken van DNS, dat DNS encrypt moet gaan worden daar zijn ze het allemaal over eens, de methode die de grote jongens er doorheen drukken in de vorm van DoH is dit niet.

hier twee video's voor wat meer info!

https://www.youtube.com/watch?v=pjin3nv8jAo&t=2012s
https://www.youtube.com/watch?v=ZxTdEEuyxHU

[sjongenelen]

Ja, zeker met dns quic is ads stoppen ook echt lastig.

[GertMenkel]

Je kunt met een paar stappen van je pihole een DoH resolver maken, dan heb je het beste van beide werelden. Of je kunt DoH gewoon uitvinken, DNS zal de komende tien jaar nog wel blijven werken.

[sjongenelen]

Dat bedoel ik niet. Ik bedoel dat devices dat zelf kunnen omzeilen met dns quic.
Een truc om dns over https adblock te omzeilen (die jij beschrijft)

[GertMenkel]

Hopelijk gaat Firefox een soort detectie inbouwen zodra Windows ook DoH aanzet in de normale releases. Zo kan FF weer gebruik maken van de system resolver en kan DNS alsnog veilig.

Firefox was wel de eerste die grootschalig DoH uitrolde dus dat ze dan zelf de implementatie moeten bouwen, vind ik niet gek. Na Firefox volgden Google en Microsoft ook, dus het heeft wel een positief effect op de industrie gehad.

Als het goed is hoef je DoH niet te blokkeren, aangezien de instelling in Europa standaard niet aan gaat en je hem anders zelf ook uit kan zetten. Als je apparaten in een netwerk beheert, kun je het daarmee ook gewoon uitzetten via de policies.

[tweaknico]

Het probleem kan zijn dat als een browserbouwer (Google) die ook een advertentie netwerk beheert een eigen DNS server gaat gebruiken, dat een AD-blocker als pi-hole niet meer gaat werken,

Dat Firefox het doet is een ding, maar google heb ik dan net weer iets minder vertrouwen in.

[GertMenkel]

De implementatie die Google heeft voorgesteld en uitgevoerd, gebruikt niet de DNS-servers van Google (niet in Chrome in ieder geval), maar probeert DoH uit te voeren op de host die je systeem als normale DNS uitvoert. In dat opzicht is Chrome netter dan Firefox als het op instellingen aankomt.

Dit betekent dat je effectief geen automatische DoH hebt tot Ziggo en KPN hun DNS-servers DoH-ondersteuning geven.

Als je je pihole DoH geeft, heb je twee vliegen in een klap, versleutelde DNS en advertentieblokkades.

[johnkeates]

Zo waarschuwt de NSA voor een 'vals gevoel van veiligheid', de mogelijkheid om dns-monitoring te omzeilen en de gevaren van een verkeerde configuratie.

Tsja, als je je 'enterprise' netwerk als een fragiel speciaaltje inricht en je security afhangt van DNS monitoring op apparaten waar je geen invloed op hebt moet je die 90's mentaliteit uit het raam gooien en eens kijke naar zero-trust en gedragsanalyse. Het hopen dat je met het monitoren van DNS requests en web verkeer magisch alles wat stout is kan zien is een beetje een wassen neus die bij hetzelfde afval kan als systemen 'imagen' met een 'golden image'. Het is allemaal slechts een enkel meetpunt in de tijd dat helemaal niks zegt over voorgaand gedrag van een systeem en ook niks over toekomstig te verwachten gedrag. Daarnaast kan je met domain fronting en misbruik van legitieme systemen prima al je verkeer over 'whitelisted' kanalen laten lopen en dan heb je zelfs met al die oude 'waterdichte' monitoring gewoon nul voordeel.

[Vinales]

Sinds jaar en dag publiceren zij beveiligingsadviezen... onder andere https://apps.nsa.gov/iad/library/ia-guidance/security-tips/

[mutley69]

Het NSA heeft gelijk - wacht nog maar tot de malwaremakers dit feature gaan gebruiken. Iedereen zal weglopen van DoH - dit is een uitvinding uit de Hel.

[sn33ky]

Snap de redenering wel. Maar is raar dat algemeen bekend "spionagedienst" (of veiligheidsdienst) dit adviseert.

Dat je uw DNS verkeer in handen geeft van de bedrijven die deze DoH als dienst beschikbaar stellen is natuurlijk een risico, je geeft dat vertrouwen dan aan die selecte bedrijven.

Zou goed zijn als providers (standaard) DoH diensten leveren, en dit zelfs standaard in de geleverde modem inschakelen.
Maar daarmee vertrouw je dit weer toe aan de provider. Is dat dan beter?

Dus tja, wat is beter. uw eigen DoH server?

[Reactie gewijzigd door sn33ky op 22 juli 2024 16:05]

[aaahaaap]

Het hele DoH verhaal bestaat door de providers in Amerika. Het werkt iets anders daar dan hier waardoor providers daar het surfgedrag van hun users lekker kunnen verkopen.
Dit is ook gelijk 1 van de problemen met DoH, de hele wereld krijgt het weer opgedrongen omdat het in Amerika een zootje is

[Cyb]

Er wordt niet echt iets opgedrongen, DoH is gewoon een browser feature die je als optie aan/uit kan schakelen. Het probleem dat netwerkbeheerders er mee hebben, is dat het buiten hun zicht om gaat, waardoor organisatiegegevens gemakkelijker naar buiten kunnen lekken.
Het probleem dat providers in de VS er mee hebben, is inderdaad dat ze nu geen DNS query geschiedenis kunnen doorverkopen aan derden.

[Verwijderd]

FireFox zet het default aan in de US (of is het toch van plan).

Enige reden dat ze het in de EU niet doen, is vanwege GDPR.

[Cyb]

Daar in de VS staat het inderdaad standaard aan als zij de browser downloaden. Maar met een vinkje is het weer uit te zetten. Maar voor de thuisgebruiker is dat niet erg, mits je de DoH server meer vertrouwt dan de DNS server die anders ingesteld zou zijn. (Wat in de VS extra opletten is, vanwege de data die providers over je doorverkopen.) Dus thuisgebruikers in de VS zullen juist standaard meer baat hebben bij DoH dan de gemiddelde thuisgebruiker in NL, waar strengere privacy regels gelden voor providers.

[Verwijderd]

Zucht... Dat is een off-topic reactie want het artikel gaat hier niet over thuis-gebruikers, maar over bedrijfsnetwerken...

[zenlord]

Jij bent diegene die over sane defaults begint, dan mag @Cyb toch een argument aanhalen waarom de huidige Firefox defauls sane zijn, ook in de US?

[walteij]

Meh. Zoiets hoort (net als mailinglijsten) opt-in te zijn en niet opt-uit.

[ToAoM]

Je zou ook kunnen zeggen dat onveilige DNS opt-in moet zijn, want onveilig.

Dat we hiervoor niets beters hadden is een slechte reden om er niet hard van weg te hollen nu er werkende alternatieven zijn.

[Verwijderd]

wat is onveilige DNS volgens jou?

Ok, standaard dns is onveilig omdat het door je provider kan ingezien worden. Je DoH provider kan ook al je dns-data inkijken. Je dns data komt dus gewoon bij een andere partij terecht.

Elke keer stel ik dezelfde vraag, en kan niemand mij een deftig antwoord geven: Waarom ga je ervan uit dat die DoH providers beter gaan behandelen dan je internet provider? Je hebt een contract met je internet-provider, en als die jouw gegevens misbruikt kan je een rechtzaak starten. Je hebt geen contract met Mozilla, of CloudFlare, en sta je in geval van misbruik gewoon nergens.

[ToAoM]

Standaard kan ik als dns opvragen niet controleren dat het antwoord dat ik krijg komt van de partij die ik vertrouw. Dat is waardoor enterprises bijvoorbeeld alle DNS verkeer op elk IP adres naar hun server kunnen routen.

Dus man-in-the-middle is super easy en daarmee onveilig.

Met dns-sec kan je nog wat verbeteren, maar dat beschermt de domein houder, niet de ontvanger van de informatie.

[Verwijderd]

DNS-overTLS-(DoT) is ook beveiligd en kan dus niet gesnooped worden. Het draait echter op zijn eigen poort, en kan daardoor op netwerk-niveau vrij eenvoudig tegengehouden worden zonder ander verkeer te impacteren. DoT is daardoor een veel betere oplossing. Bedrijven kunnen dan nog altijd zelf DoT intern opzetten voor encryped-dns.

DoH mengt een network-control protocol (hostname resolution) met een applicatie-specifiek protocol (www). En dat is nooit een goede zaak, los van politieke voorkeur voor DoH.

[kodak]

Je kan niet zomaar stellen dat er niets zou worden opgedrongen als er sprake is van ontwikkelaars die voor gebruikers bepalen wat het beste is door opt-out te hanteren. Dat je als gebruiker ( of je nu een persoon bent of een organisatie ) te maken krijgt met opt-out is al een oorzaak van het probleem. Dat er een oplossing voor is ( je kan het toch uitzetten als ... ) wil niet zeggen dat er geen probleem is. En zelfs als het je om de term gaat, het probleem is er niet mee weg.

[Cyb]

Eens. In mijn reactie reageerde ik vooral op "de hele wereld krijgt het weer opgedrongen". In de VS wordt het bij Firefox inderdaad wel opgedrongen, ook al is het mogelijk in het voordeel van de gebruiker kwa privacy (indien de default Firefox DoH server beter is). Ze zouden het eigenlijk expliciet bij de installatie van Firefox het als een keuze-optie moeten vragen. (Telemetry staat in Firefox overigens ook helaas standaard aan.)

[kodak]

Ik wil het eigenlijk niet over een specifiek product hebben omdat het er naar mijn mening gaat over het risico van DoH en niet over een risico bij een specifiek product. Maar het is wel een voorbeeld van een hoe iets een risico is bij deze waarschuwing.

De oplossing lijkt me daarbij prima passen bij ieder product dat DoH mogelijk maakt. Ongeacht of het nu een gebruiker is of een bedrijf is dat er mee te maken krijgt. Misschien hadden dit soort risico's zelfs wel eerder algemeen erkend geweest als dat eerder werd gedaan. Bijvoorbeeld ook bij DNS.

[massareal]

Maar is raar dat een spionagedienst veiligheidsdienst dit adviseert.

Tuurlijk doen ze ook aan spionage, maar zoals altijd; staat veiligheid voorop!

[ralph1212]

Grappig dat de NSA kritiek heeft op versleutelde communicatie systemen.

[-DEVON-]

Ik snap je gevoel. Maar anderzijds, het klopt wel. Je raakt als beheerder een stukje controle kwijt. Even los gezien van het feit of dat gewenst is of niet.

[ralph1212]

Klopt, aan de correctheid van de waarschuwing en de technische aspecten twijfel ik ook niet.
Ik vond het echter komisch dat nu juist de NSA een soort kritiek heeft op dit protocol.

[Verwijderd]

Ze hebben geen kritiek op het protocol ansich.
Bovendien is het de taak van de NSA om dit soort dingen te doen.

[Cyb]

Ze hebben juist wel kritiek op het protocol. Maar dat is ook niet raar, elke veiligheidsdienst heeft een hekel aan DoH als het gaat om binnenlandse veiligheid. Met DoH kan er gemakkelijker buiten het zicht van netwerkbeheerders, informatie lekken naar buiten.

[Verwijderd]

Nee, ze geven het advies aan bedrijven om het goed te implementeren.

[Cyb]

Ze zeggen het inderdaad niet letterlijk, maar het probleem is dat het niet goed te implementeren is. Het zijn allemaal suboptimale oplossingen, zoals blacklisting van DoH servers of OS restricties.

[Verwijderd]

Klopt 👍🏻
Btw, goed icon

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:05]

[unfold]

Dit is hun redenering:

When a client has DoH enabled and configured to use a DoH resolver not designated by the enterprise,
the DoH traffic will be sent directly to the enterprise gateway as HTTPS encrypted traffic over port 443, bypassing the enterprise DNS resolver entirely. The request will then go to the client-selected DoH resolver, which will either return the response or pass it along to the authoritative servers to resolve the request

Je kunt nu zeggen "DNS verkeer op poort X mag alleen naar server Y op ons eigen netwerk". DNS over https maakt dat lastiger, want je kunt het DNS verkeer en het andere https verkeer (bijvoorbeeld de website die je download) niet zo makkelijk onderscheiden. Want het gebruikt nu allemaal diezelfde poort.

Prima. Maar voor de gemiddelde consument is dit 'risico' totaal niet relevant.

Ik verbaas me dan ook enorm over hoeveel content er wordt gepusht die onder de rubriek "pas op met encrypted DNS" valt.

De NSA heeft enorm veel belang bij het ontmoedigen van encrypted DNS gebruik, want het huidige un-encrypted DNS systeem is voor hen een goudmijn. Wat mij betreft zou de media iets minder snel deze berichten mogen overnemen, en wat meer de nadruk leggen op de schandelijke en schadelijke situatie dat ons DNS verkeer anno 2021 nog steeds niet encrypted is. Dat is wat mij betreft het grote plaatje.

[Verwijderd]

Maar voor de gemiddelde consument is dit 'risico' totaal niet relevant.

Irrelevant. Het artikel gaat hier over enterprise-netwerken, niet over thuis-gebruik. Totaal andere use-case.

De NSA heeft enorm veel belang bij het ontmoedigen van encrypted DNS gebruik, want het huidige un-encrypted DNS systeem is voor hen een goudmijn.

Ook irrelevant. Er zijn beveiligde DNS alternatieven die makkelijker te controleren zijn op je bedrijfsnetwerk (DNS-over-TLS, wat over zijn eigen poort draait).

Sorry, maar je alluminium-hoedje denken is in de context van dit artikel over bedrijfsnetwerken totaal niet van toepassing.

[unfold]

Je hebt grotendeels gelijk, het staat zelfs in de titel inderdaad.

Op andere tech-nieuws websites zie ik al een tijdje vooral berichtgeving over de gevaren van encrypted DNS (vooral in het VK), en te zelden over het belang om het uberhaupt te encrypten. Dat leidde tot mijn "alweer dit narratief" reactie, maar die is in dit geval inderdaad niet geheel terecht.

Er zijn beveiligde DNS alternatieven die makkelijker te controleren zijn op je bedrijfsnetwerk (DNS-over-TLS, wat over zijn eigen poort draait).

Het artikel had dus ook "NSA raadt DNS-over-TLS aan voor bedrijfsnetwerken" kunnen heten. Het is maar hoe je het framed, en ik zie dus vooral veel artikelen waarom encrypted DNS negatief wordt geframed. Dat is het punt dat ik probeerde te maken.

Hoewel mijn stelling niet 100% on-topic is, is "aluhoedje" onnodig. Mijn stelling is niet gek of onwaar, dus laten we het op de man spelen alsjeblieft achterwege laten.

[PFY]

Volgens mij gaat het meeste verkeer van bedrijven over http proxies. Die slaan dan ook gewoon op waar een gebruiker heengaat. Dan kan je misschien niet de dns uitlezen, maar wel het http request en dat laat gewoon zien waar het verkeer heengaat.

[The Zep Man]

Wat weinig nut heeft als op 1 IP 10.000 sites draaien.

[Mushroomician]

De hostname is met SNI is altijd al leesbaar in de TLS-handshake.
_{Voorbeeld: https://i.stack.imgur.com/e3yw1.png}

[The Zep Man]

Niet met Encrypted Server Name Indication.

[Mushroomician]

1337

[zyphr]

Met de evaring van de afgelopen weken...
De de-platforming van parler etc, lijkt me dit nog een mooie toevoeging.
Dit zodat alle dns requests via Google/Apple/Facebook/etc lopen