MacOS 11 en iOS 14 ondersteunen dns-over-https en dns-over-tls

De aankomende versies van iOS en macOS krijgen ondersteuning voor dns-over-https en dns-over-tls. Appontwikkelaars kunnen de protocollen toevoegen aan hun applicaties, of nieuwe apps maken waardoor DoH en DoT voor het hele besturingssysteem gelden.

Apple zei deze week tijdens zijn ontwikkelaarsconferentie WWDC dat het van plan is de aankomende versies van het mobiele en desktopbesturingssysteem van de functie te voorzien. MacOS 11 en iOS 14 komen in de herfst uit. Ze ondersteunen dan dus dns-over-https en dns-over-tls als opties om domain name system-verkeer te versleutelen, schrijft ZDnet.

De optie voor DoH en DoT zit niet standaard in de besturingssystemen, maar ontwikkelaars kunnen wel software bouwen waarmee dat mogelijk is via mobile device management-profielen of netwerkextensies. Dat kunnen bijvoorbeeld dns-providers zoals Cloudflare doen. Ook kunnen ontwikkelaars dns-over-https of -tls voor hun eigen apps instellen. Dat laatste moet volgens Apple wel opt-in worden.

Volgens Apple kan het besturingssysteem ook automatisch herkennen wanneer DoH of DoT niet gewenst zijn. Dns-over-https is vooral binnen organisaties onpraktisch. Bedrijven gebruiken vaak hun eigen dns-resolvers. Apples besturingssystemen kunnen straks herkennen wanneer een gebruiker bijvoorbeeld op een vpn van een bedrijf zit, en vervolgens automatisch dns-over-https uitschakelen.

Ontwikkelaars kunnen daarnaast ook zelf regels aanmaken voor wanneer DoH en DoT worden ingezet, bijvoorbeeld wanneer gebruikers op alleen wifi of juist 4g zitten of voor een bepaald type apps.

Apple volgt met de beslissing andere grote techbedrijven die dns-over-https en -tls ondersteunen zoals Google, Microsoft en Mozilla in hun browsers en besturingssystemen. Dns-over-https is controversieel. Het versleutelt het dns-verkeer, maar doet dat wel door het om te leiden naar vaak commerciële partijen als Google of Cloudflare. Tweakers schreef vorig jaar een uitgebreid achtergrondartikel over dns-over-https.

Reacties (123)

[syl765]

Hier een mooie uitleg waarom DoH geen goede optie is. Gesproken door Paul Vixie een van de grondleggers van DNS en zeker niet de minste als het over het internet gaat.
Ook een mooi stukje history van DNS en hoe men steeds probeert om via DNs geld te verdienen.

https://www.youtube.com/watch?v=8SJorQ9Ufm8

De man is niet echt een spreker dus het is even doorbijten maar het is wel helder.
Er zijn dus genoeg opties om je DNS verkeer te encrypten, DoH is niet de manier.
Maar zo gaat het wel vaker, enkele grote partijen drukken het er gewoon door en de meute volgt gestaag.
Does systemd ring any bells?

[Reactie gewijzigd door syl765 op 22 juli 2024 16:11]

[Lennie]

En natuurlijk Bert Hubert van PowerDNS: https://www.youtube.com/watch?v=pjin3nv8jAo

[xCake]

Kan iemand een leek zoals ikzelf uitleggen wat hier goed aan is?

[AtleX]

Privacy. Op het moment is bijvoorbeeld je verbinding met een website negen van de 10 keer beveiligd. (HTTPS) Daardoor weet bijvoorbeeld je provider alleen met welk IP adres je verbinding maakt, maar op dat adres kunnen er tientallen sites gehost zijn. Maar, je apparaat doet eerst een DNS lookup om te achterhalen welk IP adres er bij een site hoort. Die lookup is in 99% van de gevallen totaal niet beveiligd en over het algemeen worden daarvoor ook de DNS servers van je provider gebruikt.

Dat is over het algemeen geen halszaak, maar voor bijvoorbeeld dissidenten en journalisten in minder fijne landen wel. Of, als je verbonden bent met een minder veilig openbaar WiFi netwerk kan iemand dat onderscheppen. En als het onderschept wordt, kan het ook gemanipuleerd worden. Dan verbind je misschien niet met de site van je bank maar met een phising site die je login gegevens onderschept.

Door dit verkeer te encrypten, en bij voorkeur gebruik te maken van een betrouwbare DNS server, ben je dus een stuk minder kwetsbaar qua privacy en veiligheid.

DNS-over-HTTPS voegt in dit verhaal nog een extra stukje beveiliging toe. Je DNS lookups zijn dan voor een derde partij niet meer te onderscheiden van reguliere connecties met een website.

[Reactie gewijzigd door AtleX op 22 juli 2024 16:11]

[loreom]

Dit draagt slechts deels bij aan de verbetering van privacy; inderdaad je ISP kan niet meer zien welke DNS-requests je verstuurd. Echter de aanbieder(s) van DoH of DoT (bijv. Google of Cloudflare) wel.

Daarnaast zijn er allerlei scenario's waarbij DoH/DoT een verslechtering is t.o.v. unencrypted DNS. Denk aan VPN's.

Wachten is op DHCP option/RA om aan de clients in je netwerk een DoH server mee te geven.

[AtleX]

Je hebt volkomen gelijk. Maar als nuancering van je punt is het op dit moment vooral zo dat je zelf je DOH provider kiest bijvoorbeeld. Die aanbieder zal je dan wel op z'n woord moeten geloven, maar het bied in ieder geval keuzevrijheid. En, in het geval van internetproviders in landen met minder vrijheden kan je dan ook kiezen voor een DOH provider in het buitenland. Die valt dan dus niet onder de wetten van je land die potentieel erg nadelig voor je kunnen zijn.

[Reactie gewijzigd door AtleX op 22 juli 2024 16:11]

[NielsFL]

Keuze is een belangrijk voordeel. Maar waarschijnlijk ook een nadeel. We lopen het risico dat een aantal grote commerciëlen met hippe apps de-facto het hele DNS systeem overnemen.

Het is bij ons inmiddels een paar keer voorgekomen dat een website niet werkte via ons netwerk omdat Quad9 in al haar wijsheid had besloten het domein te blokkeren. Waarom vertellen ze niet, behalve dat ze een dozijn diensten gebruiken waar ze de block-lists vandaan halen.

Nu waren die domeinen inderdaad vrij dubieus en was de actie van Quad9 waarschijnlijk correct. Bovendien is het voor ons een fluitje van een cent om de DNS anders te richten. (Quad9 heeft ook een ongefilterde variant bijvoorbeeld.) Niets aan de hand zou je zeggen.

