Dns-over-https: vloek of zegen?

Meningen verdeeld over encryptie dns-queries

Kritiek en regulering

Privacy, encryptie, versleuteling: het klinkt allemaal prettig, die anonimiteit, maar daartegenover staan ook nadelen. Dns-over-https kan bijvoorbeeld problemen opleveren voor veel bedrijven die hun eigen bedrijfsnetwerken hebben. Daarnaast helpt het dns-protocol gebruikers door verbinding te maken met de dichtsbijzijnde of in ieder geval de snelste server in de buurt. Met dns-over-https wordt dat ook een stuk moeilijker.

Bedrijfsnetwerken

Veel kritiek op dns-over-https komt uit de bedrijfshoek. Veel bedrijven gebruiken een eigen dns-resolver, bijvoorbeeld om contentblokkades op te zetten. Als een bedrijf een vpn opzet, krijgt het daar automatisch een eigen nameserver bij. In zulke gevallen is dns-over-https geen uitkomst, integendeel. Daarmee worden gecentraliseerde dns-instellingen gepasseerd en kunnen werknemers gemakkelijker om zulke blokkades heen. Dan is er nog het feit dat dns-queries vaak worden gebruikt om te scannen op malware. Als die standaard worden versleuteld, hebben systeembeveiligers een probleem.

Dat geeft hen een paar opties die geen van alle ideaal zijn. Https-verkeer blokkeren is geen optie, dus moeten ze de DoH-functie die voortaan standaard in browsers zit, uitschakelen. Ga er in een byod-omgeving maar aan staan. Een update van een browserversie in zijn geheel blokkeren is wel een optie, maar niet voor eeuwig. Om die reden is de implementatie die Google heeft bedacht, waarbij DoH alleen wordt geïmplementeerd als er geen andere instellingen zijn die daarboven staan, een redelijke tussenweg. Als een bedrijf een eigen resolver heeft, wordt die niet overschreven door het ingebouwde DoH-protocol.

Malware

Dns wordt gebruikt om te scannen op malwareNiet alleen maakt dns over https het moeilijker om malware te blokkeren, er is inmiddels ook al malware gespot die juist misbruik maakt van het nieuwe protocol. In juli ontdekten onderzoekers van Qihoo 360 dat de Godlua-malware was bijgewerkt en dns-over-https misbruikt om malwarescanners te omzeilen. Dat doet de malware door dns-queries naar de command-and-controlserver te versleutelen, waardoor het moeilijker wordt om die te spotten. Op dit moment zijn er nog niet veel van dergelijke gevallen van malware bekend. Ook om deze reden zijn er veel beveiligingsexperts die pleiten voor dns-over-tls in plaats van dns-over-https. Het DoT-protocol is zoals eerder gezegd veel gemakkelijker te blokkeren.

Boven alle praktische bezwaren heerst een wat abstractere discussie over ethiek en vrijheid. Dns is nu nog een grotendeels gedecentraliseerd protocol. Versleutelde dns-verbindingen lopen echter via een handjevol grote providers, met Google, Cloudflare en Quad9 voorop. Daarmee wordt dns steeds gecentraliseerder en je kunt je afvragen of dat een goede zaak is. CloudFlare is er op dit moment duidelijk over dat het geen gebruikersdata verkoopt, maar blijft dat zo nu het bedrijf aan de beurs genoteerd is? En zelfs als het bedrijf ethisch blijft handelen, is een single point of failure nog steeds geen goed idee. Wie daarvoor verder bewijs nodig heeft, hoeft alleen maar naar de storing van afgelopen juli te kijken.

Het begrip encryptie heeft bij de meeste gebruikers een goed imago. Encryptie betekent dat niemand kan meelezen met wat je schrijft, toch? In het geval van dns-over-https betekent het echter niet dat je verkeer compleet anoniem wordt. Je provider ziet er minder door, maar de dns-resolver, zoals Google of Cloudflare, ziet juist méér. Het probleem wordt dan verplaatst. Bovendien komen dns-queries in een dergelijk geval te liggen bij een commerciële partij, die doorgaans een stuk minder wordt gereguleerd dan een provider.

Overheidsregulering

Zeg je encryptie, dan zijn er altijd mensen die gaan steigeren. Immers, de terroristen en kinderpornoverspreiders verschuilen zich erachter en daarom zou versleuteling slecht zijn. Het aloude argument doet ook in deze discussie weer opgeld. Nergens gebeurde dat heftiger dan in het Verenigd Koninkrijk. Daar hebben isp's strenge verplichtingen, zoals het beruchte pornofilter. Ook zijn belangen- en mensenrechtenorganisaties bang voor de implicaties. In het VK waarschuwde de Internet Watch Foundation bijvoorbeeld dat dns-over-https 'het gevecht tegen online kindermisbruik' zou bemoeilijken. In het land laaide de discussie zelfs zo hoog op dat het samenwerkingsverband van internetproviders, de Internet Service Providers Association, Mozilla nomineerde voor de prijs van 'internetschurk'. Hoewel de ISPA de nominatie uiteindelijk terugtrok, bleek de lobby wel degelijk succes te hebben. Mozilla kondigde onlangs aan dns-over-https niet in het VK in te schakelen.

Internetproviders willen dat de politiek DoH aan banden legtNiet geheel onverwacht komt de kritiek ook uit de commerciële hoek. Niet alleen Britse wetgevers én isp's zijn ontevreden met de plannen, ook in Amerika is er irritatie over. Een belangengroep van grote internetproviders in de VS schreef een brandbrief naar politici. Ze waren bang dat met name Google door de plannen zijn monopoliepositie zou versterken. Ook zou DoH in Chrome ertoe leiden dat 'kritieke internetfuncties' worden verstoord, zoals de eerder genoemde contentblokkering.

Op politiek vlak ligt DoH eveneens onder vuur. Regulering ligt op de loer. In het Amerikaanse congres ligt Google inmiddels weer onder een vergrootglas vanwege zorgen om oneerlijke concurrentie. Het bedrijf zou op deze manier alle internetverkeer naar zich toetrekken en de markt volledig consolideren.

Conclusie

Je zou zeggen dat dns-over-https een goede stap is voor de privacy van de doorsnee-internetgebruiker. ‘Het laatste stukje’ van een internetverbinding versleutelen terwijl dat jaren niet gebeurde, is op het eerste gezicht goed voor consumenten. Inmiddels blijken er echter heel wat haken en ogen aan het plan te zitten. Centralisatie van een van oudsher gedecentraliseerd protocol is een belangrijk bezwaar, maar belangrijker is dat vooral de implementatie nog veel te wensen overlaat. Interne bedrijfsnetwerken en beveiligingssoftware kunnen in de problemen komen als het protocol de standaard wordt, en je kunt je afvragen in hoeverre de technologie de gebruiker écht beschermt.

Reacties (234)

Een andere tweaker linkte hier ook al over in een eerder bericht over DoH maar ik wou hem even herhalen.

https://www.youtube.com/watch?v=AGbFrZD_pnE
Bert Hubert van PowerDNS over DoH. Goed kijkvoer voor geïnteresseerden.
Even doorspoelen naar ong. 02:24:00

Denk ik ook een van de inspiraties voor dit artikel als ik zo de volgorde en inhoud bekijk.

[Reactie gewijzigd door Audiodude op 14 oktober 2019 14:31]

Je bedoelde deze denk ik: https://www.youtube.com/watch?v=pjin3nv8jAo

Net als dat dit artikel een inspiratie is geweest: https://arstechnica.com/t...-them-from-spying-on-you/

Een belangrijk onderwerp. Ik ben bang dat we weer een beetje meer in de greep raken van big tech, en steeds verder afraken van het vrije internet zoals het ooit bedoeld was.

/Edit @TijsZonderH Vanzelfsprekend raadpleeg je goede bronnen voor de achtergrond van zo'n artikel! Mooi dat je deze expert ook hebt gesproken.

[Reactie gewijzigd door bas-r op 14 oktober 2019 11:18]

Dat artikel is inderdaad één van de stukken die ik gelezen heb. En ik heb Bert voor dit artikel ook lang gesproken waarin hij me erg goede uitleg gaf.

Is dezelfde... Alleen die van mij begint op 02:24:00 ongeveer.

Maar de jouwe is makkelijker. :-)

De volgende gevaren die ik zie met DoH, is DLP.

Bij gewone DNS heb je niet eens DLP nodig, daar kan je het gewoon al lezen.

Wat een top artikel. Meestal heb ik over dit onderwerp veel te vertellen maar hier kan ik weinig aan toe voegen. Ik ga het toch proberen

Ik wil wat extra aandacht vestigen op het feit dat DoH alléén werk o het stukje webbrowser <-> DNS-resolver. Vanaf de DNS-resolver gaat het weer onversleuteld verder via het traditionele DNS-protocol. Dat is niet fundamenteel, in theorie zouden DNS-servers onderling ook DoH kunnen spreken, maar wel de huidige praktijk.
Wie zowel het inkomende als het uitgaande verkeer van een DoH-resolver kan monitoren heeft nog steeds mogelijkheden om gebruikers aan DNS-queries te koppelen (bv op grond van timing).

