Om er voor te zorgen dat niet stiekum informatie weglekt over websites die hier in huis worden bezocht, wordt al het verkeer naar UDP poort 53 en TCP poorten 53 en 853 op de router naar de name servers van Freedom gedirigeerd. Alleen Freedom en ik kunnen dus op deze manier nagaan van welke sites het aannemelijk is dat ze bezocht worden.
Maar voor DoH werkt dat dus niet zo eenvoudig.In de eerste plaats kan een DoH server in de applicatie vast zijn ingesteld en kan ik het dus niet wijzigen. In de tweede plaats ken ik het DNS verkeer nu niet meer onderscheiden van het overige http verkeer. Voor browsers is een DoH server nog in te stellen en/of aan te passen maar voor veel applicaties kan dat niet.
Kan hier verder iets aan gedaan worden? Maak ik me misschien druk om niets?
Een van de hoofdredenen van de ontwikkeling van DoH was juist de Amerikaanse providers die verdienen aan DNS logging, dus DNS verkeer âlangsâ de provider âsmokkelenâ. Dus daar loop je nu een beetje tegenaan.
Maar je bent niet de enige met zorgen over waar de logging dan wel heen gaat: Centralised DoH is bad for Privacy, in 2019 and beyond.
Van welke applicaties weet je, dat ze gebruik maken van DoH ?
Wat je benoemd zijn inderdaad veelgehoorde bezwaren tegen DoH. Ik ken voornamelijk de mozilla applicaties als DoH gebruikers, en dan vind ik het op zân minst bijzonder dat een applicatie besluit de systeembrede DNS instellingen te negeren en zelf voor DoH client gaat spelen. Zeker in zakelijke omgevingen is het nog vervelender: Voor de gebruiker âwerkt het nietâ als die interne systemen probeert te benaderen omdat de publieke DoH server de interne namen niet kent, voor de organisatie is het vervelend omdat interne namen lekken naar een publieke dienst.
Ik ken twee manieren om DoH tegen te gaan:
- BIj firefox staat het gewoon onder je instellingen (Privacy & Security â DNS over HTTPS), dit is het simpelst maar moet je per applicatie instellen.
- Er is een âcanary domainâ use-application-dns.net, als hierop een NXDOMAIN response terug komt zal DoH uitgeschakeld worden (dit is meer bedoeld voor grotere netwerken, het zal voor de meeste thuisgebruikers lastig te implementeren zijn). Mozilla producten luisteren hiernaar, geen idee of dit een bredere standaard is.
BTW er zitten tegenwoordig ook uitbreidingen in de HTML standaard aan âa hrefâ en andere links waarbij een logging dienst wordt aangeroepen vlak voor een link gekozen wordt. Ook lastig als de host niet heel anders is.
Daarom is een filter zoals uMatrix ook handig die alles kan na kijken vlak voordat iets gebruikt dreigt te worden).
Nee, dit is geen standaard, zoals ze ook uitleggen op hun support pagina over Canary domain (en).
Chromium gaat de use-application-dns.net in ieder geval niet ondersteunen, volgens hun DNS over HTTPS pagina.
Het vervelende is dat ik dus niet precies weet welke applicaties het zijn.Het is me toevallig een keer opgevallen dat er https requests gaan naar Google name servers (8.8.4.4, 8.8.8.8, 2001:4860:4860::8844 en 2001:4860:4860::8888) vanuit het WLAN, terwijl ik deze nergens heb ingesteld. Ik verdenk sterk onze Android telefoons.
Ik doe doel-NAT voor de Google name servers naar die van Freedom en bij het checken van het log zag ik dat er ook requests over TCP poort 443 worden gedaan; die gaan natuurlijk niet werken, tenminste niet zonder certificaatfout (die ik overigens al die tijd nergens heb gezien).
Blunder alertâŠ
De https calls naar de Google name server kwamen van mijn webradio: een van de presets was daar naar ingesteld 
⊠Ik heb dat aangepast en nu is het opgehouden. De soep werd dus weer niet zo heet gegeten als ze werd opgediendâŠ
Maar mijn bezorgdheid blijft. Applicaties kunnen onveranderbaar zijn ingesteld om een DoH server te gebruiken die niet mijn keuze is. Dan kan ook voor âgewoneâ DNS, maar dat is in ieder geval te detecteren en vaak op te lossen. Voor DoH is dat veel moeilijker. Ik snap dat het prima werkt om ISPâs te bypassen maar ik heb meer vertrouwen in mijn ISP dan in de grote tech-jongensâŠ
Als DoH in een applicatie gewoon in te stellen is en/of deze de systeeminstelling hiervoor gebruikt dan is er niets aan de hand.
Als een Applicatie een eigen nameserver gebruikt dan is dat in mijn ogen al slecht. Maar als dat op de normale manier gaat dan is dat in ieder geval te zien omdat het zich niet verbergt in https verkeer.
De Facebook app op Android doet https calls naar dns.facebook.com over IPv6 (2a03:2880:f080:e:face:b00c:0:2). Het heeft er vanwege de hostnaam alle schijn van dat het om DoH gaat. Maar als dat wat minder duidelijk is, bijvoorbeeld als voor DoH dezelfde host wordt gebruikt als het overige https verkeer dan wordt het vervelend.
Nu zul je je afvragen waarom het een probleem is, immers, Facebook weet al op welke links ik klik. Dat is maar ten dele zo, als ik in de ingebouwde browser op een nieuwe link klik dan kan deze op die manier dus wél achterhaald worden (en reken maar dat ze dat ook doen).
En hetzelfde grapje kan een browser natuurlijk ook uithalen. Misschien doen ze dat nu (nog) niet maar je weet het niet echt. Bij browsers waarvan de broncode bekend is kan dat dan nog achterhaald worden maar voor closed-source varianten weet je dat nooit.
Dus voor oplossingen houd ik me nog altijd aanbevolen.
Alles bij elkaar lijkt het hele DNS systeem, al dan niet DoH, kwetsbare techniek. Dagenlang probeer ik alles zo te tweaken dat ik weet welk DNS verkeer waarnaartoe gaat. Dat lijkt telkens ergens goed te gaan behalve bij mijn webradioâs. Duizenden âquery failedâ regels in mijn lokale name server maar dit gebeurt ook naar andere name servers en ik krijg het niet meer werkend. GekmakendâŠ
DoH verkeer is inderdaad moeilijk te onderscheiden van normaal https verkeer. Dat is deels het doel van de standaard, dus dat is goed gelukt 
.
Ik zie twee mogelijkheden:
-
TLS sessies (dus ook voor DoH) beginnen met een âClient Helloâ bericht vanuit de client naar de server. In dit bericht zit in veel gevallen een SNI (Server Name Indication) veld, daarin staat in plain text de hostname van de server die benaderd wordt. In geval van jouw facebook voorbeeld staat daar dus dns.facebook.com. Als je hierop zou kunnen filteren zou je een eind kunnen komen, maar let wel, het is een optioneel veld, als je pech hebt is het veld er niet. Daarna begint uiteraard nog de klus om namen van DoH servers te verzamelen.
Ik betwijfel of hier standaard implementaties voor zijn, dus dit zal een kwestie van zelf knutselen zijn. -
IP adressen van bekende DoH servers blokkeren. Er zijn zelfs al projecten die dat soort IP adressen verzamelen: GitHub - dibdot/DoH-IP-blocklists: This repo contains the domain names and the IPv4/IPv6 addresses of public DoH server
Je loopt dan wel kans dan je meer blokkeert dan je wil, bijvoorbeeld als er op zoân IP adres meer diensten actief zijn dan alleen DoH. Of dat gebeurd en of dat voor jou vervelende (bij)effecten heeft is een kwestie van uitproberen.
@pa4wdh, goede tips!
SSL verbindingen kan ik alleen dus niet op die manier onderscheiden van de rest. Die blocklists zijn ook een goed initiatief.
Overigens zijn er best goede redenen om DoH ergens in te implementeren maar mijn bezwaar is het gebrek aan transparantie. Een niet door jezelf beheerd apparaat kan door de fabrikant of exploitant ingesteld zijn om middels DoH te spieken naar door jouw opgezochte hostnamen.
Een aantal bekende DoH servers heb ik nu op de router omgeleid naar de Freedom name servers (in plaats van te blokkeren). Gek genoeg lijkt alles gewoon te blijven werken in diverse Android apps.
A propos, het probleem met mijn webradioâs is ook opgehelderd en stond geheel los van DNS: Logitech heeft simpelweg het squeezenetwork.com geheel verwijderd uit de DNS waardoor de clients gek werden.
Dit is op zich niet specifiek voor DoH, ieder device kan standaard voorgeprogrammeerde DNSâen blijven gebruiken. Zo heb ik wel eens gehoord dat -ongeacht de instellingen- android toestellen bepaalde connectiviteitschecks naar de DNSâen van google blijven doen.
Extra probleem met DoH is dat het inderdaad moeilijk te detecteren/blokkeren is.
Ja, maar maar alle UDP en TCP pakketjes naar port 53 dest-NAT ik naar de name servers van Freedom. Dus tenzij ze het op een andere manier doen, kun je het zo afvangen. Thuis, over wifi dan tenminsteâŠ
Met gewoon DNS verkeer kan dat inderdaad heel goed, ik doe iets soortgelijks met DNS naar mân eigen DNS server en NTP naar mân eigen NTP server.
Dat neemt niet weg dat ik het heel vervelend vind als apparaten niet naar de instellingen luisteren die ik ze geef 
.
Klopt deelsâŠ
SNI is optioneel, maar omdat de juiste certificaten gepresenteerd moeten worden is SNI in de meeste gevallen aanwezigâŠ
haproxy (maar dan als reverse proxy naar buiten toe, kan evt. gebruikt worden om op basis van SNI tw switchenâŠ, ie. je forward selectief naar een bepaalde server op basis van de SNI header (indien bekend) en doet dan geen TLS onderschepping. (ds geen decode/reencode HTTPS, geen data controle op inhoud maar wel selectie op SNI naam).