Maar voor de gewone consument is dat anders. Die zal meestal niet eens doorhebben dat het de DNS provider is die een website op zwart heeft gezet. En als ze dat wel hebben, dan zal die niet veel meer kunnen doen dan simpelweg aannemen dat daar een goede reden voor is.

Het is een worst-case scenario, maar het zou zo maar kunnen dat we ons massaal afhankelijk maken van een handjevol "veilige" DNS providers. Die vervolgens niets in de weg staat om domeinen om willekeurige redenen op zwart te zetten.

[Jan-E]

Quad9 heeft ook wel false positives. En soms kun je achterhalen waarom. https://your-covid-19-risk.com (een site die is ontwikkeld door gedragswetenschappers over de hele wereld) werd geblokkeerd door Quad9. Reden: ze vertrouwden allerlei nieuwe sites over Covid-19 niet: https://www.quad9.net/hel...-site-is-getting-blocked/
De argeloze consument die DNS via Quad9 krijgt kon dus ineens niet meer bij een volkomen onschadelijke site. Uiteindelijk hebben de domeinbeheerders Quad9 ervan overtuigd dat de blacklisting ten onrechte was en is de blokkering opgeheven. Maar het geeft wel aan dat "veilige" DNS providers ook nadelen hebben.

[GekkePrutser]

Probeer de tool eens en:
"Application runtime path "/limeservice/installations/3/estimate.your-covid-19-risk.com/userdata/tmp/runtime" is not valid. Please make sure it is a directory writable by the Web server process."

Niet bepaald klaar voor productie

Maar inderdaad het is wel iets met een goede bedoeling en niet iets dat Quad9 zou moeten blokkeren. Je kan trouwens bij Quad9 wel gewon ongefilterde DNS krijgen.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:11]

[Jan-E]

Lijkt ook een DNS-probleempje
https://your-covid-19-risk.limequery.org/100117 werkt wel

Edit De link die jij probeerde werkte tot afgelopen woensdag. Is vermoedelijk een probleem bij de Limesurvey SaaS. Niet direct een DNS-probleem, maar een nginx instelling.

[Reactie gewijzigd door Jan-E op 22 juli 2024 16:11]

[GekkePrutser]

Die link kwam gewoon van de knop op de voorpagina van hun site (die wel werkte). Ik had alleen een deeplink gemaat om het probleem aan te tonen. Overigens doet die knop het nog steeds niet. Die link van jou werkt wel idd.

[xbeam]

Ik krijg van Zscaler een hele andere melding terug.

Website Blocked
Website: www.your-covid-19-risk.com
Reason: Malware site

Wat doet vermoeden dat iets meer aan je hand is met deze site dan alleen de url?

[Jan-E]

Ik weet 100% zeker dat het geen malware site is. De sources staan hier:
https://gitlab.com/a-bc/your-covid-19-risk

Ik heb zelf meegeholpen aan het Limesurvey theme, maar kan de link op https://your-covid-19-risk.com/ niet aanpassen.

Zeer on-topic: van Zscaler had ik nooit gehoord, maar die doen kennelijk ook aan "Internet Threat Exposure Analysis" en zitten dus tussen jou en de website in. Of dat via DoH of DoT gaat is me uit hun site niet helemaal duidelijk, maar het illustreert wel duidelijk dat dergelijke providers veel macht in handen hebben.

[xbeam]

Klopt
Zscaler is onderdeel onze utm oplossing en gebruikt avast AI virus detectie.
Wat ze doen is real time al ons verkeer scannen. Hierdoor wordt iedere ook https/ssl site gedecrypt gescand/gesandboxed op inhoud en dan pas doorgezet naar de gatenway lokaal of remote clients. Het is dus geen dns filter maar echt een inhoud/virus/iets wat niet klopt melding anders wordt hij weergeven als webfilter en kan ik hem withlisten. Maar hij komt nu echt als maleware
Zie screenshot

https://tweakers.net/foto...EUNldLp4eAt9FVMZxF5qr.jpg

Als je bij dit project betrokken bent zal je ze eens contact op moeten laten nemen met avast om de site laten reviewen daar gebeurt dus iets wat ook virus scanners Triggert. Met zcaler heb je wel over veel top 500 bedrijven gebruikers en avast met meer dan 500 miljoen eind gebruikers

[Reactie gewijzigd door xbeam op 22 juli 2024 16:11]

[Jan-E]

Ik laat hem wel checken door Avast als die link naar de eigenlijke tool gefixt is

[Jan-E]

De link naar de tool vanaf https://your-covid-19-risk.com/ werkt weer. Geeft Avast nog steeds een malware melding? Zit daar nog een cache in?

[xbeam]

Ik krijg hem nog steeds, hoelang ze cache weet ik niet maar hier lokaal TTL in iedergeval 0
Ik ben voor je op zoek in de documentatie naar app review upload support link.
Ik heb ergens maar even zoeken

Edit: gevonden zie voor meer info en upload locatie details je Tweakers PB inbox
https://support.avast.com/en-ww/article/228/

[Reactie gewijzigd door xbeam op 22 juli 2024 16:11]

[Dreamvoid]

Groot nadeel van DoH is dat DNS-based adblockers en filtering niet meer werken, ook niet die op je eigen LAN. Ook lokale DNS servers werken dan niet meer, die veel gebruikt worden op intranetten. Flink werk aan de winkel voor admins bij bedrijven om ervoor te zorgen dat de apps op hun LAN geen DoH doen, of alles veranderen naar IP adres (range)-based blocking.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 16:11]

[cranebird]

Huh, je kunt toch een PiHole icm DoH op je Pi draaien? Dat werkt prima. Of zie ik iets over het hoofd?

[Dreamvoid]

De Pi kan wel DoH draaien, maar als de clients zelf DoH draaien richting andere DNS servers helpt het natuurlijk niet meer.

[asing]

Check, dat werkt uitstekend. Ik heb hem hier draaien met CloudFlared.

[WoutervOorschot]

Waarom zou DoH of DoT niet gewoon zoals normale DNS werken, dat zei, je richt als bedrijf gewoon een DNS resolver met https/tls ondersteuning in, en devices gebruiken de default. Ik vind het maar bijzonder dat dit allemaal handmatig ingesteld moet worden (en als het aan Google en Mozilla ligt zelfs per browser ingesteld moet worden).

[lenwar]

Die werken prima. Ze worden hooguit niet benaderd op de manier hoe we het tot nu toe gewend zijn. Als je bijvoorbeel AdBlock Home gebruikt. Dat is een DoH dns-server met advertentieblokkeerfunctionaliteit. (ofwel een goed (beter in mijn ogen, maar dat is een andere discussie ) alternatief voor pi-hole (wat 'slechts' een dnsmasq met een dikke saus is))
Als je je besturingssysteem daar naartoe laat praten heb je het beste uit twee werelden (DoH in je netwerk, met advertentieblokkades) Als je dan vervolgens je dns-server met DoH laat praten richting het internet ben je helemaal klaar.