Voor een deel kun je dat probleem oplossen door je te verstoppen in de drukte. Als er heel veel mensen tegelijk dezelfde DNS-server (DoH of traditioneel) bevragen wordt het moeilijker om te zien wie welke query heeft gedaan. Zeker als die server ook nog een cache heeft. Je kan je afvragen of je je verkeer beter kunt verstoppen bij de resolver van je lokale provider of die van een internationale dienstverlener als Google.

Een simpele oplossing voor een deel van deze problemen heet Query Name Minimization. DNS-resolvers doen hun werk in meerdere stappen. blog.voorbeeld.com zijn bv drie stappen. Eerst .com, dan voorbeeld.com en dan blog.voorbeeld.com. Traditioneel vraag je in iedere stap de hele naam van de eindbestemming. Alle DNS-servers zien dan welke eindbestemming je zoekt. Met QNAME Minimization vraag je alleen om het volgende stukje dat je nodig hebt, niet de hele naam.
Vergelijk het met de vraag "Kunt u me de weg naar Amsterdam vertellen?" versus "Kunt u me de weg bordeel XXX op de Wallen in Amsterdam vertellen?". Als je in Groningen vertrekt heb je aan de eerste vraag genoeg om een heel eind te komen, en hoef je de tweede vraag pas te stellen als je in Amsterdam bent aangekomen.

DNS servers onderling gaan over op DoT, daar wordt op dit moment aan gewerkt.

Na DOH in de browser, moeten we naast boven genoemde nog 2 dingen fixen: SNI encryption (als je een HTTPS-verbinding maakt wordt nu de hostname verstuurd waar je mee verbind). En we moeten HTTPS de default maken ipv. HTTP.

Als dat allemaal is gedaan: dan gebruikt de browser alleen nog HTTPS verbinding uit en is alles verder verborgen door de encryptie.

Mogelijk dat we dan ook overgestapt zijn op: de IETF variant van QUIC (zeg maar HTTP/2 over encrypted UDP).

[Reactie gewijzigd door Lennie op 14 oktober 2019 23:01]

Groningen heeft zelf een prachtige wandelbuurt! Beetje opkomen voor 127.0.0.1

Ik heb geen probleem met het protocol, maar het moet eenvoudig te implementeren zijn op servers en je moet eenvoudig de keuze kunnen maken of je het wil en met welke servers.

Nu krijg je weer een stuk informatie die je verplaatst van een willekeurige partij naar Google, 1 van de grootste informatieverzamelaars. En het ergste is dat vele gebruikers het niet eens beseffen dat Google nog meer informatie over hen gaat verzamelen.

En het ergste is dat vele gebruikers het niet eens beseffen dat Google nog meer informatie over hen gaat verzamelen.

Ik vind juist het ergst dat je er vanuit een beveiligingsoogpunt zeer weinig aan kan doen, je network controls worden voor CnC / bot en malware volledig blind, je kan het uitzetten op group policy niveau maar dat betekend dat je alle browsers moet gaan toevoegen en onderhouden. Er is een optie tot een soort killswitch maar die werkt dus enkel in centraal beheerde gevallen want als de user DoH expliciet aanzet wordt die killswitch genegeerd. Portable installaties gaan dan een serieus probleem vormen of headless browser die samen met malware geïnstalleerd kunnen worden.

Kortom de investeringen die er gedaan zijn door de bedrijfswereld om hun netwerken te beveiligen zodat client er veilig van gebruik kunnen maken moeten nu verplaatst worden naar de end points met als potentieel gevolg dat de gebruiker meer hinder van die security controls kan ondervinden. Dit kan dus de balans tussen gebruikers ervaring en beveiliging meer verstoren als wat het opleverd.

Portable installaties gaan dan een serieus probleem vormen of headless browser die samen met malware geïnstalleerd kunnen worden.

Als portable installaties toegestaan zijn dan is DNS-over-HTTPS niet het probleem.

Kortom de investeringen die er gedaan zijn door de bedrijfswereld om hun netwerken te beveiligen zodat client er veilig van gebruik kunnen maken moeten nu verplaatst worden naar de end points met als potentieel gevolg dat de gebruiker meer hinder van die security controls kan ondervinden.

Een netwerk is niet beveiligd zolang onveilige apparaten ermee kunnen verbinden. Zorg ervoor dat je het beheer van je clients op orde hebt, en DNS-over-HTTP is geen probleem.

je kan het uitzetten op group policy niveau maar dat betekend dat je alle browsers moet gaan toevoegen en onderhouden.

Nee. Je levert één browser met een whitelist aan add-ons die geïnstalleerd kunnen worden door de gebruiker samen met andere policies om deze dicht te timmeren. Die ga je beheren.

En nee, dat is geen Internet Explorer. IE gebruik je enkel voor het lokale prutje dat met niets anders werkt, en laat je geen verbinding maken met het Internet.

[Reactie gewijzigd door The Zep Man op 14 oktober 2019 07:16]

Dit is echt veel te kort door de bocht, helaas. In een BYOD omgeving kan je dit soort dingen niet afdwingen, en dat heeft niks te maken met een netwerk dat onbeveiligd is als je onveilige apparaten toelaat.

Dat is namelijk prima te beveiligen mits je goede segmentatie aanbrengt in je netwerk. Alsnog wil je niet dat die BYOD DoH gaan doen omdat je als beveiliger wel wil zien of er malware actief is, om dat het apparaat in een ander segment of gewoon van je netwerk te droppen.

Dit is echt veel te kort door de bocht, helaas. In een BYOD omgeving kan je dit soort dingen niet afdwingen, en dat heeft niks te maken met een netwerk dat onbeveiligd is als je onveilige apparaten toelaat.

Ik vind het eerlijk gezegd vooral kort door de bocht om te doen alsof het zuiver versleutelde DNS-verbindingen zijn die de beveiliging in het gedrang brengen in een BYOD-omgeving. Ik snap dat het een realiteit kan zijn dat je niet zomaar af kunt stappen van een BYOD-omgeving vanwege niet security-gerelateerde keuzes maar het is onoprecht om dat niet te benoemen. Strikt genomen neemt dat natuurlijk niet weg dat je wat aan security inlevert als je DNS-requests niet meer kunt inzien, maar het is absoluut een lapmiddel dat nodig is (of lijkt) omdat op een ander onderdeel nog veel meer is ingeleverd.

Laten we voorop stellen dat een BYOD-omgeving de beveiliging niet ten goede komt. Dat is niet te ontkennen natuurlijk.

Echter, Security is niet alles dicht zetten. Security binnen bedrijven is ervoor zorgen dat je business zo veilig mogelijk runt. Dat wil zeggen dat als de business wil werken met BYOD je je security maatregelen daar op moet afstemmen. En aangezien je vrij weinig zichtbaarheid hebt op een BYOD is DNS wel degelijk een essentieel onderdeel voor zichtbaarheid op een device waar je verder geen zicht op hebt.

Kijk maar naar bijvoorbeeld de PiHole. Dat is een DNS ad block oplossing dat erg populair is voor thuis gebruik. Je komt er dan achter dat veel van je IoT devices dingen doen waar je geen grip op hebt. Je krijgt zichtbaarheid in wat er gebeurd en kan daar eventueel ook op handelen.

Dus ja, ik ben het zeker met je eens dat BYOD op andere vlakken meer inlevert op het gebied van security dan een DoH oplossing, echter is dat niet relevant voor deze discussie, omdat BYOD het kader is waarin je je security moet toepassen.

Als je BYOD direct in het bedrijfsnetwerk plaats. Helemaal mee eens. een BYOD is dan echt een ziekte bron voor je netwerk.
Echter als jij je netwerk goed segmenteerd en een aangesloten laptop gaat whoop zo het gasten netwerk in. Waarna een gebruiker eerst Citrix, Horizon, RDP moet starten. Dan zit je echt wel een stuk veiliger.
Daarnaast moet je als bedrijf zijnde altijd wel een blocking list bijhouden binnen je DNS, en dan niet eens alleen op DNS maar ook op IP.

Daarnaast zou ik niet begrijpen waarom je als bedrijfzijnde intern DoH zou willen draaien. je eigen DNS Server naar het Internet zou DoH kunnen zijn. Maar intern verkeer zie ik niet zo snel gebeuren. Zelfde met IPv4 waarom zou je IPv6 willen uitrollen op end user devices? en je omgeving onnodig moeilijk maken.

Helemaal eens, echter is het punt wat ik maak juist dat niet in beheer zijnde apparaten (BYOD) dus standaard DoH (gaan) gebruiken in de browser. Daar heb je juist geen invloed op en dat is een punt van aandacht voor digitale beveiligers.

Je wilt dus inderdaad niet DoH intern draaien nee

Zo lang ze niet in het Corp netwerk zitten maar in een gasten netwerk waar zij sowieso geïsoleerd zijn zie ik geen problemen.

Toegang tot porten tot diensten boven de gebruikelijke porten zou ik ook dicht zetten.

Daarnaast maakt het voor een op blacklist niet uit of je nu wel of geen DoH gebruikt. Het op adres wordt geblokkeerd. Is geen toegang tornde website/dienst.

