image

Cloudflare en SURF lanceren Oblivious DNS over HTTPS

dinsdag 8 december 2020, 15:00 door Redactie, 15 reacties

Cloudflare, het Nederlandse SURF en verschillende andere partners hebben vandaag Oblivious DNS over HTTPS (ODoH) gelanceerd. 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.

Op dit moment zijn dns-verzoeken van internetgebruikers, waarin staat welk domein ze willen opvragen, nagenoeg altijd onversleuteld. Zo kunnen derden zien welke websites iemand bezoekt of de dns-informatie aanpassen. Om dit te voorkomen werd DNS over HTTPS (DoH) bedacht. DoH versleutelt dns-verzoeken van internetgebruikers, zodat die niet meer zijn in te zien of aan te passen.

DoH moet echter wel door de dns-provider van de gebruiker worden ondersteund. Op dit moment zijn er slechts een paar publieke DoH-providers. Hierdoor bestaat het risico dat één partij heel veel inzicht in het dns-verkeer van gebruikers krijgt. Om dit probleem te tackelen bedachten engineers van Apple, Cloudflare en Fastly Oblivious DNS over HTTPS.

ODoH versleutelt het dns-verzoek en laat het via een proxyserver lopen. Deze proxyserver, die losstaat van de dns-server, fungeert als tussenpersoon tussen de internetgebruiker en de website die hij wil bezoeken. Doordat het dns-verzoek is versleuteld kan de proxyserver de inhoud niet zien. De proxyserver voorkomt vervolgens weer dat de dns-server het ip-adres van de gebruiker ziet.

"De combinatie van deze twee onderdelen garandeert dat alleen de gebruiker op hetzelfde moment toegang tot zowel de dns-berichten als zijn eigen ip-adres heeft", aldus Tanya Verma van Cloudflare in een blogposting. ODoH heeft volgens Verma ook nauwelijks impact op de snelheid waarmee de dns-verzoeken worden verwerkt.

Om ODoH goed te laten werken is het nodig dat de proxyserver die het dns-verzoek naar de dns-server doorstuurt, door een andere partij wordt beheerd dan de dns-provider. Hiervoor werkt Cloudflare samen met verschillende proxypartners, te weten PCCW, SURF en Equinix. ODoH is inmiddels te gebruiken met de 1.1.1.1-dns-server van Cloudflare zelf. Daarnaast heeft Cloudflare de ODoH-specificatie aan de Internet Engineering Task Force (IETF) voorgelegd, in de hoop er een internetstandaard van te maken.

Image

Reacties (15)
08-12-2020, 15:50 door Anoniem
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..
08-12-2020, 15:57 door Hans van Eijsden
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.
08-12-2020, 16:09 door Erik van Straten - Bijgewerkt: 08-12-2020, 16:20
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.
08-12-2020, 16:40 door -Peter-
Door Erik van Straten: 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).

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.

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...

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.

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).

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.

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.

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
08-12-2020, 17:00 door Anoniem
"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.
08-12-2020, 17:02 door Anoniem
"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.
08-12-2020, 19:18 door Anoniem
Als je losse broodjes gaat halen bij de bakker, dan is de zak waar ze in gaan in principe gratis.
Als een ondernemer dit zou doen, dan zou hij verlies maken in plaats van winst.
08-12-2020, 22:23 door Anoniem
Door Anoniem: "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.
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.
09-12-2020, 10:26 door Anoniem
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.)
09-12-2020, 14:47 door Anoniem
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
09-12-2020, 15:39 door -Peter-
Door Anoniem: "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.

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

Peter
09-12-2020, 17:37 door botbot - Bijgewerkt: 09-12-2020, 17:39
Door Erik van Straten: 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).

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.
09-12-2020, 18:31 door Anoniem
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
09-12-2020, 23:40 door Erik van Straten
Door -Peter-:
Door Erik van Straten: 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).

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.
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...
12-12-2020, 20:55 door Anoniem
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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.