Als vervolgens je internetverkenner of willekeurige andere applicatie er voor kiest om de DNS-verzoeken niet naar het besturingssysteem te sturen, maar zelf iets te doen (aldanniet geconfigureerd voor/door de gebruiker) dan houdt het op, maar dan houdt het ook op bij de klassieke DNS.

DoH heeft als techniek niets te maken met specifieke aanbieders, anders dan dat er bepaalde aanbieders de eerste waren die het groot/publiek ondersteunen.

[aikebah]

Maar op klassiek DNS zou je dan een firewall de uitgaande DNS requests kunnen laten blokkeren vanaf alle hosts behalve je pi-hole. Met DoH wordt dat toch een stuk lastiger.

[lenwar]

Klopt. Dan moet je een lijstje bijhouden van de bekende publieke DoH-providers en die hard blokkeren eventueel. Dit werkt natuurlijk ook maar gedeeltelijk als je een apparaat hebt die met een onbekende DoH-server wil praten of op een andere poort dan 443. (dit laatste kan ook een probleem zijn met klassiek DNS, al zou je dan nog kunnen proberen met DPI iets af te vangen)

In de praktijk ben ik alleen bekend met twee apparaten die zich niet aan de DHCP-DNS houden. Dat is een Chromecast en de Athom Homey. Beide apparaten gaan ongeacht wat je DHCP-server aangeeft altijd naar de DNS-servers van Google, maar dat biedt natuurlijk geen garantie voor andere apparaten. Dus alleen de DNS-servers van Google blokkeren is dan mogelijk niet voldoende.

[DeevieP]

Dit zorgt net niet voor extra privacy. Aangezien die diensten aangeboden worden door bvb google weet google nu nog meer welke sites je allemaal bezoekt. Het is eigenlijk een alternatief dat ze bedacht hebben als alternatief voor hun tracking-cookies die tegenwoordig niet zomaar meer mogen worden meegestuurd.

Daarnaast weet een isp nog steeds welke sites je bezoekt aangezien de hostname van de site die je via HTTPS bezoekt, te achterhalen is tijdens het opzetten van de beveiligde verbinding.

[AtleX]

Jawel, het zorgt wel voor extra privacy. Als je ervoor kiest om een andere DOH provider dan Google te gebruiken, weet Google dus niet welke site je wil bezoeken. En met ESNI is de hostname header ook bij SNI geëncrypt waardoor je provider alleen nog weet met welk IP adres je verbinding probeert te maken en is ook de informatie over de exacte site die je wilt bezoeken voor hun onbereikbaar. De grote jongens, met eigen IP adressen of ranges, blijven dus wel een heikel punt maar dat is met bijvoorbeeld een VPN via een vertrouwde partij ook op te lossen.

Vergeet niet dat privacy en security geen one-size-fits-all oplossing kennen. Het gaat om laagjes en spreiding.

[Reactie gewijzigd door AtleX op 22 juli 2024 16:11]

[DeevieP]

En hoeveel eindgebruikers gaan met hun chrome browser specifiek kiezen voor een andere DOH provider? Geen enkele bijna. Google leeft van userdata dus ze gaan er alles aan doen om zoveel mogelijk te weten.

Daarnaast is ESNI alweer outdated en heet dat tegenwoordig ECH. Aantal sites is echter heel beperkt.

[cranebird]

Weer een goeie reden om Firefox te gebruiken. Die heeft als standaard cloudflare (=natuurlijk ook een grote aparte partij, maar niet Google)

[Reactie gewijzigd door cranebird op 22 juli 2024 16:11]

[Niosus]

Ik zou Cloudflare niet als grote partij benoemen. Ze zijn een stevige speler op het internet, maar ze in dezelfde adem noemen als Google is toch wel een stap te ver vind ik.

Maar wat belangrijker is dan de grootte, is het business model. Google leeft van de data van eindgebruikers en die gebruiken in hun ecosysteem houden.

Cloudflare is daarintegen volledig onzichtbaar voor eindgebruikers. Je krijgt geen reclame van hun te zien, je gaat nooit hun software installeren en het kan hun eigenlijk zelfs niet schelen of je weet dat ze bestaan.

Cloudflare verkoop diensten aan website beheerders. Ze zijn niets met gebruikersdata want ze kunnen er toch geen winst uit halen. Daarom is hun DNS service meer te vertrouwen.

Maar om eerlijk te zijn denk ik dat de Google DNS in de praktijk ook gewoon oké is om te gebruiken. Google beweert geen data bij te houden voor langer dan een paar dagen, en niet te correleren met je profiel. Ik denk dat ze via hun ads en Analytics genoeg dekking hebben dat de DNS geen toegevoegde waarde heeft.

[LanTao]

Er zijn drie goede redenen om Cloudflare niet te gebruiken als DNS provider.

Ten eerste krijgen ze heel veel data binnen over wat mensen op het internet allemaal doen, welke websites ze bezoeken etc. Hier kunnen ze onbeperkt in grasduinen om te zien welke sites populair zijn die bij grote en kleine concurrenten gehost worden. Als je de privacy policy leest staat er alleen in dat ze data niet wederverkopen; er worden geen beperkingen gesteld aan dit soort praktijken.

Ten tweede valt je browser-verkeer plotseling onder Amerikaanse wetgeving. Buitenlanders hebben geen enkele rechten daaronder. De Amerikaanse overheid kan Cloudflare gewoon opleggen om informatie over willekeurige of zelfs alle buitenlandse DNS requests te overhandigen.

Ten derde kan Cloudflare wel degelijk via bijvoorbeeld TLS session tickets of zelfs eigenschappen van de TCP-implementatie onderscheid maken tussen verschillende devices, waardoor ze meer informatie over eindgebruikers kunnen verkopen aan hun klanten in de vorm van statistieken. Als je de nameserver van je ISP gebruikt dan ben je veel beter verborgen in de massa, het is heel moeilijk om je individueel te traceren omdat de recursor van je ISP de queries in jouw naam doet en in naam van alle andere klanten.

Ten vierde kunnen ze andere CDN's minder goed laten presteren. Er is geen enkel bewijs dat ze dit doen, maar het blijft één van vele bedrijven die security, performance, analytics, caching aanbieden. (Ja, ik schreef eerder drie, maar ik tel dit niet als goede reden.)

Google is met hun DNS-service begonnen omdat ze merkten dat ISP's in sommige landen verplicht werden censuur toe te passen, iets waar Google als search engine vaker dan gemiddeld last van heeft. Waarom is Cloudflare begonnen met hun service? Omdat public WiFi hotspots af en toe gammel zijn? Het is Europese ISP's al niet toegestaan om DNS-gegevens van klanten te verkopen.

[familyman]