Naast DNS filtering is ook ip filtering in een netwerk nodig. Zolang je cliënt niet hoeft te vragen aan de dns server welk op bij Pietje hoort zou de cliënt alsnog bij Pietje kunnen komen al blokkeer jij de dns naam.

Echter, Security is niet alles dicht zetten. Security binnen bedrijven is ervoor zorgen dat je business zo veilig mogelijk runt. Dat wil zeggen dat als de business wil werken met BYOD je je security maatregelen daar op moet afstemmen. En aangezien je vrij weinig zichtbaarheid hebt op een BYOD is DNS wel degelijk een essentieel onderdeel voor zichtbaarheid op een device waar je verder geen zicht op hebt.

Ik snap je volledig hoor, ik denk dat we vooral een andere mening hebben als het aankomt op de effectiviteit van het kunnen inzien van DNS-requests van de apparaten op het netwerk als beveiligingsmaatregel.

Kijk maar naar bijvoorbeeld de PiHole. Dat is een DNS ad block oplossing dat erg populair is voor thuis gebruik. Je komt er dan achter dat veel van je IoT devices dingen doen waar je geen grip op hebt. Je krijgt zichtbaarheid in wat er gebeurd en kan daar eventueel ook op handelen.

DNS-verkeer is maar een fractie van wat je in de gaten zou moeten houden op een netwerk en de extra informatie die het oplevert is marginaal. Als je door DoH op je PiHole niet meer kunt zien wat de apparaten op je netwerk doen is het probleem de manier waarop je je netwerkverkeer in de gaten houdt, niet DoH.

Dus ja, ik ben het zeker met je eens dat BYOD op andere vlakken meer inlevert op het gebied van security dan een DoH oplossing, echter is dat niet relevant voor deze discussie, omdat BYOD het kader is waarin je je security moet toepassen.

Ik ben met je eens dat je altijd binnen een kader handelt van wat (economisch) haalbaar en wenselijk is, maar het is m.i. wel relevant. Als je zegt dat iets "veiliger" is dan moet je dat wel kunnen verdedigen en daarbij is context belangrijk.

Volgens mij zijn we het redelijk met elkaar eens Meer ter verduidelijking, wat ik bedoelde met betrekking tot de pihole is dat je met inzage in je DNS request ook goed kan zien wat er gebeurd op wat anders een black box is. Daarmee illustreer ik alleen dat DNS request juist wel goede extra informatie oplevert.

Daarnaast is het inderdaad van belang dat je meer in de gaten houdt op je netwerk, echter is DNS vaak juist een waardevolle bron, vooral als je historische informatie bijhoudt zodat je weet wanneer en waarheen een specifieke record wees. Dat kan bij het onderzoeken van malware van cruciaal belang zijn.

Nogmaals, DNS is een element van een toolbox die je als beveiliger goed kan gebruiken. DoH heeft daar zeer zeker invloed op en het is daarom voor bedrijfsnetwerken zeker van belang dat daar naar gekeken wordt.

Kleine 'correctie' :): Security binnen bedrijven is ervoor zorgen dat je business zo veilig mogelijk nodig runt

In mijn geval ga ik liever voor zo veilig mogelijk in plaats van zo compliant mogelijk. Iets met 6-jes cultuur.

Eens hoor, maar bij veel bedrijven is er nog het aspect van budget . Maar als IT'er kun je de omgeving zeker inderdaad zo veilig als mogelijk configureren.

Dit is echt veel te kort door de bocht, helaas. In een BYOD omgeving kan je dit soort dingen niet afdwingen,

Je kan het misschien niet afdwingen in een BYOD omgeving, maar je kan wel de bekende DoH ip's blokkeren op poort 443.
Bovendien kan je nog steeds stellen dat in een BYOD omgeving apparaten bepaalde instellingen over moeten nemen voor een correcte werking in het netwerk, gezien het BYOD is zou men daar zelf zorg voor moeten dragen of anders moeten ze gewoon apparaten die door het bedrijf geleverd worden gebruiken.

dns is 53 voor DoH wordt 5053 gebruikt.

Daarnaast zou je net als veel andere diensten ook porten kunnen wijzigen.

Gebruikelijke porten moeten open 443, 80 ,25 enz. Al het andere is gewoon blocked. Totdat een specifieke business case het verantwoordt om een Port te openen.

[Reactie gewijzigd door To_Tall op 14 oktober 2019 16:31]

DoH gaat gewoon over poort 443, het is immers gewoon https verkeer en dat gaat standaard over poort 443.

reviews: Dns-over-https - Meningen verdeeld over encryptie dns-queries

Dns-over-https-verkeer loopt via poort 443, de poort waar al het andere https-verkeer overheen loopt.

En:

Bij dns-over-tls is dat anders. Dat loopt via de unieke poort 853.

Dus ik weet niet precies hoe je aan poort 5053 komt.

https://www.speedguide.net/port.php?port=5053 --> DNS over HTTPS (used by Cloudflared)

Dan is dat een uitzondering, al ken ik wel Cloudflare, is Cloudfared hetzelfde? Of was dat een test van Cloudfare?
Zoals bekend gaat https standaard over poort 443, een andere poort voor DoH zou ook niet slims zijn in verband met firewalls.

Cloudflared is een applicatie (die je o.a. op je Raspberry kan zetten) die een DoH implementatie regelt. Je host resolved dan tegen 127.0.0.1 en Cloudflared resolved dan tegen Cloudflare, via DoH. Ook poort 5053 was mij ook onbekend tot vandaag . Ik kan me niet herinneren dat ik die ooit open heb gezet.

[Reactie gewijzigd door Anoniem: 470811 op 17 oktober 2019 15:23]

omdat je als beveiliger wel wil zien of er malware actief is

Wat mij betreft is dit de kern.

Security is niet alleen voorkomen dat er iets gebeurt, security is dat je kan zien + handelen wanneer jij dat nodig acht.
De 3 onderstreepte punten geef een organisatie juist uit handen aan een commerciële partij die andere belangen heeft die aan veranderingen onderhevig zijn, en dat zelfde geld ook vaak voor de wetgeving waar ze onder vallen...

DNS over beveiligde verbindingen is een goed idee.
DNS over https.., ja.., if everything else fails.

Ik zie ook liever DNS-over-TLS over poort 853. Maar door uitblijven support bij de vele operating systems en DNS providers drukt de tech-reuzen dit kennelijk door naar DNS-over-HTTPS. Er kunnen echte uses cases verzonnen worden waarbij DoH een optie moet zijn, maar in de regel is DoT handiger.

We kunnen beter gaan mopperen op Microsoft (geen DNS-over-TLS) en onze Internet Service Providers (geen DNS-over-TLS en vaak ook niet eens DNSSEC), dan op Google of Mozilla (hoewel Mozilla wel een beetje, want die doet altijd DoH, en Google upgrade het alleen wanneer je al een DNS resolver gebruikt die DoH ondersteund).

Moah. BYOD betekent bij ons veelal ook SYOP. Solve your own problems. Het is als een DMZ en volledig afgescheiden van core business applicaties, maar daar zou ik dan ook niet specifiek DNSoHTTPS gaan afdwingen. Gevalletje van zoek het zelf maar uit.

Daar waar je wel controle over endpoints heb zou je intern gewoon DNS kunnen toestaan naar je DNS farm, en publiek zelf wel DNSoHTTPS afdwingen. Dan omzeil je een aantal knelpunten zonder de antimalware en contentcontrol zaken te omzeilen. En zijn je publieke requests toch verstleuteld.

Daar waar je wel controle over endpoints heb zou je intern gewoon DNS kunnen toestaan naar je DNS farm, en publiek zelf wel DNSoHTTPS afdwingen. Dan omzeil je een aantal knelpunten zonder de antimalware en contentcontrol zaken te omzeilen. En zijn je publieke requests toch verstleuteld.

Dit! Gewoon Gezond Verstand(TM) gebruiken.

[Reactie gewijzigd door poktor op 14 oktober 2019 17:23]

BYOD zal je sowieso willen afschermen in een apart vlan/etc, je weet nooit wat daarop draait.

En nee, dat is geen Internet Explorer. IE gebruik je enkel voor het lokale prutje dat met niets anders werkt, en laat je geen verbinding maken met het Internet.

Vertel dat eens aan alle bedrijven die nog steeds enkel IE support voor hun webapplicaties. Ik kom helaas nog steeds webapplicaties / portals tegen van bedrijven (regelmatig zelfs grote multinationals) waarbij bepaalde zaken gewoon niet lekker, of zelfs helemaal niet werken wanneer je geen IE gebruikt.

Het wordt ook een beetje door de industrie zelf in stand gehouden. Neem bijvoorbeeld de VMware-console van de laatste versie van ESX. Die wordt nog steeds geheel in Flash gebouwd. Hoe krom wil je het hebben..

De Flash console is al weer even "deprecated", alle vernieuwingen m.b.t. vSphere zitten in de HTML5 console. Het flash gedeelte is alleen nog eenwezig voor legacy zaken die nog niet in de HTML5 console zitten.

