En dan komt de amerikaanse overheid onder leiding van Biden (als die dan nog leeft en niet zijn heup/nek gebroken heeft tijdens het wandelen in het park met de hond) met een onzichtbaar dwangbevel om de logging van de proxy server en dns server op te hoesten. Leuk dat de russen dan niet mee kunnen lezen, maar de NSA zeker wel...
Resultaat: /DEV/NULL

Maar de oppervlakkige securityminded sheep zijn al weer blij met een halve dode mus.
Daarom moet nu bijv CCC ook WEER de acties starten om de 'kuch kuch antiterrorisme' wetgeving aan te laten passen zodat jouw gezicht van jou blijft (reclaim your face) oja, toevallig dat apple die hier als privacy ridder fungeert dit nu standaard op hun iphone verplicht stelt om je iphone te unlocken omdat ze ineens de knop hebben weggehaald voor de vingerafdruk..

Op zich juich ik deze ontwikkeling toe, ware het niet dat CloudFlare geen edns-client-subnet ondersteunt. Op die manier komen veel van je requests niet op de meest dichtstbijzijnde server uit (YouTube, Facebook, etc.) maar kan het zomaar ergens in de VS uitkomen omdat je requests dan niet goed kunnen worden doorgestuurd naar de snelste server.
Google ondersteunt het met 8.8.8.8 wel, maar nu KPN op hun eigen DNS-servers DNSSEC ondersteunt, heeft Google voor mij geen meerwaarde meer en gebruik ik de standaard DNS-servers van mijn provider (KPN). Ik vertrouw KPN momenteel meer dan een derde partij.