Volgens mij is cloudfare begonnen ter ondersteuning van cdn?

[snoopdoge90]

Het lijkt erop dat Cloudflare DNS wel andere richtlijnen hanteert dan hun reguliere services.

Privacy First: Guaranteed.
We will never sell your data or use it to target ads. Period.

We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained a big 4 accounting firm to audit our assertions about our systems annually to ensure that we're doing what we say.

Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t.

https://1.1.1.1/dns/

What makes 1.1.1.1 more secure than other public DNS services?

Some other recursive DNS services may claim that their services are secure because they support DNSSEC. While this is a good security practice, users of these services are ironically not protected from the DNS companies themselves. Many of these companies collect data from their DNS customers to use for commercial purposes. Alternatively, 1.1.1.1 does not mine any user data. Logs are kept for 24 hours for debugging purposes, then they are purged.

1.1.1.1 also offers some security features not available from many other public DNS services, such as query name minimization. Query name minimization diminishes privacy leakage by only sending minimal query names to authoritative DNS servers.

https://www.cloudflare.com/learning/dns/what-is-1.1.1.1/

[K-aroq]

Omdat het niet google is, is het beter? Kan je ook aangeven waarom het beter is? Ik neem aan dat je van beide bedrijven de gebruiksvoorwaarden naast elkaar hebt gelegd en hebt geanalyseerd.

[84hannes]

Ik neem aan dat je van beide bedrijven de gebruiksvoorwaarden naast elkaar hebt gelegd en hebt geanalyseerd.

Daar heb ik mensen voor.

nieuws: Duitse overheidsdienst voor it-beveiliging vindt Firefox de veiligste...


Maar daar buiten zijn de doelstellingen van Firefox en Google natuurlijk totaal verschillend. Firefox is niet gewoon ‘niet Google’, het is een non profit organisatie die ons probeert de beste internetbeleving voor te schotelen in plaats van één advertentiebedrijf.

[Reactie gewijzigd door 84hannes op 22 juli 2024 16:11]

[xbeam]

Google is gedeeltelijk eigenaar van Cloudfare is van in hun overeenkomst gewoon dat ze aan de hoogste bieder verkopen en delen met Google plus overdragen aan de vs.
Google en cloudflare zijn meer met elkaar verweven dan vele door hebben
https://www.cnbc.com/2019...ion-with-crowdstrike.html

Alphabet’s first big win in security. It also had a small stake in Zscaler, which went public last year, and is an investor in pre-IPO vendor Cloudflare.

Je dns inbakken in de browser betekent voor je privacy
DoT= Dns over Trump
Doh= DNS over hoogste bieder

Het is voor je privacy en beveiliging belangrijk dat je zelf kan bepalen welk bedrijf wel en niet je privacy toe vertrouwt.

[Reactie gewijzigd door xbeam op 22 juli 2024 16:11]

[cranebird]

Bedankt voor de info, ik krijg altijd de rillingen van dit soort vervlechtingen. Jammer dat je ook je eigen provider niet goed kunt vertrouwen tegenwoordig (die verkopen dit soort info ook door).

Ik vraag me soms af wat beter is voor je privacy: alles juist door het buitenland laten lopen of juist niet. In NL zit alles veel dichter om je heen (dus de afgeroomde data levert hen meer op).

[xbeam]

amerkaanse providers verkopen dns info over hun gebruikers.
voor nederlandse providers is dit vooralsnog onder gdpr verboden

[Lennie]

Chrome gebruikt niet Google DNS, Chrome heeft alleen DoH mogelijkheid, die niet ingesteld is.

Dat lijkt ook het plan te zijn om dat zo te houden.

(Waarschijnlijk omdat men anders een EU oid. achter de broek krijgt vanwege monopoly/privacy, etc.)

[WoutervOorschot]

Het kan zorgen voor extra privacy, maar in huidige uitvoering is het ook vooral invloed kapen door bijvoorbeeld Google. Nederlandse providers hebben grotendeels een goede geschiedenis omtrent privacy en beveiliging. Om je dns zomaar bij een ander bedrijf te leggen ‘want het is veiliger’ is kort door de bocht.

Er kan niemand tussendoor meer meelezen, maar in ruil daarvoor ‘geef’ je je dns-data aan het bedrijf die het resolved.

Ik vind het vooral gek dat providers hier het nog niet gewoon zelf aanbieden, en het OS dat gewoon automatisch meeneemt. Misschien dat het niet mag gezien DNS blokkades (piratebay) wettelijke dingen zijn in NL?

[Lennie]

Daarom gaat Firfox die ook standaard niks veranderen aan de situatie voor mensen in Europa.

[unreal0]

Je moet hoe dan ook voor 1 provider kiezen, en die weet in 1 klap alles. Het is absoluut niet goed Kwa privacy

[xCake]

Enorm bedankt voor je uitleg! Ik snap het nu volkomen.

[themibur]

Dat is niet geheel waar. Wanneer je browser een https sessie opbouwt dan request het de host in plain text voordat het een certificaat aangeboden krijgt. Kip/Ei probleem. Je ISP kan altijd achterhalen waar je naar toe gaat door simpel de http headers uit te lezen.

DoH/DoT voorziet enigszins in extra privacy, met het grote probleem is dat er te weinig DoH/DoT servers zijn, en die enkele die betrouwbaar zijn hebben amerikaanse eigenaren, zoals Google, Cloudflare, Quad9, wat ook je laatste argument achterhaald.

Ik zit er niet op te wachten als mijn iphone buiten mijn eigen DNS server (met filter) om gaat lopen resolven en ik blokkeer dan ook DoH/DoT. Dat gezegd hebbende, je kan uitstekend zelf DoH/DoT gebruiken om filters te omzeilen van publieke gast netwerken voor dat beetje extra privacy. Zolang je maar beseft dat de eerste de beste NextGen firewall een prima lijstje kan ophoesten waar jij mee verbind.

[DiedX]

Sni lost dat op.

[themibur]

Incorrect.
Wanneer ik connect naar 1 van mijn websites achter HAProxy, beveiligd met SNI/Let's encrypt dan onderschept fiddler doodleuk:

CONNECT www.ha<censuur>.nl:443 HTTP/1.1

Hoe kan anders HA Proxy achterhalen welk certificaat hij moet presenteren? Daar speelt SNI idd ook een rol maar het start allemaal met een clear text http 1.1 CONNECT message.

[Lennie]

Bijna goed. Encrypted certificates (zit in TLS/1.3) en encrypted SNI en lost dat op.

[Verwijderd]

Mag ik vragen hoe je DoH blokkeert, zonder al je gewone HTTPS verkeer te blokkeren? Werken beiden over poort 443 en gebruiken HTTPS, dus het is mij niet duidelijk hoe je dit op firewall niveau blokkeert (zou het het thuis ook graag doen namelijk).