Mooi bedacht vanuit een beheersomgeving, maar volstrekt onhoudbaar als je te maken hebt met veeleisende gebruikers met een bovengemiddelde kennis van netwerken en systemen. Je wilt niet weten wat de shitstorm was toen connectie naar github op de blacklist kwam. Development lag stil en mensen gingen tarretjes per e-mail versturen om tóch maar verder te kunnen, want deadline.
Zodra iets onwerkbaar wordt (gemaakt) wordt er een omweg gevonden, malware lukt dat dan ook wel.

Nee. Je levert één browser met een whitelist aan add-ons die geïnstalleerd kunnen worden door de gebruiker samen met andere policies om deze dicht te timmeren. Die ga je beheren.

Je hebt dit. En dan de praktijk:
Ik moet applicatie X testen tegen browser Y. En Browser Z, V en W, versies x,z,y.

Buiten het feit dat een hele simpele maar effectieve manier om hordes vol malware buiten de deur te houden nu om zeep wordt geholpen biedt het ook gewoon bar weinig meerwaarde.

In plaats van je provider kunnen nu grote commerciële partijen informatie halen uit je dns verzoeken. In landen waar dns queries een probleem waren was daar al gewoon de oplossing om je dns verkeer via een vpn te laten lopen. Ik durf de stelling aan dat in alle andere landen Google en andere grote commerciële partijen een veel grotere bedreiging zijn voor een vrij internet dan je lokale provider...

Geef mij een reden waarom ik niet gewoon een random dnsoh server op mag geven, maar alleen mag kiezen uit grote commerciële partijen? Als ik nu mijn router opgeef als dns dienst is dat geen probleem, maar nu beslissen de browsers plotseling dat het maar eens even flink redundant, stabiel, bla bla moet? Wassen neus.

Je lost hiermee geen probleem op, je maakt er eentje.
Zeer slechte zaak dit.

Prima artikel trouwens van T.Net!

Je hebt dit. En dan de praktijk:
Ik moet applicatie X testen tegen browser Y. En Browser Z, V en W, versies x,z,y.

Dat is de praktijk in een beperkt aantal gevallen, waarschijnlijk toegespitst op jou ervaring. Over het algemeen kan een standaard kantoormedewerker best met één browser werken.

Ik denk dat je dat in enterprise omgevingen zwaar tegen gaat vallen.
Je hebt namelijk ook nog de scenario's waarbij een webapplicatie alleen in browser X werkt en een andere webapplicatie alleen in browser Y. Wij hebben binnen ons bedrijf al Internet Explorer, Mozilla Firefox én Chrome nodig voor de gewone gebruikers van de standaard pakketten.
Devvers en marketeers is nog een heel ander verhaal..

Dat hangt natuurlijk van de omgeving af. In vele bedrijfsomgevingen worden er oplossingen gebruikt die wel degelijk inspectie doen op https verkeer waarbij je specifieke domains gaat whitelisten. Daarnaast blijf je de optie behouden om DoH volledig uit te schakelen als je dat wenst. Maar dat brengt me opnieuw bij het feit dat het relatief moeilijk is om een eigen DoH implementatie op te zetten als men jouw geen controle geeft over de instellingen van welke servers gebruikt mogen worden.

Voor een bedrijf dat zijn IT goed op orde heeft is er dus geen probleem. DoH kan je trouwens uitschakelen met 1 enkele DNS entry als ik het mij nog goed herinner. De browser gaat controleren op dat record om te beslissen of DoH gebruikt mag worden of niet. Wel is het zo dat malware implementaties dat kunnen negeren, maar er zijn ook andere manieren waarop ze de CnC server kunnen gaan zoeken zonder dat er veel aandacht op gevestigd moet worden.

DoH kan je trouwens uitschakelen met 1 enkele DNS entry als ik het mij nog goed herinner.

Correct. Dit kan met behulp van een "canary" domein. Echter is dit als het goed is geen universele standaard en ben je afhankelijk van de browser boeren om hier naar te luisteren. Persoonlijk ben ik er niet heel blij mee omdat ik dit zie als een middel wat het gevolg aanpakt en niet de oorzaak (ie: browsers die network settings default negeren, wat is het volgende pakket dat dit gedrag gaat kopiëren?).

Bron: https://support.mozilla.o...in-use-application-dnsnet

[Reactie gewijzigd door Caayn op 14 oktober 2019 09:11]

DoH kan je trouwens uitschakelen met 1 enkele DNS entry als ik het mij nog goed herinner.

Alleen als de gebruiker het niet expliciet heeft aangezet.

Kortom de investeringen die er gedaan zijn door de bedrijfswereld om hun netwerken te beveiligen zodat client er veilig van gebruik kunnen maken moeten nu verplaatst worden naar de end points met als potentieel gevolg dat de gebruiker meer hinder van die security controls kan ondervinden. Dit kan dus de balans tussen gebruikers ervaring en beveiliging meer verstoren als wat het opleverd.

De verplaatsing van het security model naar de endpoint is sowieso iets dat al veel langer in gang was. En het is ook heel logisch: Mensen werken niet meer van 9/5 op het kantoor met hun desktop PC. Ze pakken hun laptop mee, werken een dagje thuis, in de trein of op het vliegveld. In veel gevallen kunnen ze zonder VPN toe omdat je als bedrijf veel cloud diensten gebruikt, en hierdoor zullen ze vaak nalaten om de VPN aan te zetten.

Het hele security model verplaatst zich gewoon naar de endpoint maar ook naar de cloud, waarbij je het tussenliggende netwerk niet per se als vertrouwd ziet. Hier heb je 'op de zaak' alleen maar extra voordeel van, het maakt rotzooien op het netwerk door hackers een stuk lastiger. Het zijn vooral legacy toepassingen op het interne netwerk die nog VPN en onge-encrypte verbindingen nodig hebben, en dit zijn juist de dingen die aangepakt moeten worden.

[Reactie gewijzigd door GekkePrutser op 14 oktober 2019 10:34]

Het hele security model verplaatst zich gewoon naar de endpoint maar ook naar de cloud, waarbij je het tussenliggende netwerk niet per se als vertrouwd ziet. Hier heb je 'op de zaak' alleen maar extra voordeel van, het maakt rotzooien op het netwerk door hackers een stuk lastiger.

Klopt, ben er ook een groot voorstander van maar dat betekend niet dat organisaties hier "snel" naar toe bewegen. De Snelheid waarmee dit uitgerolt word ( in de komende release of misschien twee releases) is vele malen sneller als wat grote organisaties nodig hebben om naar een endpoint model te gaan.

Waarmee je dus voor dat tussenliggende stuk een probleem hebt dit kan bij een kleine organisatie misschien een maand of 3 zijn maar een enterprise met 60k werknemers wereldwijd, zal die gap een heel stuk langer zijn en dus ook kwetsbaarder in die periode.

Ja, waar ik werk zal het ook langer duren dan 3 maanden hoor (veel meer dan 60k werknemers)

Maar dan nog zijn er prima opties om mee om te gaan. Je kan het tijdelijk uitzetten: Kwestie van wat instellingen pushen. Als je nu de instellingen je browsers nog niet beheert dan doe je sowieso wat fout.

Bovendien, als we het aan de enterprise overlaten dan komen we nooit verder en dan zaten we nu nog op Windows XP. Soms hebben die gewoon een zetje nodig.

[Reactie gewijzigd door GekkePrutser op 14 oktober 2019 10:42]

Maar dan nog zijn er prima opties om mee om te gaan. Je kan het tijdelijk uitzetten. Als je nu de instellingen je browsers nog niet beheert dan doe je sowieso wat fout.

Dat is het punt dus dat kan niet, werknemer zijn zeer creatief zeker als ze daarmee bijvoorbeeld whatsapp web (voorbeeld) wel mee kunnen gebruiken.

Zelfs vanuit centraal beheerde installs met een non admin account, zijn de enforcements van de grouppolicy uit te zetten of te negeren. ook als je het canary domain gebruikt.

Als de werknemer gaat klooien en daarmee de intranet sites stukmaakt, hebben ze zelf een probleem (en nog meer omdat ze daarmee de security policy overtreden).

Dit komt ook een beetje doordat je als een schooljuf gaat werken natuurlijk. Waarom Whatsapp Web(*) blokkeren? Flexibiliteit en verantwoordelijkheid bij de werknemer is nu belangrijk. Maak het makkelijk om 's avonds nog een werk emailtje te lezen en overdag een whatsappje te beantwoorden. Alle non-werk sites blokkeren is zo 2005.

Als je je werknemers als volwassene behandelt gaan ze er ook minder omheen werken.

(*) Waar ik wel een probleem mee heb overigens (en mijn werkgever) is de gewone Whatsapp op de mobiel, die alle contactpersonen uploadt. Dit staan we wel toe maar we geven die geen toegang tot de bedrijfcontacten ivm GDPR.

Interessant, ik zie niet vaak zo'n bewustzijn over de incompabiliteit van Whatsapp met zakelijk gebruik.

Bij ons mag Whatsapp niet gebruikt worden op apparaten waar zakelijke contacten op staan.