Wat een onduidelijk plaatje. Het wekt bij mij de suggestie dat er sprake is van twee https verbindingen (tussen de client en de proxy. en tussen de proxy en de "Target"), maar dan zou de proxy alle DNS requests zien. Als dat niet zo is, waarom wordt de request in de client, proxy en target alle drie met "Q" aangeduid, en de responses allemaal met "Q"? (ik zou in de proxy dan op z'n minst iets als Q' en R' verwachten).

Verder kun je erop wachten tot cybercriminelen die proxy gaan misbruiken voor C&C en voor bestandsoverdracht van/naar gecompromitteerde PC's. De bedrijfsfirewall ziet alleen https verkeer met de vertrouwde proxy, maar ondertussen...

Aanvulling: ook bij (D)DoS aanvallen weet de aangevallen https server niet welke IP-adressen hem aanvallen c.q. vanuit welk land de https verbinding wordt opgezet (kan dus ook handig zijn om geo-IP-filters te bypassen, vind gewoon zo'n gratis proxy in de gewenste regio). Natuurlijk ziet de proxybeheerder dit wel, maar bij gratis diensten zit daar vast geen groot 24x7 team op van mensen die snappen waar je het over hebt als je aan de bel trekt i.v.m. misbruik.

Dom idee dit.

Zonder al te diep in de ODoH specificaties te duiken (heb jij ook niet gedaan) alvast wat extra informatie. Die staat redelijk duidelijk uitgelegd in de tekst in het plaatje.

De proxy is een SSL-pass-through proxy. De client maakt een verbinding via de proxy. De versleuteling wordt opgezet door de DoH server. Hierdoor ziet de proxy niet wat er in het pakketje zit. De DoH server ziet niet waar het verkeer vandaan komt, want hij ziet alleen het IP adres van de proxy.

Natuurlijk vraagt dat wel om een goede configuratie van de proxy. De laatste tijd komen er nog al eens kwetsbaarheden naar boven waarbij het IP adres van de client wel op de een of andere manier wordt gelekt.


Als je die proxy zo instelt dat ze alleen verkeer doorlaten naar de DoH servers van hun partners, is er voor de criminelen niet veel te compromiteren. En gebruik van DoH om queries van malware voor C&C servers te verbergen, is nu al mogelijk. Dat is een bekend probleem bij DoH. Dat maakt ODoH niet veiliger of onveiliger.


Als mijn server aangevallen wordt, zie ik toch echt wel uit welk land dat IP adres afkomstig zou zijn. Dat is eenvoudig te blokkeren middels Geo-IP. Ja, ze kunnen deze proxy gebruiken, maar die worden toch wel beter beheerd dan al die SOCKS proxies op thuisaansluitingen. Voor een crimineel is het eenvoudiger om gebruik te maken van de miljoenen thuisproxies dan de paar ODoH proxies.

En dan nog zie ik niet hoe een goed ingestelde ODoH proxy mee kan doen in een DDoS anders dan in eentje naar Cloudflare. Als dat gebeurt, dan weet Cloudflare die proxy beheerder wel snel te vinden.


Van een paar van de genoemde aanbieders weet ik dat het gewoon een onderdeel is van de standaard dienstverlening voor hun klanten. Als je losse broodjes gaat halen bij de bakker, dan is de zak waar ze in gaan in principe gratis. Maar nog steeds kun je best klagen als die blijkt te scheuren en je broodjes over de straat rollen.

Van een paar partijen week ik dat ze een zeer actieve 24-uurs security dienstverlening hebben. Ik heb daar nog wel eens gebruik van mogen maken.

Peter

"Zo kunnen derden zien welke websites iemand bezoekt of de dns-informatie aanpassen."
Dit klopt natuurlijk niet. Om te voorkomen dat DNS informatie ongewenst aangepast wordt, is er zoiets als DNSSEC uitgevonden.

"ODoH zorgt ervoor dat dns-providers niet kunnen zien welk dns-verzoek bij een bepaald ip-adres hoort, wat de privacy van gebruikers ten goede moet komen." Ook dit statement klopt niet. Je gooit je privacy niet meer te grabbel voor je eigen ISP, maar die data worden nu gegraaid door de Amerikaanse internetgiganten.

Als een ondernemer dit zou doen, dan zou hij verlies maken in plaats van winst.

Vanuit deze optiek is het met OdoH wachten op de keuzemogelijkheden de komende jaren. Tot die tijd heb ik slechts 'reguliere' doh in mijn Firefox geïmplementeerd. Customized. De defaults zijn idd...Cloudflare en Nextdns.

Ook hoop dat mensen in zien dat dit vooral marketing praat is. Zo wordt is het cachen van DNS records een van de technieken om DNS zo snel te laten lopen. Caching is met ODoH niet meer mogelijk. Als je dan toch de cache eruit haalt, waarom dan niet direct verbinden met de authoritative nameserver?

Dit hele model draait nog steeds om het idee dat je DNS records via Cloudlfare/Google/??? moeten lopen. Die records geven zelfs zonder client IP genoeg informatie. Over bijvoorbeeld de meest populaire websites of websites die nog niet bekend waren, beide informatie die gebruikt kan worden in bijvoorbeeld de Google search ranking. Het hoeft niet altijd om persoonsgegevens te gaan, dit is gewoon het oude bekende data graaien in een nieuw jasje. Daar veranderd ODoH niets aan.

Zorg dat je data blijft bij de enige (Europeese) partij waar je een contract mee hebt: je ISP. Of "cut out the middlemen" en draai je eigen recursive resolver.

(Overigens zijn er ook al andere voorstellen gedaan om DNS echt privacy vriendelijk te maken. Zo zou een zoekmachine je ook de DNS records mee kunnen geven van de websites die je als resultaten te zien krijgt. Dan hoeft je eigen computer geen lookup meer te doen. Uiteraard alleen te gebruiken als je zelf de DNSSEC validatie doet.)

Kijk zelf eens even naar de 6 onveiligheidsalerts hier.
Het betreft een scannetje op een Akamai-sub-domein, dit is het tracking onderdeel van de UPS tracker,
bij gebruikers met uBlock Original wordt dit als ad-tracker geblokkeerd:

https://dnsviz.net/d/tags.tiqcdn.com/dnssec/

Het blijkt dus dat grote Big IT Data-Trackers toch wel hun ding zullen gaan blijven doen,
ondanks deze ODoH "gimmick".

luntrus

Lees het artikel eens.
Met ODoH gebeurt dat juist niet.

Peter

Ik zie toch wat anders. Er wordt op de drie servers (client, proxy en target) een Query gedaan, en alle drie geven ze een Response terug. Het gaat om dezelfde query op alle drie servers en dezelfde response. Dus ik zie niet waarom je Q' en R' zou moeten verwachten.

L.S.

Naar aanleiding van mijn vorige post hogerop in deze draad nog even een combinatie van deze gegevens:
https://crt.sh/?q=tags.tiqcdn.com en dan met fouten en onveilig ->
https://dnsviz.net/d/s5.wac.edgecastcdn.net/dnssec/

Er speelt dus hier nog wat meer ? No Data Zone Transfer.

luntrus

Ondertussen heb ik https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-03 grotendeels gelezen en daar maak ik het volgende uit op (dit is hoe ik vermoed dat het ongeveer gaat, padding e.d. laat ik gemakshalve weg), uitgaande van een DNS-verzoek vanaf die client in Q_plain:
1) Op de client is een oblivious DNS-server geconfigureerd, bijv. odoh.example.net;
2) De client vraagt, via DNS [*], een public key (t.b.v. encryption) voor oblivious DNS, PubKey_odoh, op van odoh.example.net;

[*] Ik heb me niet in het impliciete kip-ei probleem hierbij verdiept, noch in dat als dit specifieke DNS verkeer direct naar de DNS server gaat (buiten de proxy om dus), de DNS server zou kunnen weten van welk IP-adres het eerstvolgende DNS verzoek (via proxy) afkomstig is.

3) In het antwoord zit PubKey_odoh en een key_ID (kennelijk worden meerdere sleutelparen per server ondersteund);
4) De client genereert een symmetrische sleutel SKey_plain en versleutelt daarmee Q_plain in Q_encrypted;
5) De client versleutelt de symmetrische sleutel met PubKey_odoh van de DNS server, resulterend in SKey_encrypted;
6) De client zet een https verbinding op met de proxy server en POST de volgende gegevens:
- vereiste oblivious DNS server (bijv. odoh.example.net);
- key_ID;
- SKey_encrypted;
- Q_encrypted.