[themibur]

Ik gebruik pfSense en een filter die poorten 443 (DoH) en 853 (DoT) dichtzet maar de target is een alias list die ik vul met DNS namen en ip nummers van welbekende providers. hier staat een lijst: https://dnsprivacy.org/wi...+Privacy+Public+Resolvers
Niet compleet waterdicht maar op dit moment is het aanbod nog zeer schaars dus te doen.

Daarnaast poortNAT ik uitgaande requests naar poort 53 en redirect deze naar mijn eigen unbound server. er zijn zat IOT devices die hardcoded eigenhandig servers kiezen (Chromecast bijv) en zo houd ik controle.

Unbound server is gefilterd met PfblockerNG (Pihole variant) en deze resolved recursive (zonder forwarders) over enkele VPN tunnels. Na enig testen met DoH/DoT ben ik hierop teruggevallen, de prestatie/privacy verhouding is prima zo.

[Dreamvoid]

Je kan de IP adressen van de DNS servers blacklisten.

[Lennie]

Het certificaat wordt in TLS/1.3 encrypted en SNI encryptie (Client Hello Encryption) wordt aan gewerkt door IETF.

Zeer waarschijnlijk is voor SNI encryptie een DNS aanvraag nodig om een public key op te vragen, oid. Vandaar dat Encrypted DNS eerst nodig is.

[BugBoy]

Je ISP ziet nog altijd het IP adres, dus het is wel deels schijnveiligheid. Voor journalisten is een VPN een veel betere optie.

[Lennie]

Het gebruik van een VPN kan op zich zelf al verdacht zijn.

De oplossing is om het verkeer van iedereen het zelfde te doen lijken.

Domain Fronting is mogelijk een veel betere oplossing:

https://datatracker.ietf....i-encryption-09#section-4

[lenwar]

Het gebruik van een VPN kan op zich zelf al verdacht zijn.

Dat valt in de praktijk (in Nederland) heel erg mee. Ik kan me zo voorstellen dat het merendeel van de mensen die thuiswerken middels VPN naar het bedrijfsnetwerk gaan.

Indien journalisten echt iets 'te verbergen hebben' (niet in kwade zin, maar vanuit hun beroep) kunnen zij denk ik beter naar een groot publiek access point gaan (opgaan in de menigte) en vanaf daar met TOR-achtige constructies het internet op gaan.

[Lennie]

I had het natuurlijk over het buitenland, er zijn landen waar het wel een probleem is. Niet in NL, daar kijkt niemand naar om.

[Fermion]

Het gaat niet zozeer om dat iemand je DNS stream afkijkt, want de beheerder van een DNS server zoals Google (8.8.8.8) of van je eigen ISP zien op de server zelf jouw requests voorbij komen en instaat de informatie te gebruiken (bij Google zal dat vast wel zo zijn). Bij DNS security is het belangrijker het tegengaan van:

- Man in the Middle aanval: het onderscheppen van jouw DNS request en een ander antwoord (IP) daarvoor terug sturen.
- Gecompromitteerde DNS servers (gehackte DNS servers): het herkennen van niet legitieme answers omdat er geknoeid is met zone files.
- Het tegengaan van informatie lekken (DLP) via DNS.

Met het alleen toevoegen van encryptie op DNS verhoog je weinig qua veiligheid.

[Munchie]

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

[Lennie]

Ik denk dat iedereen het wel eens is dat encrypted DNS-queries goed is, het probleem is met hoe kunnen we het invoeren op zo'n manier dat we het zo snel mogelijk krijgen zonder dat we de privacy erger maken voor mensen door hun DNS alleen bij Google/Cloudflare, etc. neer te zetten.

Het gaat bijvoorbeeld jaren duren voordat Windows/Mac/Linux (iOS/Android) en de het modem in het LAN de juiste updates hebben gehad zodat we DNS over TLS kunnen gebruiken

[Reactie gewijzigd door Lennie op 22 juli 2024 16:11]

[GeforceAA]

Je kan het achtergrondartikel lezen dat ze hebben gelinkt.

[BeepBoop]

Privacy.

Het originele DNS-protocol voorziet niet in vertrouwelijkheid. Dat wil zeggen dat iedereen die DNS-verzoeken kan onderzoeken kan zien welke namen je opvraagt. En welke namen je opvraagt zegt heel veel over je surfgedrag; zo zou iemand kunnen zien of je op zoek bent naar een nieuwe liefde op basis van DNS-verzoeken voor bijvoorbeeld ‘tinder.com’

[Luuk2015]

Op het moment dat je bijvoorbeeld naar Google.nl navigeert dan doe je een verzoek bij een DNS server die dan het IP geeft voor Google.nl.
Deze verzoeken worden grotendeels niet versleuteld gedaan, je kan dus exact zien voor wat voor site er een verzoek is gedaan. Met DNS over HTTPS/TLS worden deze verzoeken versleuteld.
Apple heeft nu deze 2 protocollen toegevoegd in de nieuwe macOS/iOS.
Correct me if i'm wrong ;-)

[ehvc]

Waar wordt dan beslist welke DNS je gebruikt.
Kan een bedrijf niet de DNS server zelf hosten voor de DNS over HTTPS?

[johnkeates]

in macOS is een systeem met de naam "System Configuration" verantwoordelijk voor een aantal low-level onderdelen, waaronder DNS.

Binnen DNS zijn er al meerdere systemen aanwezig met prioriteitsvolgorde en controle op bereikbaarheid, type, on-demand vs. always-on, manual vs. auto, local vs. direct etc.

Als je dan op een willekeurig systeem "scutil --dns" uitvoert krijg je de lijst met de resolvers, eigenschappen, en bron, met ook een lijst van de resolver die daadwerkelijk gebruikt kan worden. Zo kan je bijv. by default een lijst met 7+ resolvers terugkrijgen waarbij op een non-IPv6 netwerk al een groot aantal als niet-bereikbaar aangemerkt staan en overgeslagen worden tijdens normaal gebruik. De default resolver die bij mij terug komt (via DHCP aangeleverd) heeft als eigenschappen "0x00020002 (Reachable,Directly Reachable Address)". Als je dan DoH en DoT zou toevoegen zou zo'n entry ook met dezelfde flags wel of niet in de pool terecht komen. Afhankelijk van de volgorde kan je dan verwachten dat als zo'n resolver beschikbaar is, en hoger staat dan de klassieke insecure resolver dan zal je die gebruiken. Valt zo'n resolver weg, dan wordt de eerstvolgende resolver gebruikt die wel beschikbaar is.