Immers, zodra jouw arts of advocaat Whatsapp installeert op een telefoon met jou in het adresboek, weet Facebook van jullie relatie.Ik vraag me af hoeveel mensen zich daarvan bewust zijn, als ik zie hoeveel Whatsapp nog door professionals gebruikt wordt.

Whatsapp Web is wat dat betreft redelijk onschuldig, het is meer een makkelijkere bediening van je telefoon. Er is wel een beetje een "data loss prevention" probleem, maar aan de andere kant kan je ook altijd gewoon foto's van het scherm maken met je telefoon. Uiteindelijk hebben we gekozen dat wel toe te staan.

Wat we doen is de contactpersonen beschermen op de mobiel. Op iOS via een MDM API waarmee we kunnen kiezen welke apps ze kunnen zien, Whatsapp is daar inderdaad geen van. Op Android installeren we een "Work profile", een soort VM. Toegang tot de zakelijke informatie (email, contactpersonen en alles) is alleen toegestaan binnen die omgeving en alleen goedgekeurde apps kunnen daarin geinstalleerd worden (dus geen WhatsApp). Dus zo doen we dat. iOS komt trouwens ook met een dergelijke afgeschermde mode nu met iOS 13 ("User Enrollment" genaamd). Dat gaan we ook gebruiken.

We krijgen er wel heel veel klachten over. Vaak is het argument "De klant gebruikt het dus ik moet wel". We staan het alsnog niet toe dus ik denk dat ze contactpersonen toevoegen op het persoonlijke gedeelte van de telefoon. Dit kunnen we niet voorkomen.

En inderdaad, het is een puinhoop op het gebied van Privacy. Facebook kan ontzettend veel zien. Vooral in combinatie met big data technieken kan er ontzettend veel aan afgeleid worden ondanks dat de communicatie zelf encrypted is en facebook die niet in kan zien.

[Reactie gewijzigd door GekkePrutser op 14 oktober 2019 13:27]

Netjes gedaan hoor! Tijd voor een andere nickname lijkt me

Bij ons mag Whatsapp niet gebruikt worden op apparaten waar zakelijke contacten op staan.

Wij hebben zo'n regel niet, in ieder geval niet zo expliciet, maar ik heb ooit geprobeerd om Dropbox tegen te gaan (ten gunste van filetransfer service die we zelf beheerden). De gemiddelde reactie was "Oh, geen probleem. Ik doe het wel even via mijn privé-telefoon, dan hoeven we IT niet lastig te vallen". En dan denken ze oprecht dat ze goed bezig zijn om dat ze zelfstandig een oplossing hebben bedacht zonder het aan IT te vragen.

En dat zijn allemaal mensen met een academische achtergrond, wat intelligentie betreft horen ze bij de bovenlaag van het land en de meesten zijn harde werkers die extreem gemotiveerd zijn. Met de beste wil van de wereld zien ze de problemen niet en/of weten ze niet hoe ze er mee om moeten gaan. Het is geen kwade wil of opzet, in tegendeel, ze proberen echt om 'het' goed te doen, maar voor de meeste mensen is het veel te complex en niet te overzien. Daar heb je jaren opleiding en ervaring voor nodig en die hebben de meeste mensen nu eenmaal niet.

Dat klinkt bekend. Ik ben wel blij om te merken dat we niet de enige roepende in de woestijn zijn.

Het lijkt wel alsof mensen, onafhankelijk van opleiding en ervaring, dit soort problemen zien als onvermijdelijke natuurverschijnselen. Misschien een soort cognitieve dissonantie: te lastig om er iets aan te doen, dus geen probleem.

Tja, die werknemers zitten in de tang, aan de ene kant noodzaak om te leveren, aan de andere kant geen mogelijkheid om te leveren.

En daarnaast vergeten veel mensen dat als je Whatsapp gebruikt je wel encryptie hebt in je gesprek, maar zodra je een backup maakt van de chats dit dan unencrypted is Kan de NSA gewoon makkelijk meelezen
Tekst FAQ: De media en berichten in de back-up op Google Drive zijn niet beschermd met WhatsApp end-to-end encryptie.

dat is toch gewoon een keuze hoor.
Je kan perfect afdwingen dat alle trafffic via je VPN moet lopen ook die voor cloudtoepassingen.
VPN heeft niets met "legacy" te maken, maar eerder met controle hebben over data-stromen van welke aard die ook zijn.

Om niet in herhaling te vallen: GekkePrutser in 'reviews: Dns-over-https - Meningen verdeeld over encryptie d...

Naja het is dan meer dat de bot/malware controle ook alleen maar plaats kan vinden bij de servers die het verkeer de-encrypten want dat moet ergens gebeuren.

Zoals je zegt als Google/Mozilla de enige zijn die de "service" dns over https aanbieden komen er nog meer dns queries centraal binnen bij google (die het unencrypt) en dus veel extra data krijgt .
Dus informatie weg bij providers, centraal bij google/mozilla.

Dan moeten die niet alleen de lusten maar ook de lasten dragen! Dus ook verplicht scannen.

Volledig blind is het ook nog niet als je hooks in de netwerk driver maakt waar lokaal (eigen hardware) gemonitord kan worden welke dns requests gedaan worden (en ja dan kan malware dat ook, of moet zijn eigen netwerk stack beheren, blijft toch een arms-race)

Lang verhaal kort: Versleuteld verkeer beter ja, Nog centralere verwerking nee niet goed

Kortom de investeringen die er gedaan zijn door de bedrijfswereld om hun netwerken te beveiligen zodat client er veilig van gebruik kunnen maken moeten nu verplaatst worden naar de end points met als potentieel gevolg dat de gebruiker meer hinder van die security controls kan ondervinden. Dit kan dus de balans tussen gebruikers ervaring en beveiliging meer verstoren als wat het opleverd.

Ik heb hier een beetje dubbele gevoelens bij. Van de ene kant denk ik dat beveiliging zo veel mogelijk end-to-end moet werken. Van de andere kant maak ik (of vooral mijn gebruikers) veel gebruik van technieken die moeilijk of onmogelijk worden met DoH. Denk aan split-DNS, DNS-blocklijsten, malware-detectie, een captive portal of een blokkade op poort 53 zodat onze byod-gebruikers via onze DNS-servers moeten gaan. Al die technieken vind ik eigenlijk niet mooi en invasief, maar wel de meest praktische oplossing die we hebben.
Op lange termijn zou ik zo veel mogelijk end-to-end willen doen, maar op dit moment missen er naar mijn mening nog te veel stukken om die stap te maken. In mijn ogen is het op z'n minst noodzakelijk dat DNS weer door het OS gedaan wordt (al dan niet via DoH) en dat DoH via DHCP configureerbaar wordt.

[Reactie gewijzigd door CAPSLOCK2000 op 14 oktober 2019 11:52]

Wat heeft Google/Cloudfare aan de DoH info? Het doel van DoH is toch juist dat de beheerder van de DSN resolver niet meer mee kan kijken.

Ik vind het aspect van single point of failure veel belangrijker. In NL hebben providers echt een nutsvoorzieningen. Hou DSN verzoeken maar lekker gedecentraliseerd.

Heb jij dat even mis. De beheerder van de DNS-server ziet nog steeds elke website die je bezoekt, het is alleen op het stukje tussen jouw computer en de DNS-server dat het niet meer onderschept kan worden. Google/Cloudfare krijgen met deze zet dan ook toegang tot een hoop informatie die ze eerst niet hadden en potentieel kassa voor ze is.

...die ze eerst niet hadden

Wat bedoel je hiermee, aan de info die zij hiermee krijgen veranderd in principe toch niks en hadden ze toch al?

Als je Google/Cloudfare nu ook al als DNS gebruikt, dan is dat zo. Echter, het merendeel van de internetgebruikers heeft zijn modem op automatisch DNS staan en gebruikt de DNS-server van zijn internetaanbieder. Die internetaanbieder heeft nu dus de data van het merendeel van zijn klanten en die data wordt verhuisd naar Google/Cloudfare, die dus veel meer data krijgen waar ze potentieel munt uit kunnen slaan.

Weet je ook waarom het artikel stelt dat DoH is iets wat alleen grote partijen kunnen aanbieden? KPN en Ziggo hebben nu ook hun eigen DNS-servers. Het invoeren van DoH moet voor zo'n partij dan toch niet lastiger zijn?

DoH is geen onderdeel van de normale netwerkonderhandelingen over de verbindingsparameters (in praktijk veelal DHCP). Het hele besturingssysteem wordt genegeerd: De webbrowser heeft zijn DNS-client ingebouwd en doet eigenhandig DNS-queries.

Een partij als KPN of Ziggo kan wel DoH op zijn eigen servers activeren, maar dat betekent niet dat dat dan ook gebruikt wordt. Daarvoor is invloed op de browsermaker nodig en ik zie het niet gebeuren dat Mozilla met alle internetaanbieders ter wereld afspraken gaat maken dat hun eigen DoH-servers gebruikt worden. Kortom, dit zet de internetaanbieder buiten spel, wat ook precies het doel van deze ontwikkeling is.