7) De proxy server maakt een (geheel gescheiden) https verbinding met de gespecificeerde oblivious DNS server;
8) De proxy server POST de ontvangen gegevens aldaar (de DNS server komt het IP-adres van de client zo niet te weten);

9) De oblivious DNS server zoekt, op basis van key_ID, de juiste private key PrivKey_odoh op;
10) De oblivious DNS server ontsleutelt SKey_encrypted m.b.v. PrivKey_odoh en verkrijgt zo SKey_plain;
11) De oblivious DNS server ontsleutelt Q_encrypted m.b.v. SKey_plain en verkrijgt zo Q_plain;
12) De oblivious DNS server voert het DNS-verzoek Q_plain uit en verkrijgt antwoord (of foutmelding) R_plain;
13) De oblivious DNS server versleutelt R_plain met SKey_plain en verkrijgt daarmee R_encrypted;
14) De oblivious DNS server stuurt R_encrypted als antwoord naar de proxy server;

15) De proxy server stuurt R_encrypted naar de client als antwoord op diens verzoek in 6);

16) De client ontsleuteld R_encrypted met SKey_plain (die de client bewaard heeft) en heeft zo het antwoord R_plain.

Conclusies
A) Het is enerzijds geen NAT maar anderzijds nauwelijks proxyen (application-level) wat de "proxy server" doet. Er zijn twee gescheiden https verbindingen, maar verder doet de proxy niets op applicatieniveau;
B) Het plaatje zuigt, want -van de geheim te houden info- ziet de proxy server (naast SKey_encrypted) alleen Q_encrypted en R_encrypted;
C) Als de client voor de gek gehouden kan worden met een valse PubKey_odoh, bijv. verstekt door de proxy server, kan de proxy server alles zelf afhandelen zonder dat de client dit weet;
D) De client kiest de oblivious DNS server, maar de proxy kan desgewenst alles weigeren behalve partners. In dat laatste geval is het de vraag hoever dat partnerschap gaat (als de proxy server IP-adressen van clients doorspeelt is het geheel een farce). Als de proxy server willekeurige oblivious DNS servers ondersteunt helpt cybercriminelen dat bij het exporteren van vertrouwelijke informatie en/of C&C communicatie zonder dat Q_plain en R_plain een formaat zoals gespecificeerd in "draft-irtf-cfrg-hpke-06" hoeven te hebben, en mogelijk faciliteert dit het uitvoeren van (D)DoS aanvallen;
E) Maar ook indien de proxy server meer dan één oblivious DNS servers ondersteunt, heeft (malware op) de client in elk geval een keuze welke server zij kiest (bijv. degene die geen of "minder snelle" blacklists hanteert), zonder dat jouw uitgaande firewall weet naar welke uiteindelijke oblivious DNS server de requests gaan; je ziet immers alleen maar dat een of meer clients met de ingestelde proxy communiceren. Met TLS-inspectie zie je dat wel, maar dan heb je slechts Q_encrypted en R_encrypted (dus geen Q_plain en R_plain). Tenzij je PubKey_odoh, voordat deze de client bereikt, straffeloos (zonder foutmeldingen op de client) door een public key van jezelf weet te vervangen, en zo een dubbele MitM realiseert. Maar dat zo'n complexe setup de beveiliging en privacy netto ten goede komt waag ik zeer te betwijfelen;
F) Als ik het goed begrepen heb, wordt er geen gebruik gemaakt van forward secrecy (als dat wel zo is klopt mijn bovenstaande beschrijving niet). Dat betekent dat als de proxy server op een gegeven moment PriKey_odoh in handen krijgt (of uit PubKey_odoh weet te herleiden, bijv. middels een quantum computer), de beheerder alle eerder opgeslagen Q_encrypted en R_encrypted (die zijn versleuteld met PubKey_odoh, en dus ook alle daarmee versleutelde SKey_plain's) kan ontsleutelen, en -zolang PubKey_odoh nog gebruikt blijft worden- alle toekomstige communicatie.

Ten slotte denk ik dat we, om drie redenen, doorschieten met DoH en zeker met dit soort fratsen daarbovenop:
a) Je bemoeilijkt "opsporing" van verdacht gedrag binnen jouw organisatie terwijl je juist cybercriminelen ermee faciliteert, en als "DNS niet werkt" weet je, zeker met odoh, helemaal niet meer waar het probleem zit;
b) Het gedistribueerde karakter van DNS wordt gesloopt, de macht komt bij een klein aantal providers te liggen wat de consequenties van eventuele hacks en/of uitval vergroot en het risico op censuur toeneemt;
c) Als je minister Grapperhaus ook zijn metadata afpakt, zal dat de roep om verzwakte of gebackdoorde encryptie alleen maar vergroten - don't push your luck...

Ik blijf DNS over HTTPS een heel slecht idee vinden. Er gaan zware vodden van komen - malware die gewoon niet meer te stoppen valt bij voorbeeld.