De resolvers (inclusief DNS-SD/mDNS) worden op basis van reachability en netwerk triggers (kabel er in/uit, WiFi aan/uit) bijgehouden. Als er een resolver request gedaan wordt zal er in 99% van de gevallen dus de 'beste' optie gekozen worden zonder eerst te wachten op een timeout of iets dergelijks. Je hebt nog steeds dat als alles werkt en een resolver mid-request offline zou gaan je wel die timeout hebt en een failover naar de eerstvolgende resolver, dat is ook hoe dat klassiek gebeurde.

[Blokker_1999]

Bedrijven kunnen kiezen voor de klassieke DNS. Zowat alle resolvers, en ik hoop dat Apple het ook doet, gaan nakijken of een bepaald domein geresolved kan wordn via klassieke DNS. Als dat het geval is, dan zal DNS-over-HTTPS niet gebruikt worden.

[Montaner]

Je haalt het een en ander door elkaar... Apple heeft geen ‘resolver’. De software kan straks kiezen voor een protocol welke wel of niet beveiligd is, bij het benaderen van de resolver welke jij via DHCP hebt ontvangen of zelf hebt ingesteld.

Je hoopt dus dat Apple kiest voor het onveilige protocol zodra het een resolver benadert.. beetje vreemd als je het mij vraagt. Misschien zolang het nog geen gemeengoed is.. maar hoop dat straks dus wel by default het veilige protocol gebruikt wordt.

[Lennie]

Je moet het zo zien: dit is een eerste stap in het beveiligen van alle stappen, we hebben 100% zeker de problemen nog niet opgelost. Maar:

Als alles HTTPS/IMAPS/POP3S/SMTPS, etc. gebruikt en we certificates checken en we hebben DNS encrypted zelfs als het gaat naar een partij die we niet willen (publieke WiFi en attacker heeft eigen DNS server). Dan wordt het al heel lastig om niet opgemerkt te worden als de aanvaller het verkeer naar andere IPs gaat sturen van die zullen niet de juiste certificaten, etc. hebben.

HSTS helpt daar bij om te voorkomen dat men sites als google.com niet alleen via HTTP bezoekt en nooit redirect naar HTTPS. Dat is iets dat een aanvaller zo kunnen regelen want het is iets dat veel mensen mogelijk niet eens zou opvallen in de balk boven in de browser (vooral op mobiel is dat niet altijd in beeld).

Als DNS over HTTPS gaat is dat nog een certificate check. Als je die via DHCP van een aanvaller krijgt,... tja, wat we kunnen doen is weergeven in het OS: "u bent nu verbonden met wifi.bedrijfsnaam.nl" Dat wordt al stuk lastiger om te faken door aanvaller.

Zo kunnen we iedere keer iets betere stappen ondernemen.

[Lennie]

In het kort::ja

[Verwijderd]

"Volgens Apple kan het besturingssysteem ook automatisch herkennen wanneer DoH of DoT niet gewenst zijn."

Vervelend dat de gebruiker als hij/zij kiest voor DoH door het Os overruled kan worden, weet je nooit zeker of je DoH gebruikt of niet.

[Dreamvoid]

Dit moet ook kunnen op OS-level, anders wordt het wel erg moeilijk voor enterprise admins, ook ivm lokale DNS servers. Met een group policy de boel uitzetten op alle clients is erg gewenst.

[Lennie]

Correctie: Met een group policy de boel instellen op de juiste DoH or DNS over TLS DNS servers op alle clients is erg gewenst

[Dreamvoid]

OK maar wat heeft DoH voor een lokale DNS op je LAN voor voordeel?

[Lennie]

Encrypted en ook authenticated (zodat je zeker weet dat je met zelfde DNS server praat en niet een immitatie van aanvaller met WiFI punt met zelfde naam en beter dan WiFi encryptie.

En natuurlijk: wat dacht je van een HTTPS verbinding naar een router thuis met DoH die je met je laptop van overal te wereld gebruik van kunt maken ?

Ik heb gemerkt niet alle DNS over TLS implementaties checken ook het cert, want de naam is niet altijd meegegeven

[Reactie gewijzigd door Lennie op 22 juli 2024 16:11]

[Anoniem: 1301524]

Anders worden ads in applicaties door je strot geduwt of heb je als sysadmin geen grip op ads (die met louche ads netwerken communiceren)

[JackBol]

Als gebruiker heb je toch beheersrechten over je OS? Lijkt me juist een extra mate van zekerheid. Ongeacht wat de app doet, kan het OS wat je zelf onder controle hebt, dit beheren.

Tenzij je laptop in een corporate AD zit, maar dan heb je sowieso al te luisteren naar je IT beheerders.

[Dreamvoid]

Idd maar die willen graag 1x DoH uitzetten per OS, niet voor elke applicatie individueel.

[lenwar]

Dat is in de praktijk natuurlijk niet te doen. Iedere applicatie kan geschreven worden om z'n DNS-verzoek niet aan het OS te doen, maar zelf naar een willekeurige DNS-server te gaan. (op een willekeurige poort in het extreemste geval). Dat staat los van DoH.

[Dreamvoid]

Maar hoeveel sysadmins laten toe om dat soort applicaties te installeren?

[lenwar]

Als 'de business' specifieke applicaties nodig heeft, delft de sysadmin meestal het onderspit (althans, dat is mijn ervaring). Echter zie je in de praktijk (zover ik weet) dat de meeste (alle?) applicaties die bedrijfsmatig nodig zijn, niet de moeite nemen om zelf DNS-verzoeken te doen. Maar de wat meer 'vage' tools die al dan niet geïnstalleerd moeten worden (ook Portable applicaties kunnen dit natuurlijk) heb je nu ook al weinig controle op. Dit "probleem" staat dus los van DoH.

[iworx]

Heeft vooral te maken met de bereikbaarheid van die DoH of DoT servers. Stel dat je ze activeert en je komt op een hotel wifi terecht die alles eruit filtert voor je aangemeld bent op de captive portal -- in dat geval vallen de OS'en terug op de lokale DNS tot ze aan de DoH/DoT kunnen. Niet meer, niet minder.

[guillaume]

Volgens Apple kan het besturingssysteem ook automatisch herkennen wanneer DoH of DoT niet gewenst zijn. Dns-over-https is vooral binnen organisaties onpraktisch. Bedrijven gebruiken vaak hun eigen dns-resolvers. Apples besturingssystemen kunnen straks herkennen wanneer een gebruiker bijvoorbeeld op een vpn van een bedrijf zit, en vervolgens automatisch dns-over-https uitschakelen.

Erg netjes van Apple. Dit is precies waarom ik het gedrag - zoals ik het heb begrepen - van bijvoorbeeld Firefox niet waardeer: ik zit op een VPN, dus voor mij is geforceerd gebruik van DNS-over-HTTPS van een andere service juist een extra privacy-risico. Zie ook reviews: Dns-over-https - Meningen verdeeld over encryptie dns-queries

[Reactie gewijzigd door guillaume op 22 juli 2024 16:11]

[TijsZonderH]

Firefox was de eerste grote partij die DoH op grote schaal toepaste, maar je ziet nu dat ze wel echt veel kritiek krijgen op hun alles-of-niets-implementatie. Dan doet Google dat toch een stuk beter met een soort opt-in, al kun je vraagtekens zetten bij de keus voor Googles eigen dns-dienst.

[guillaume]

Jup, plus het past mijns inziens ook totaal niet binnen het beeld van Firefox om de mensen zoiets door de strot te duwen, al valt inmiddels wellicht wel te stellen dat zo ongeveer alles van de oorspronkelijke filosofie van Firefox, dat wat de ietwat technischer aangelegde gebruiker bond, compleet teloor is gegaan.

[TijsZonderH]

Het is een heel Amerikaans cultuurding. In de VS is je provider veel minder te vertrouwen en ze verkopen je gegevens door. In Nederland blijven providers veel meer van ons internetverkeer af en dus vertrouwen we ze meer. In de VS is het dan ook ook logisch te zien dat ze het privacyaspect verleggen, hier in Nederland een stuk minder.

[Dreamvoid]

Dit inderdaad - hier heeft een ISP zich aan allerlei privacy regels te houden. Een Cloudflare of Google DNS server in de VS (of ergens anders) waar je gegevens met DoH naartoe gaan valt niet onder onze privacy wetten.

[Reactie gewijzigd door Dreamvoid op 22 juli 2024 16:11]

[familyman]

Strikt genomen wel.... het betreft elk individu dat zich in Europa bevindt.

[lenwar]

Dat doen ze zeker wel. Als zij zich niet aan de Europese wetten kunnen of willen houden moeten zij Europese gebruikers blokkeren. (even los van hoe goed dat technisch gezien te doen is).
Je ziet het al bij al die niet-EU websites die EU-gebruikers cookie-banners laten zien. Als je vanuit de Canada naar diezelfde sites gaat krijg je ze veelal niet. (afhankelijk van hoe lui de siteontwikkelaar was)

Er zijn ook websites die geblokkeerd zijn voor EU-gebruikers omdat ze niet aan de AVG-regels kunnen/willen voldoen zoals de New York Daily News, Orlando Sentinel of Baltimore Sun (drie (grote?) kranten in de VS)

[guillaume]

Klopt, dat was ik even vergeten. Dan blijven er nog steeds wel twee vragen staan wat mij betreft:

1. Blijft het wel bij het als standaard instellen voor de VS? Het kan ook slechts de eerste fase zijn.
2. Heeft zo'n verandering in je verbinding wel een plaats in je browser, of dient het uitsluitend een optie van je OS te zijn? Je browser heeft niet de mogelijkheid vast te stellen of je verbinding via een VPN verloopt, dus dit kan al snel voor problemen zorgen (bij verschillende VPN-providers zie je die al tevoorschijn komen in de vorm van meldingen over DNS-leaks waarbij de mensen geen idee hebben wat er aan de hand is).

[Lennie]

Je moet bedenken het wordt in de VS gebruikt, niet in NL.

[guillaume]

Heb je helemaal gelijk in (ik wist het wel, maar was het even vergeten).

[Lennie]

Ik ben blj dat er voortgang is, hopelijk komt het DNS verkeer nu straks ook op de juiste plek waar de mensen het willen hebben. :-)