Ik snap nu wat je bedoelde

Chrome 'upgrade' je DNS. Dus als jij 9.9.9.9 gebruikt op je apparaat, dan maakt Chrome daar straks DoH van. Als jij 192.168.1.1 hebt staan omdat je de DHCP van je thuisrouter niet hebt aangepast, dan gebeurt dat dus niet. Dus ik mis denk ik het werkelijke issue. Want als bedrijven gewoon 10.0.1.1 o.i.d. gebruiken, dan gaat Chrome geen DoH toepassen.

En wanneer je Chrome gebruikt, kan Google sowieso al bij je browse geschiedenis. Je privacy exposure veranderd niet met DoH in dat licht.

Bij Firefox is dat anders inderdaad, die gaat geforceerd een DoH provider toepassen.

[Reactie gewijzigd door Anoniem: 470811 op 17 oktober 2019 11:47]

DNS over HTTP = Aanbieder weet dan Echt alles wat je benaderd.

In de VK zijn ze echt losgeslagen in mijn ogen. Een aantal jaren geleden vóór de invoering, heb ik een documentaire gezien over een organisatie die pleiten voor internet filters. Hun redenering was om kinderen te beschermen tegen zaken als porno, gokken en andere 'schadelijke' content. De ISP moesten maar hun best doen om het mogelijk te maken en zaken als eenvoudige leeftijd checks zouden gecontroleerd moeten worden met een online paspoort.

De ISP dient daar niet voor. Zij moeten simpelweg het verkeer (veilig) doorgeven, anders krijg je zaken als in China én Turkije waar zelfs legaal content of een mening/wikiplatform wordt geblokkeerd of erger gebruikers worden vervolgd wanneer de overheid dat wilt. Als je familieleden wilt beschermen, dan koop je maar een pakket of schakel je controles in om dit mogelijk te maken.

Is een nutsbedrijf ook verantwoordelijk dat ik mijn energie niet gebruik voor een wietplantage? Moet ik ook maar gaan doorgeven/laten zien voor welke toepassingen ik mijn stroom (legaal/illegaal) inzet?

Dat overheden niet zo gelukkig zijn met DoH, is met name doordat hun vangnet in gevaar komt. VK staat bekend dat het graag gegevens opslaat onder de noemer terrorisme bestrijding. Door zoveel mogelijk te encrypten wordt dit soort onzin al een stuk moeilijker.

ISP zijn ook mede tegen omdat ze tegenwoordig ook content aanbieders zijn. Bt, Sky, Comcast.. allemaal bieden ze content aan die ze ook willen beschermen. Met encryptie wordt het een stuk moeilijker en kan niet zo eenvoudig worden nagegaan of iemand illegaal iets streamed bijvoorbeeld.

TL; DR: ISP moeten (DNS) verkeer versleuteld aanbieden en overheden moeten maar op een andere manier te werk gaan dan iedereen meeslepen in één vangnet.

Probleem is hier niet zozeer de overheden, maar de gebruiker zelf wiens DNS queries ongemerkt wordt doorgesluisd naar Google ipv zijn lokale ISP.

Interessant onderwerp, in het kader van privacy en profilering ben ik fel voorstander van deze techniek.Je DNS query dan weer via deze techniek aan Google geven is dan ook best zinloos lijkt me.

Kan iemand mij uitleggen hoe dnscrypt en dnssec zich verhouden tot DoH of Dns over Tls ?

DNScrypt en DNSsec zijn voor communicatie tussen DNS Servers onderling.
DoH en DoT zijn tussen server en client.

Onjuist: DNSsec is ook gewoon voor clients.

Verschil is dat DNSsec de authenticiteit borgt en niet de vertrouwelijkheid.

Dns wordt ook wel 'the last mile' van het internet genoemd: het laatste stukje dat een internetpakketje aflegt voordat het een website voorschotelt.

Deze snap ik ff niet, kan een internet pakketje immers niet eerder verstuurd worden voordat het bestemming adres bekend is, maw moet niet als een van de eerste akties de host in de url omgezet worden naar een geldig IP nummer via een DNS lookup?

Het klinkt erg zweverig. Ik denk dat de auteur 'the last unencrypted mile' bedoelde. Dat is overigens ook niet waar. Zie mijn reactie over Server Name Indication.

kun je een bron noemen waarin meer staat over SNI,

Ik had namelijk het idee dat SNI juist goed is voor servers, omdat je op die manier meerdere namen aan één ip kunt hangen om vervolgens het juiste cert te serveren.

De vraag is dan, waarom zou je dan niet de eerste verbinding kunnen maken naar: server27.serverowner.com over tls met default.cert

om dan te zeggen: heej server27. ik zoek mijnwebsite.nl
waarop dat ding zegt: ok dan switchen we naar mijndomeinnl.cert en var/www/mijndomeinnl/htdocs

kun je een bron noemen waarin meer staat over SNI,

Wikipedia to the rescue.

Ik had namelijk het idee dat SNI juist goed is voor servers, omdat je op die manier meerdere namen aan één ip kunt hangen om vervolgens het juiste cert te serveren.

Klopt.

De vraag is dan, waarom zou je dan niet de eerste verbinding kunnen maken naar: server27.serverowner.com over tls met default.cert

om dan te zeggen: heej server27. ik zoek mijnwebsite.nl
waarop dat ding zegt: ok dan switchen we naar mijndomeinnl.cert en var/www/mijndomeinnl/htdocs

Omdat jij niet in je adresbalk "server27.serverowner.com" intikt, maar "mijnwebsite.nl". Het is een kip-en-ei probleem. Om een veilige verbinding op te bouwen moet de server eerst weten met welke site jij wilt verbinden. Om te weten met welke site jij wilt verbinden moet eerst een veilige verbinding opgebouwd worden...

Zoals genoemd is men nu bezig met encrypted SNI. Dat had er natuurlijk vanaf dag 1 in moeten zitten, maar het is nooit te laat om het alsnog toe te voegen. DNS-over-HTTPS maakt ESNI mogelijk doordat voor ESNI via DNS kritieke gegevens uitgewisseld worden, wat ook veilig moet gebeuren. DNS-over-HTTPS is dus een stap naar de oplossing om unencrypted SNI in de ban te doen, maar nog niet de oplossing zelf. Die zal uiteindelijk vanuit de domeinbeheerders moeten komen zodra ESNI breed beschikbaar is.

[Reactie gewijzigd door The Zep Man op 14 oktober 2019 12:50]

Goede uitleg, bedankt! Is ESNI ook mogelijk met DNS-over-TLS? Ik kan het nergens terugvinden maar het lijkt me net zo goed mogelijk.

De client kan nooit weten dat hij een andere naam zoals "server27.serverowner.com" moet gebruiken terwijl hij data van mijnwebsite.nl wilt hebben.

Een multi-domain server zonder SNI is alleen mogelijk indien de server altijd een certificaat presenteert dat geldig is voor al zijn domeinen. Iets wat technisch op zich nog niet zo moeilijk is, maar het staat natuurlijk niet mooi als je een cert presenteert voor allerlei totaal ongerelateerde domeinen.

Zo las ik het ook en eerste wat ik deed is kijken of iemand al SNI in de comments had gepost. :-)

Dank je daar voor. :-)

Ik ben gelukkig niet de enige die dat als probleem ziet.

Na DNS encryption kunnen we dat dan ook oplossen gelukkig.

'The last unencrypted mile' is inderdaad ietsje duidelijker, daar doelde ik op. Maak ik even wat duidelijker.

The last mile is een aspect in de afstand van de verbinding, dus van server naar client bijvoorbeeld. De last mile is dan bijvoorbeeld vanaf de wijkkast.

In jouw context gebruik je het als een overblijfsel nu de meeste andere communicatieaspecten van internetverkeer zijn versleuteld. Maar dat heeft niks met afstand te maken, het slaat immers op het totale pad dat plaintext is (client naar dns server en weer terug). Dus the last unencrypted mile is dan een soort van verwarring van twee verschillende uitdrukkingen.

Dat maakt het m.i. niet veel beter, het is meer één van de laatste delen van het internet waarvoor nog geen encryptie wordt toegepast.

Je versimpelt hier nodeloos (wat is nou weer een internetpakketje?) en bovendien incorrect!

Je mist denk ik de thuis situatie die hier ook last van gaat krijgen.

Denk aan je Chromecast nu die je dhcp dns server ignored en gewoon DoH naar buiten stuurt. Dat wordt een stuk moeilijker te blokkeren/filteren.

En dit krijg je dan straks x100 met alle IoT apparaten die je gast aanschaffen. Waarvan je hopelijk de dns seever kan overrullen. Maar waarschijnlijk gaan ze allemaal hun eigen DoH server gebruiken en kan je mooi een waslijst met ip adressen gaan bijhouden van al je IoT producten die allemaal een andere DoH server gebruiken.

Een Chromecast moet je als tweaker zien als een onbeheerd apparaat van een derde partij, en dat thuis net zo behandelen als dat je op het werk zou (moeten) doen: gesegmenteerd in een apart VLAN. Verbindingen erheen zijn te proxyen of door simpelweg een ander entertainment apparaat (zoals een tablet) onderdeel te maken van hetzelfde netwerk.

Met goede segmentering is het niet zo interessant waar het allemaal verbinding mee maakt. Als je wel controle wilt over wat een apparaat doet moet je geen Chromecast aanschaffen.

[Reactie gewijzigd door The Zep Man op 14 oktober 2019 07:01]

Dat ben ik niet met je eens.
Er is zeer goede informatie over waar ip-adressen zich fysiek bevinden.
Straks gaan mijn "gewone" IoT devices zich allemaal even aanmelden via Chinese DoHs.
Nu heb ik nog de mogelijkheid heb om hun uitgaande verkeer volledig te blokkeren, maar straks werken ze dan gewoon niet meer.

Het is al een doorn in mijn oog dat veel IoT devices tegenwoordig met gesloten API en verplichte "cloud" oplossing komen. Met DoH wordt het nog erger.

[Reactie gewijzigd door Zynth op 14 oktober 2019 09:37]

Dus je bent het wel met mij eens. Als je controle over je eigen apparaten wilt hebben dan moet je dus goed opletten wat je koopt. Chromecasts en Chinees prul zijn een risico.

DNS-over-HTTP is iets dat een probleem blootlegt en niet het probleem zelf. Het probleem is dat jij geen controle hebt over de apparaten die je koopt.

[Reactie gewijzigd door The Zep Man op 14 oktober 2019 12:43]

Je blijkt dus die mogelijkheid nu al niet te hebben. Je hebt een beveiligingslek, dat is niet de schuld van DoH.

Nu kan ik nog controle uitoefenen op welke domeinen hij mag contacteren, dus die controle heb ik wel.

Die _HEB_ je dus niet, zoals je ziet. Dit is geen nieuw truukje. Als je onveilige apparatuur in huis haalt -> alleen intern verkeer. Opgelost.

Als apparatuur een dns verzoek doet via je eigen dns, kun je prima een fake adres terugsturen. Of als het protocol reverse engineered is, je eigen versie hosten waardoor het apparaat toch werkt.
Met DoH kun je niet je eigen mitm spelen en kun je niet meer blokkeren dat de verbinding naar buiten gaat.

Ja, maar als je het als beveiliging gaat gebruiken werkt het dus niet. De software kan zelf een andere DNS server kiezen. Dus mitm spelen is GEEN secure oplossing. Je probleem is een untrusted entity in je netwerk die verbinding wil naar buiten. Mitm is een symptoombestrijding.

Denk aan je Chromecast nu die je dhcp dns server ignored en gewoon DoH naar buiten stuurt. Dat wordt een stuk moeilijker te blokkeren/filteren.

Dat heeft eigenlijk helemaal niets te maken met DoH. Een apparaat kan nu ook al de DNS server die het binnenkrijgt via DHCP links laten liggen en de requests naar een eigen server sturen. Dat wordt niet makkelijker gemaakt door DoH.

Als je genoeg kennis hebt om geen apparaat te willen gebruiken dat DoH gebruikt naar een niet door jou in te stellen server dan heb je ook genoeg kennis om een apparaat te kopen dat configureerbaar genoeg is om het zelf te kunnen problemen.

Maar alles over DoH is encrypted... Dus je hebt geen idee wat er gebeurd.

Klopt, maar dat is alleen een probleem als je bouwt op de doorzichtigheid van DNS als beveiligingsmaatregel. Dat is vooral schijnveiligheid, want je kunt er niet zomaar van uitgaan dat een (kwaadwillende) zijn domeinnamen in plain-text resolved.

voor DoT in je router poort 853 blokkeren. voor DoH wordt het wat lastiger

Iets niet versleutelen heeft nadelen, zoals je verwacht. Het maakt het namelijk relatief eenvoudig voor een internetprovider om te achterhalen welke websites iemand bezoekt of door wie een bepaalde website bezocht is.

Wat DNS-over-HTTPS niet gaat oplossen door Server Name Indication. Dat is de echte 'last mile'.

Besturingssystemen ondersteunen het protocol op dit moment nog niet native.

Onder Linux kan je het voor het gehele besturingssysteem implementeren. Ja, het heet een 'proxy', maar conventionele DNS is vaak ook afhankelijk van een client-side daemon. Veel verschil is er dus niet.

[Reactie gewijzigd door The Zep Man op 14 oktober 2019 07:29]

SNI is er net gekomen omdat we meerdere sites op 1 enkel IP adres willen kunnen hosten. Een handshake kan perfect zonder het weggeven van de hostname, zolang je maar zeker bent dat er slechts 1 hostname achter een IP adres zit.

Het gaat er om dat de SNI ook gewoon in plain text staat en je provider zo kan zien welke site je bezoekt. Dat hoeft helemaal niet om met virtual hosts te kunnen werken, de SNI zou gerust ook versleuteld kunnen worden (zie Encrypted SNI).

Het artikel claimt dat dns-over-https gaat voorkomen dat providers kunnen zien welke sites je bezoekt, dat is dus pertinent onwaar zolang de SNI plain text blijft.

Hier nog een goed verhaal over encrypted SNI dat ik vond toen ik onderstaande aan het typen was

https://blog.cloudflare.com/encrypted-sni/

De versleuteling hangt aan een domeinnaam bij HTTPS daarom krijg je een kip en ei verhaal op de server. Om te kunnen achterhalen welke sleutel je nodig bent om de versleuteling eraf te halen moet je weten om welk domein het gaat zodat je het bijbehorende certificaat kan opzoeken. Als dat domein dus in de versleutelde data staat dan wort het wel heel moeilijk. Je zou dan op de server al de op dat adres beschikbare certificaten moeten proberen om te zien of 1 de juiste data oplevert, maar dit is veel te veel werk op een server daarom hebben we SNI.

Encrypted SNI zet dus nog een extra encryptie op zoals te lezen in het cloudflare artikel.

Encrypted SNI bestaat al, dus dat zal ook in de nabije toekomst opgelost gaan worden.

Indeed! En op windows, die andere grote groep, is het ook een client/daemon die je kan vervangen/proxieen door een eigen variant waar je nog wel ook je eigen ‘dns blok/malware detect’ tussen kan zetten. Wat ik om me heen zie, zijn vooral ‘lui’ opgezette omgevingen. Even iets verder kijken dan wat je verteld wordt. Met zo’n proxy oplossing kan je je precious byod en interne omgeving goed regelen én je eigen browser kiezen zonder overgeleverd te worden aan evil google en co. Voordeel is ook nog dat je ook alle andere Internet pratende apps iig op DNS niveau filtert. Yay!
Voor grote bedrijfsomgevingen maak je toch gewoon je eigen doh/dot? Zo moeilijk is dat nou ook weer niet en als het goed is heb je dan ook al je malware filtering/blokkades op datzelfde apparaat. De encryptie hoeft de functionaliteit niet tegen te houden.

Voor bedrijfsnetwerken / vpn opgelegde dns servers is er wel de mogelijkheid om ervoor te zorgen dat DoH niet gebruikt wordt, namelijk: https://support.mozilla.o...in-use-application-dnsnet

Dit is nog wel een tijdelijke oplossing die enkel door Mozilla wordt gebruikt/aangeboden tot het tot standaard wordt geheven. Dit kan ook helpen bij het zorgen dat captive portals e.d. blijven werken.

Ook is het voor bedrijven met goede infrastructuur natuurlijk geen enkel probleem om iets als https://github.com/DNSCrypt/dnscrypt-proxy als upstream op te zetten (met meerdere upstreams), dan is het privacy voordeel er nog steeds en kunnen ze nog steeds een lokale resolver/caching hebben draaien.

Uiteindelijk is het natuurlijk de bedoeling dat root/authoritative servers ook DoT/DoH gaan accepteren zodat zodat iedereen z'n eigen resolvers kunnen draaien van begin tot eind en de eis verdwijnt voor een Cloudflare/Google, maar uiteindelijk moet er iemand zijn die het voortouw neemt om de verandering te implementeren (iedereen wilt ook nog steeds ESNI).

(full disclosure: ik werk voor Cloudflare)

[Reactie gewijzigd door DJVG op 14 oktober 2019 10:00]

Dit is natuurlijk een nonsense-oplossing. Ten eerste is opt-out hier een verschrikkelijke oplossing. Het zou opt-in moeten zijn. Je moet niet willekeurige meuk aan je DNS-server toe gaan voegen om te voorkomen dat browsers hem negeren.

Bovendien is er natuurlijk ook weinig wat de gemene Amerikaanse ISP's in de weg staat om het betreffende opt-out record toe te voegen aan hun eigen DNS-servers zodat het netto geen effect heeft.

Overschakelen op DoH moet een actieve keuze zijn, niet iets wat bepaald wordt door de aan- of afwezigheid van nonsens-DNS-records.

[Reactie gewijzigd door MadEgg op 14 oktober 2019 11:40]