We zijn best dicht bij om alles encrypted te hebben:
- bijna alle websites/mailservers, etc. gebruiken nu HTTPS/IMAPS/SMTPS, etc.
- certificate encryption (zit in TLS/1.3)
- DNS encryption DNS over TLS of HTTPS

Dan houden we er nog 1 over: SNI, daar wordt nog aan gewerkt.

1 van de ideen is: doe een extra DNS request om te weten hoe je encrypted SNI kunt doen met een website.

En daarvoor is natuurlijk encrypted DNS eerst nodig.

[guillaume]

True, dat zijn ook wezenlijke verbeteringen. Ik denk echter dat een DoH-optie geen plek heeft binnen een browser, maar door je OS moet worden aangeboden. Je browser heeft niet de mogelijkheid vast te stellen of je verbinding via een VPN verloopt, dus dit kan al snel voor problemen zorgen (bij verschillende VPN-providers zie je die al tevoorschijn komen in de vorm van meldingen over DNS-leaks waarbij de mensen geen idee hebben wat er aan de hand is).

[Lennie]

De reden voor de browser is simpel: snelheid, niet in werking, maar in deployment.

Hoe lang gaat het duren voor dat het OS dat je hebt DNS encryptie ondersteund ?

En hoe lang gaat het duren voordat het netwerk waar je aan verbonden bent het ook ondersteund ?

Ik denk dat misschien wel mooi is: een OS API die de browser vertelld: ik doe al DNS encryptie, dus jij moet het niet meer doen ?

We kunnen het natuurlijk eens of oneens zijn over de snelheid van handelen opweegt tegen het risico dat we een complexiteit toevoegen en potentieel zelfs politiek bedrijven. Maar door andere mensen was die keus al gemaakt. Ik denk wel dat de meensten, zo niet allen, die er bij betrokken waren 'good intentions' hadden, maar dat betekend nog niet dat achteraf blijkt de foute keus te zijn.

[Reactie gewijzigd door Lennie op 22 juli 2024 16:11]

[guillaume]

Toch vind ik dat dit naar halfslachtigheid riekt: een feature implementeren op een niveau waar het niet thuishoort, omdat dit inherent voor nieuwe problemen zorgt, met als reden dat het simpelweg eerder naar de eindgebruiker te pushen is, dat is niet de juiste weg. In die zin pakt Apple het dus wél goed aan door het te implementeren op het juiste niveau, waarmee het rekening kan houden met een belangrijke issue. Daar staat tegenover dat Mozilla het ook veel beter had kunnen aanpakken door de gebruiker expliciet de keuze te laten maken: "Ja, ik wil via DoH de websites die ik bezoek beter afschermen van mijn provider" of "Nee, ik gebruik (soms) een VPN-verbinding en wil DNS-verzoeken overlaten aan het systeem". Nog beter zou zijn om DoH te kunnen "whitelisten" bij gebruik van de IP die je krijgt van je provider, dat is dan ook een redelijke workaround.

[Primuszoon]

al kun je vraagtekens zetten bij de keus voor Googles eigen dns-dienst

Dit dus. Zo kan Google naast cookies of andere tracking zaken nu ook nog gaan volgen naar welke websites je surft en je nog meer profileren.

Klinkt voor de ene misschien als muziek in de oren zodat Google nog beter aansluit bij je internetgebruik, maar voor mij is het eerder een horror verhaal.

[grote_oever]