Je hoeft natuurlijk enkel deze zone toe te voegen om te voorkomen dat DoH geactiveerd wordt, meestal omdat je lokaal een DNS server hebt draaien die lokale records gebruikt voor zones die eigenlijk publiek zouden moeten zijn (.local is namelijk nooit resolved over DoH: https://wiki.mozilla.org/...esolver#Dynamic_Blacklist).

We weten dat lastig is om mensen wijzigen te laten maken en voor veel thuisgebruikers (de wereld is tenslotte groter dan Nederland) heeft het gebruik van DoH veel privacyvoordelen (of dat nu of later is, ik laat in het midden of mensen Cloudflare, Google, PowerDNS, Quad9 etc.. zouden moeten vertrouwen), het is in ieder geval niet makkelijk om de DNS queries on the wire in te zien met het gebruik van DoH/DoT en dat is het doel.

Ik begrijp dat mensen het vervelend vinden dat het opt-out is maar ik denk dat dit een goede manier is om vooruitgang te bewerkstelligen.

Heb je zelf een idee hoe wat zou werken om de privacy te verhogen voor de gemiddelde internet gebruiker zonder dat ze daar verstand van hoeven te hebben? Een idee afschieten is natuurlijk heel erg makkelijk maar meewerken aan de oplossing zou veel waardevoller zijn!

Mijn punt is dat dit geen oplossing is van een probleem, alleen de verplaatsing ervan. Je verruilt één probleem (DNS unencrypted over de draad) met een ander probleem (centralisatie van DNS requests naar een paar grote ISP's, met name CloudFlare en Google). Dat is niet de oplossing. Ook niet een stapje in de richting.

DoT is een goede oplossing. Thuisgebruikers zouden daar inderdaad weinig mee van doen moeten hebben. De push moet komen vanuit operating system bouwers - als Windows, Mac OS en ChromeOS geen hun leverage inzetten om unencrypted DNS in de ban te doen kun je stappen maken door ISP's te dwingen om DoT te ondersteunen. Een goede eerste stap is popup / waarschuwingen in het OS als het een DNS server ontvangt die geen DoT ondersteund. En daarbij vanzelfsprekend ook het vereisen van DNSSEC. Op termijn kunnen niet-versleutelde verbindingen vertraagd of zelfs geblokkeerd gaan worden. Zo zullen er genoeg klachten binnenkomen bij ISP's om overstag te gaan.

Dit is natuurlijk een nonsense-oplossing. Ten eerste is opt-out hier een verschrikkelijke oplossing. Het zou opt-in moeten zijn. Je moet niet willekeurige meuk aan je DNS-server toe gaan voegen om te voorkomen dat browsers hem negeren.

Dit is een tijdelijk hack om die niet bedoeld is als langetermijnoplossing. We moeten nog gaan zien wat het alternatief wordt, maar ik heb nog hoop dat er een betere oplossing komt.

DoH is volgens mij alleen terecht wanneer je meer vertrouwen hebt in de browser dan je ISP. Ik vertrouw mijn ISP, die onder hetzelfde recht valt als ik en waar ik een expliciete relatie mee heb. Een browser waar ik tien jaar geleden eens "Ik ga accoord" die ik niet kan bellen als ik een probleem heb, laat die maar van mijn verbinding afblijven.

DoT is imho een betere oplossing, maar biedt dan weinig voordelen wanneer je ISP ook je DNS beheerd.

Heel erg veel DNS servers ondersteunen DoT al, dus je zit niet perse vast aan je provider of één van de grote jongens. PowerDNS ondersteunt het ongetwijfeld, openNic servers en surfnet ook, evenals verschillende adblokkende DNS providers. Keuze genoeg dus.

Je maakt het grootschalig meeluisteren op netwerkverbindingen door inlichtingendiensten bijvoorbeeld wel net weer een tandje lastiger. Met TLS 1.3 is ook onversleuteld SNI weg, dus lekt dat ook de plaintext hostname niet meer.

Bovendien is DoT in een bedrijfsnetwerk gemakkelijk uit te rollen, waarbij je toch je split horizon DNS opstelling werkend kunt houden, monitoring en logging op DNS kunt blijven doen etc.

[Reactie gewijzigd door wizzkizz op 14 oktober 2019 07:19]

Je hebt artikel dus niet gelezen.

Bijna geen enkel dns server ondersteund het. Omdat het een functie in de browser is. Chrome werkt alleen met Google dns
Firefox heeft ook zijn eigen dns.

En powerDNS is de verliezende partij en niet bruikbaar. Omdat ze NIET worden opgenomen in browser settings.

Een bijkomend effect daarvan is dat eigenlijk alleen grote dns-providers met Google of Mozilla in zee kunnen gaan. Kleinere aanbieders, zoals het Nederlandse PowerDNS, kunnen niet aan de eisen voldoen die die bedrijven stellen. "Mozilla stelt bijvoorbeeld zware eisen", zegt PowerDNS-oprichter Bert Hubert tegen Tweakers. "We hebben het geprobeerd samen met partners, want zonder wereldwijd dekkend netwerk mag je niet meedoen.

Het probleem is namelijk dat je geen eigen DNS instellingen meer kan gebruiken en opgegeven. Je kan op je gateway elke dns instellen die je wil maar deze wordt niet meer gebruikt omdat dat de dns over Port 443 (https) naar de browser fabrieksdns gaat.

Waar door bijv Google het alleen heerschappij krijgt over de dns en dus ook over welke sites wel of niet werken. Waarbij Dns over tls niets toevoegt of tegenhoud over daar iets anders aan kan doen..

[Reactie gewijzigd door xbeam op 14 oktober 2019 09:35]

https://support.mozilla.o...tps#w_switching-providers

https://github.com/m13253...tps/blob/master/Readme.md

Het valt allemaal wel mee voor de echte Tweakers, gewoon je eigen server rollen en settings aanpassen. Voor ons een goede zaak!

Daar kan dus in de logica van het artikel niet je eigen dns instellen maar alleen door Firefox geselecteerden dns’s gebruiken zoals powerdDNS aangeeft is heel moeilijk om daar als dns provider tussen te komen. Laat staan dat je als it bedrijf of afdeling je eigen DNS op dat lijstje krijgt.

Het spreekt elkaar allemaal een beetje tegen

[Reactie gewijzigd door xbeam op 14 oktober 2019 09:46]

Het artikel klopt dan ook voor geen kant. Je kunt je eigen DoT server opzetten en ook gewoon je eigen DoH server. Je kunt zelfs je eigen DNS Server gebruiken met een DoH laag erover heen, ook als bedrijf. In Firefox en Chrome kun je je eigen DoH server gewoon toevoegen. Ik gebruik al een tijdje ondertussen DoH in FF op m'n eigen server waar ik voorheen m'n eigen DNS server gebruikte. Dit is geen enkel probleem en er gaat niets naar Cloudflare of Google toe. Ook m.b.t. SNI is er al een oplossing bedacht, namelijk eSNI. Deze standaard is echter nog niet aan de server kant geimplementeerd door ontwikkelaars omdat het zover ik weet op dit moment nog een draft is. Dus dat is nog even afwachten tot het zover is.

Maar je kan dat niet meer afdwingen in de NAT. Door wat bedrijven nu doen bij plain-text dns via een Port 53 redirect.

Nu moet dat voor iedere browser apart instellen.

Jij had mijn comment dus niet gelezen

Ik had het namelijk over DoT en niet over DoH. Daarnaast kun je van alles zelf instellen (ook straks nog), maar in een corporate omgeving met powerusers (die eigen executables kunnen uitvoeren) is DoH een stuk lastiger dan DoT.

Gelukkig is er standaard een override, maar de gebruiker kan die handmatig ook weer blokkeren.

Precies! bedankt voor de bevestiging dat Je het niet hebt gelezen. 😘 (waarschijnlijk heb je dat wel maar je reactie was door meer kennis tegen strijdig met artikel)

Dot is volgens het artikel inderdaad een goed alternatief maar wordt niet gebruikt door browsers zoals Chrome en Firefox die gebruiken Doh waardoor spelers zoals powerDNS buitenspel staan. En dat is juist het grote bezwaar van bedrijven, providers en experts.
Waar het in de conclusie om gaat.

Maar zoals in het bericht hier boven al blijkend dat waarschijnlijk een te eenzijdige stelling van powerDNS is. En dat het dus wel
Mogelijk is om Binnen de DOH settings iedere willekeurige DNS te gebruiken. Dus wat dat betreft heb je gelijk. Alleen is dat niet duidelijk vanuit het artikel

[Reactie gewijzigd door xbeam op 14 oktober 2019 14:00]

DoH is volgens mij alleen terecht wanneer je meer vertrouwen hebt in de browser dan je ISP. Ik vertrouw mijn ISP, die onder hetzelfde recht valt als ik en waar ik een expliciete relatie mee heb. Een browser waar ik tien jaar geleden eens "Ik ga accoord" die ik niet kan bellen als ik een probleem heb, laat die maar van mijn verbinding afblijven.

En het is nog erger want het is niet alleen je browser maar ook de DoH-provider die je moet vertrouwen, en toevallig of niet zijn dat alleen/vooral(?) grote Amerikaanse bedrijven met een lage dunk van Europese wetgeving en privacy en aandeelhouders die iedere kan aangrijpen om hun winst te vergroten.