Kan iemand mij uitleggen wat voor gevolgen die heeft voor Pihole? Want ik zag een stuk op Reddit wat best technisch is. Volgens mij ondersteund Pihole sinds 5.0 dns-over-https en zou dit niet z’n probleem moeten zijn. Echter zag ik daar reacties tussen die aangaven dat dit een negatief effect heeft op Pihole.

[Xander2]

Browsers/clients met DNS-over-HTTPS moeten verbinding maken naar je Pihole in het lokale netwerk; dat is vervelend omdat deze dan een SSL certificaat nodig zal hebben terwijl deze meestal achter de router hangt en dus geen publiek vast IP heeft wat nodig is voor het certificaat.

Het stuk dat de pihole zelf resolved/forward voor queries (dns/dns-over-https) staat hier los van.

[iworx]

Je hebt geen publiek IP nodig voor een SSL certificaat. Simpele CSR, DNS entry en je bent vertrokken. Ik draai de tegenhanger van PiHole hier thuis - Adguard Home - en daar heb ik mijn wildcard certificaat in opgeladen. Works like a charm.

[Dreamvoid]

PiHole zelf doet wel DoH en dat is leuk, maar dat staat verder los van dat clients met DoH buiten de PiHole om hun DNS queries gaan doen. Alle adblocking werkt dan niet meer.

[1superheld]

Apple in Mac OSX 11, Windows 10 (waarschijnlijk) eind van het jaar, support van DoH / DoT begint goed te worden! Denk dat dit winst is voor ons allemaal.

[Berten..]

Het gebruik van DNS-over-TLS en DNS-over-HTTPS zal ook een impact hebben op legitieme toepassingen. Bijvoorbeeld voor captive portals die gebruik maken van DNS hijacking voor client authenticatie.

[Dreamvoid]

En lokale DNS servers, zoals op de meeste bedrijfs intranetten.

[GekkePrutser]

Dat is waar, maar het is natuurlijk ook wel zo dat captive portals een smerige truc zijn die veel nadelige effecten hebben. Zoals niet goed werken als je HTTPS url's invoert. En detectie van bijvoorbeeld iPhones die wel werken bij verbinding met een nieuw netwerk maar niet als de hotspot authenticatie halverwege het gebruik 'dichtklapt'. Eigenlijk is het gewoon een ranzige MITM aanval. Ik zou mijn protocol ook niet aanpassen om zulke trucs te laten werken.

Liever gebruiken ze een doordachte techniek zoals Hotspot 2.0 in plaats van zo'n ranzige workaround.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:11]

[iworx]

Wanneer iOS merkt dat er URLS gehijacked worden dan geeft ie dat ook weer in de interface -- ala : Dit netwerk is onveilig omdat het je DNS requests probeert te onderscheppen / herschrijven.

Je ziet browsers dit al vaker doen -- ik heb me ooit rot gezocht naar een applicatie die de meest rare subdomeinen probeerde te requesten op mijn netwerk -- bleek het Chrome die zocht naar DNS hijacks.

[Lennie]

Het is goed om aan de gebruiker te melden dat er smerige dingen worden gedaan voor een captive portal.

Maar daar is ook een nette oplossing voor: er is een speciale DHCP parameter geloof ik die je kunt gebruiken om aan het OS duidelijk te maken dat het om een captive portal gaat en welke URL het is.

Ik heb dit al wel eens zien werken in praktijk.

[Reactie gewijzigd door Lennie op 22 juli 2024 16:11]

[Snelletomaat]

Kan iemand dit voor mij verhelderen? In mijn beleving geeft DoH/DoT eerder een verplaatsing van het privacy-issue.

Bij DoH of DoT omzeilt de applicatie de lokale DNS, waar filtering op kan zijn toegepast zoals het blokkeren van trackers omwille van privacy. Via DoH of DoT staat zo’n lokale DNS buiten spel begrijp ik. Dus de winst is dat iemand het DNS-verkeer tussen mij en mijn provider niet in kan zien. Maar ik haal wel Facebook en andere trackers gelijk weer naar binnen omdat ik ze niet meer kan blokkeren. En ik kan er niets tegen doen wanneer de app-ontwikkelaars zelf mogen bepalen of ze DoH/DoT willen gebruiken. DoH en DoT tegenhouden lijkt me niet heel eenvoudig.

Of maak ik een denkfout?

[iworx]

Je beslist zelf welke DNS server je gaat gebruiken -- zolang die maar encrypted is. Als jij je PiHole op die manier opzet dan ben je nog altijd volledig secure, je ads & trackers worden nog altijd geblocked. 't is gewoon een andere standaard/poort boven op je vertrouwde resolver.

[robert_paats]

Op zich is er niets mis met DoH of DoT, het probleem zit in de manier waarop het geïmplementeert lijkt te gaan worden.

Op dit moment gaan mijn DNS query's naar de DNS van mijn lokale telecom provider die er niets mee mag doen behalve de vraag beantwoorden. Dit is dankzij lokale telecom wetgeving.

Bij de huidige DoH en DoT implementaties gaan die query's naar Google, Facebook en dergelijk in de US die er vervolgens een data harvesting party van maken omdat privacy wetgeving niet echt bestaat daar.

Als het nou gewoon DNS over TLS richting mijn lokale ISP is of een andere bestemming waar ik mee instem dan heb ik er niet echt een probleem mee.

[Snelletomaat]

@robert_paats en @iworx , dat wordt dus afwachten of je zelf nog beslist welke DNS server er voor DoH gebruikt wordt. Begrijp ik dat goed? Ik had begrepen dat de applicatie dit zelf kon gaan bepalen. En dan is de data harvesting volgens mij niet tegen te gaan.

[iworx]

Facebook of Google gaan geen DoT of DoH "verdekt" kunnen opstellen in hun apps. Je hebt er een entitlement voor nodig. Deze zijn bedoeld voor de gekende DNS / VPN providers. In hun apps vink je dan aan "Ja, ik wil DOH" en dan wordt achterliggend die optie aangezet.

Het is niet zo dat om't even welke app zelf hun eigen DNS server gaan kunnen opdringen.

Voor de toestellen die onder beheer van je werkgever vallen kunnen die algemeen geactiveerd worden door middel van een MDM profiel of als je zelf wat handig bent via Apple Configurator profielen.

[joo5ty]

Dit is het einde voor google analytics toch? Als je alle Apple devices aan informatie gaat missen, dan kan je slecht conclusies trekken op halve informatie?

[LanTao]

Waarom zou dit het einde van Google Analytics zijn? Dat is gewoon een blob JavaScript dat bij een webpagina geladen wordt. Of iets dat ingebouwd wordt in een native app via een SDK. Een HTTP request blijft een HTTP request, alleen het gebruikte transport om het IP-adres van een server te achterhalen kan veranderd worden van stateless, unencrypted UDP naar TCP + TLS.