DNS-Datenschutz verbessern mit Oblivious DoH in 1.1.1.1

Heute geben wir die Unterstützung eines neuen vorgeschlagenen DNS-Standards bekannt, der von Ingenieuren von Cloudflare, Apple und Fastly gemeinsam ausgearbeitet wurde und IP-Adressen von Abfragen trennt, so dass keine einzelne Entität beide zur gleichen Zeit sehen kann. Besser noch: Wir haben den Quellcode öffentlich verfügbar gemacht, sodass jeder ODoH testen oder einen eigenen ODoH-Dienst betreiben kann.

Aber zunächst einmal etwas Kontext. Das Domain Name System (DNS) bildet die Grundlage für ein von Menschen nutzbares Internet. Es ordnet verwendbare Domainnamen wie cloudflare.com IP-Adressen und anderen Informationen zu, die erforderlich sind, um sich mit dieser Domain zu verbinden. Eine kurze Einführung in die Bedeutung von DNS und die damit verbundenen Probleme finden Sie in einem früheren Blog-Beitrag. Für den aktuellen Beitrag genügt es, zu wissen, dass das System ursprünglich so konzipiert ist, dass DNS-Abfragen im Klartext versendet werden – und dass dies immer noch gängige Praxis ist. Somit kann jeder, der sich auf dem Netzwerkpfad zwischen Ihrem Gerät und dem DNS-Resolver befindet, sowohl die Abfrage sehen, die den anvisierten Hostnamen (oder die anvisierte Website) enthält, als auch die IP-Adresse, die Ihr Gerät identifiziert.

Um DNS vor Datenspionen und Dritten zu schützen, hat die IETF DNS-Verschlüsselung mit „DNS over HTTPS“ (DoH) und „DNS over TLS“ (DoT) zum Standard gemacht. Beide Protokolle verhindern, dass Abfragen zwischen dem Client und dem Resolver abgefangen, umgeleitet oder geändert werden. Die Client-Unterstützung für DoT und DoH wächst, sie wurde unter anderem in den aktuellen Versionen von Firefox, iOS und weiteren implementiert. Doch zurzeit ist die Verbreitung unter den Internetprovidern noch begrenzt und Cloudflare gehört zu den wenigen Anbietern, die einen öffentlichen DoH/DoT-Dienst anbieten. In diesem Zusammenhang werden im Wesentlichen zwei Bedenken angemeldet. Eine Sorge ist, dass durch die Zentralisierung des DNS Single Points of Failure geschaffen werden (auch wenn Cloudflare mit Rechenzentren in mehr als 100 Ländern auf ständige Verfügbarkeit ausgelegt ist). Eine weitere Sorge ist, dass der Resolver weiterhin alle Abfragen mit Client-IP-Adressen verknüpfen kann.

Cloudflare ist dem Datenschutz der Endbenutzer verpflichtet. Benutzer unseres öffentlichen DNS-Resolver-Dienstes sind durch eine starke, geprüfte Datenschutzrichtlinie geschützt. Trotz der strengen Datenschutzrichtlinie hält die Notwendigkeit, Cloudflare sensible Abfragedaten anvertrauen zu müssen, jedoch manche Nutzer von der Implementierung der Lösung ab. Was wäre, wenn sich Nutzer nicht auf Datenschutzbestimmungen und Audits verlassen müssten, sondern wir ihnen die Möglichkeit geben könnten, diese Hürde mit technischen Garantien zu beseitigen?

Ab heute unterstützen Cloudflare und seine Partner ein Protokoll, das genau dies tut: Oblivious DNS über HTTPS, oder kurz ODoH.

Wir freuen uns, ODoH mit mehreren führenden Partnerunternehmen auf den Weg zu bringen, die sich gleichermaßen dem Datenschutz verpflichtet fühlen.

Eine wichtige Komponente von ODoH ist ein Proxy, der vom Ziel-Resolver getrennt ist. Und heute lancieren wir ODoH mit mehreren führenden Proxy-Partnern, darunter PCCW, SURF und Equinix.

"ODoH ist ein revolutionäres neues Konzept, bei dem die Privatsphäre der Nutzer im Mittelpunkt steht. Unsere ODoH-Partnerschaft mit Cloudflare hilft unserer Positionierung im Bereich Privatsphäre und „Infrastruktur des Internet“. Neben der verbesserten Sicherheit und Performance des zugrundeliegenden PCCW Global-Netzwerks, auf das bei Bedarf über Console Connect zugegriffen werden kann, wird nun auch die Performance der Proxys in unserem Netzwerk durch die 1.1.1.1-Resolver von Cloudflare verbessert. Dieses Modell entkoppelt den Client-Proxy erstmals vollständig von den Resolvern. Diese Partnerschaft stärkt unseren bestehenden Fokus auf Datenschutz in einer Zeit, in der die Welt zu einem Modell der Remote-Arbeit übergeht und Datenschutz zu einem noch wichtigeren Feature wird.“ -- Michael Glynn, Vice President, Digital Automated Innovation, PCCW Global

Wir arbeiten mit Cloudflare zusammen, um den Datenschutz der Nutzer über ODoH zu verbessern. Der Wechsel zu ODoH ist ein echter Paradigmenwechsel, bei dem die Privatsphäre der Nutzer und die IP-Adresse keinem Provider offengelegt wird. Das Ergebnis ist echte Privatsphäre. Mit der Einführung von OdoH-pilot werden wir Teil des leistungsstarken Cloudflare-Netzwerks, um den Herausforderungen aller Nutzer rund um den Globus gerecht zu werden. Der Übergang zu ODoH ist nicht nur ein Paradigmenwechsel, sondern unterstreicht auch, dass den Nutzern der Datenschutz wichtiger denn je ist, insbesondere im Jahr 2020. Dies steht im Einklang mit unserem Hauptanliegen und unserer Überzeugung: dem Schutz der Privatsphäre". — Joost van Dijk, Technical Product Manager, SURF

ODoH fügt zwischen Clients und DoH-Servern wie 1.1.1.1. eine Ebene mit Public Key Encryption und einen Netzwerk-Proxy ein. Die Kombination dieser beiden zusätzlichen Elemente garantiert, dass nur der Benutzer gleichzeitig Zugriff auf die DNS-Nachrichten und seine eigene IP-Adresse hat.

Es gibt drei Akteure auf dem ODoH-Pfad. Betrachten wir die obige Abbildung und beginnen wir mit dem Ziel. Das Ziel entschlüsselt vom Client verschlüsselte Abfragen über einen Proxy. Auf ähnliche Weise verschlüsselt das Ziel Antworten und gibt sie an den Proxy zurück. Der Standard besagt, dass das Ziel der Resolver sein kann oder auch nicht (wir werden später darauf eingehen). Der Proxy tut, was ein Proxy tun sollte, indem er Nachrichten zwischen Client und Ziel weiterleitet. Der Client verhält sich wie im DNS und DoH, unterscheidet sich aber durch die Verschlüsselung von Abfragen für das Ziel und die Entschlüsselung der Antworten des Ziels. Jeder Client, der sich dafür entscheidet, kann einen Proxy und ein Ziel seiner Wahl angeben.

Gemeinsam bieten die zusätzliche Verschlüsselung und das Proxying folgende Garantien:

1. Das Ziel sieht nur die Abfrage und die IP-Adresse des Proxys.

2. Der Proxy hat keinen Einblick in die DNS-Nachrichten und kann weder die vom Client gesendete Abfrage noch die vom Ziel ausgegebene Antwort identifizieren, lesen oder ändern.

3. Nur das anvisierte Ziel kann den Inhalt der Abfrage lesen und eine Antwort generieren.

Diese drei Garantien verbessern die Privatsphäre des Clients und gewährleisten gleichzeitig die Sicherheit und Integrität von DNS-Abfragen. Jede dieser Garantien stützt sich jedoch auf eine grundlegende Eigenschaft — nämlich, dass der Proxy und die Zielserver nicht kolludieren. Solange es keine Absprache gibt, hat ein Angreifer nur dann Erfolg, wenn sowohl der Proxy als auch das Ziel kompromittiert sind.

Hervorzuheben ist bei diesem System der Aspekt, dass das Ziel von dem vorgeschalteten rekursiven Resolver getrennt ist, der die DNS-Auflösung durchführt. In der Praxis erwarten wir in Bezug auf die Performance, dass das Ziel dasselbe ist. Tatsächlich ist 1.1.1.1 jetzt sowohl ein rekursiver Resolver als auch ein Ziel. Es gibt keinen Grund dafür, dass ein Ziel getrennt von einem Resolver existieren muss. Wenn sie getrennt werden, dann kann das Ziel frei entscheiden, welche Resolver es wählt und nur als Bindeglied fungieren. Die einzige echte Voraussetzung ist, erinnern Sie sich, dass Proxy und Ziel niemals kolludieren.

Wichtig ist auch, dass die Clients die vollständige Kontrolle über die Auswahl der Proxys und Ziele haben. Ohne auf TRR-ähnliche Programme zurückgreifen zu müssen, kann Clients die Wahrung der Vertraulichkeit und Sicherheit für ihre Abfragen geboten werden. Da das Ziel nur über den Proxy Bescheid weiß, wissen das Ziel und jeder vorgelagerte Resolver nichts von der Existenz irgendwelcher Client-IP-Adressen. Das bedeutet vor allem, dass die Clients mehr Kontrolle über ihre Abfragen und die Art und Weise ihrer Verwendung erhalten. Zum Beispiel könnten Clients ihre Proxys und Ziele jederzeit und aus jedem Grund auswählen und ändern!

Das „O“ in ODoH steht für „Oblivious“ (sinngemäß: blind). Diese Eigenschaft stammt von der Verschlüsselungsebene der DNS-Nachrichten selbst. Diese zusätzliche Ende-zu-Ende-Verschlüsselung zwischen Client und Ziel ist unabhängig von der von TLS/HTTPS bereitgestellten Verschlüsselung auf Verbindungsebene. Man könnte sich die Frage stellen, warum eine zusätzliche Verschlüsselung überhaupt notwendig ist, wenn doch ein Proxy zum Einsatz kommt. Dies liegt daran, dass zwei separate TLS-Verbindungen zur Unterstützung der Proxy-Funktionalität erforderlich sind. Konkret beendet der Proxy eine TLS-Verbindung vom Client und initiiert eine weitere TLS-Verbindung zum Ziel. Zwischen diesen beiden Verbindungen würden die DNS-Nachrichtenkontexte sonst im Klartext erscheinen! Aus diesem Grund verschlüsselt ODoH zusätzlich Nachrichten zwischen Client und Ziel, so dass der Proxy keinen Zugriff auf die Nachrichteninhalte hat.

Der ganze Prozess beginnt mit Clients, die ihre Abfrage für das Ziel mittels hybrider Kryptographie (HPKE) verschlüsseln. Clients erhalten den öffentlichen Schlüssel des Ziels über das DNS, wo er in einen HTTPS-Ressourceneintrag integriert und durch DNSSEC geschützt wird. Wenn die TTL für diesen Schlüssel abgelaufen ist, fordern Clients bei Bedarf eine neue Kopie des Schlüssels an (genau wie sie dies bei einem A/AAAA-Eintrag machen würden, wenn der TTL dieses Eintrags abläuft). Die Verwendung eines durch DNSSEC validierten öffentlichen Schlüssels des Ziels garantiert, dass nur das beabsichtigte Ziel die Abfrage ent- und eine Antwort verschlüsseln kann.

Clients senden diese verschlüsselten Abfragen über eine HTTPS-Verbindung an einen Proxy. Dieser leitet die Abfrage dann an das vorgesehene Ziel weiter. Das Ziel entschlüsselt die Abfrage und generiert eine Antwort, indem es die Abfrage an einen rekursiven Resolver wie 1.1.1.1 schickt und dann die Antwort an den Client verschlüsselt. Die verschlüsselte Abfrage des Client enthält eingekapseltes Schlüsselmaterial, aus dem Ziele den Schlüssel für die symmetrische Verschlüsselung der Antwort ableiten.

Diese Antwort wird dann an den Proxy zurückgeschickt und von dort aus an den Client weitergeleitet. Die gesamte Kommunikation ist authentifiziert und vertraulich, da diese DNS-Nachrichten durchgängig verschlüsselt sind, obwohl sie über zwei separate HTTPS-Verbindungen (Client-Proxy und Proxy-Ziel) übertragen werden. Die Nachricht, die dem Proxy ansonsten als Klartext erscheint, ist in Wirklichkeit ein verschlüsseltes Durcheinander.

Wir haben viele Messungen durchgeführt, um das herauszufinden, und werden noch mehr machen, wenn ODoH in größerem Umfang eingesetzt wird. Unser erster Satz von Messkonfigurationen umfasste Städte in den USA, Kanada und Brasilien. Wichtig ist, dass unsere Messungen nicht nur den 1.1.1.1.1, sondern auch 8.8.8.8.8 und 9.9.9.9.9 umfassen. Der vollständige Satz von Messungen ist bisher für Open Access dokumentiert.

Bei diesen Messungen war es wichtig, die Kosten für Proxying und zusätzliche Verschlüsselung von den Kosten für den Aufbau von TCP- und TLS-Verbindungen zu isolieren. Dies liegt daran, dass die Kosten für TLS und TCP ohnehin bei DoH anfallen. Bei unserem Aufbau haben wir also die Messungen „vorbereitet“, indem wir die Verbindungen einmal hergestellt und diese Verbindung für alle Messungen wieder verwendet haben. Dies haben wir sowohl für DoH als auch für ODoH getan, da in beiden Fällen die gleiche Strategie angewendet werden konnte.

Zunächst können wir mit Sicherheit sagen, dass die zusätzliche Verschlüsselung marginal ist. Wir wissen dies, weil wir 10.000 Domänen aus dem Tranco Millionen-Datensatz nach dem Zufallsprinzip ausgewählt und sowohl die Verschlüsselung des A-Datensatzes mit einem anderen öffentlichen Schlüssel als auch seine Entschlüsselung gemessen haben. Die zusätzlichen Kosten zwischen einer durch einen Proxy abgewickelte DoH-Abfrage/-Antwort und ihrem ODoH-Pendant betragen durchweg weniger als 1 ms im 99. Perzentil.

Die ODoH-Request-Response-Pipeline ist jedoch viel mehr als nur eine Verschlüsselung. Eine sehr nützliche Art, Messungen zu betrachten, ist die Betrachtung des kumulativen Verteilungsdiagramms — wenn Sie mit dieser Art von Diagrammen vertraut sind, springen Sie zum nächsten Absatz. Im Gegensatz zu den meisten Diagrammen, bei denen wir entlang der x-Achse beginnen, beginnen wir bei kumulativen Verteilungen oft mit der y-Achse.

Das Diagramm unten zeigt die kumulativen Verteilungen für Abfrage-/Antwortzeiten in DoH, ODoH und DoH bei der Übertragung über das Tor-Netzwerk. Die gestrichelte horizontale Linie, die links bei 0,5 beginnt, ist die 50 %-Marke. Entlang dieser horizontalen Linie enthält bei jeder aufgezeichneten Kurve der Teil der Kurve unterhalb der gestrichelten Linie 50 % der Datenpunkte. Betrachten Sie nun die x-Achse, die ein Zeitmaß darstellt. Die Linien, die auf der linken Seite erscheinen, sind schneller als die Linien auf der rechten Seite. Ein letztes wichtiges Detail ist, dass die x-Achse in einem logarithmischen Maßstab aufgetragen ist. Was ist damit gemeint? Beachten Sie, dass der Abstand zwischen den beschrifteten Markierungen (10x) bei kumulativen Verteilungen gleich ist, aber das „x“ ist ein Exponent und steht für Größenordnungen. Während also der Zeitunterschied zwischen den ersten beiden Markierungen 9 ms beträgt, beträgt der Unterschied zwischen der 3. und 4. Markierung 900 ms.

In diesem Diagramm stellt die mittlere Kurve ODoH-Messungen dar. Wir haben auch die Performance von Datenschutz-bewahrenden Alternativen gemessen, z.B. DoH-Abfragen, die über das Tor-Netzwerk übertragen werden, wie sie durch die rechte Kurve in der Grafik dargestellt werden. (Weitere Datenschutz-bewahrende Alternativen sind im Open Access Technical Report erfasst.) Im Vergleich zu anderen datenschutzorientierten DNS-Varianten verkürzt ODoH die Abfragezeit um die Hälfte oder mehr. Dieser Punkt ist wichtig, da Datenschutz und Performance selten gut zusammenspielen, daher ist es ermutigend, diese Art von Verbesserung zu sehen!

Die obige Grafik zeigt auch, dass 50 % der ODoH-Abfragen in weniger als 228 ms aufgelöst werden. Vergleichen Sie nun die mittlere Linie mit der linken Linie, die das „geradlinige“ (oder normale) DoH ohne jede Modifikation darstellt. Die linke Punktlinie besagt, dass in 50 % aller Fälle DoH-Abfragen in weniger als 146 ms aufgelöst werden. Wenn man unter die 50 %-Marke blickt, sagen uns die Kurven auch, dass dieser Unterschied in der Hälfte aller Fälle nie größer als 100 ms ist. Auf der anderen Seite zeigt uns ein Blick auf die Kurven oberhalb der 50 %-Marke, dass die Hälfte der ODoH-Abfragen mit dem DoH konkurrieren.

Diese Kurven verbergen auch eine Menge Informationen, so dass es wichtig ist, die Messungen weiter zu vertiefen. Das untenstehende Diagramm zeigt drei verschiedene kumulative Verteilungskurven, die die Performance von ODoH beschreiben, wenn wir Proxys und Ziele nach ihrer Latenz auswählen. Dies ist auch ein Beispiel für die Einsichten, die durch Messungen gewonnen werden können, von denen einige kontraintuitiv sind. Wenn man zum Beispiel über 0,5 blickt, besagen diese Kurven, dass die Hälfte der ODoH-Abfrage-/Antwortzeiten praktisch nicht unterscheidbar sind, unabhängig von der Wahl des Proxy und des Ziels. Richten Sie Ihre Aufmerksamkeit nun unter 0,5 und vergleichen Sie die beiden durchgezogenen Kurven mit der gestrichelten Kurve, die den Gesamtdurchschnitt darstellt. Dieser Bereich deutet darauf hin, dass die Auswahl des Proxy und des Ziels mit der geringsten Latenz eine minimale Verbesserung gegenüber dem Durchschnitt bietet, aber vor allem zeigt sie, dass die Auswahl des Proxy mit der geringsten Latenz zu einer schlechteren Performance führt!

Natürlich bleiben einige offene Fragen. Diese erste Reihe von Messungen wurde großteils in Nordamerika durchgeführt. Verändert sich die Performance auf globaler Ebene? Wie wirkt sich dies in der Praxis auf die Client-Performance aus? Wir arbeiten daran, dies herauszufinden, und diese Publikation wird uns dabei helfen.

Die Antwort auf beide Fragen lautet: ja! Wir haben unsere interoperablen ODoH-Implementierungen in Rust, odoh-rs und Go,odoh-go, als Open Source angelegt und das Ziel in den Cloduflare DNS Resolver integriert. Sie haben richtig gelesen: 1.1.1.1 ist bereit, Abfragen über ODoH zu empfangen!

Wir haben auch Test-Clients in Rust, odoh-client-rs, und Go, odoh-client-go, als Test-Clients angelegt, um ODoH-Abfragen demonstrieren zu können. Sie können sich auch die HPKE-Konfiguration ansehen, die von ODoH für die Nachrichtenverschlüsselung nach 1.1.1.1 verwendet wird, indem Sie den Dienst direkt abfragen:

$ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com 

; <<>> DiG 9.10.6 <<>> -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;odoh.cloudflare-dns.com.	IN	TYPE65

;; ANSWER SECTION:
odoh.cloudflare-dns.com. 300	IN	TYPE65	\# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A
odoh.cloudflare-dns.com. 300	IN	RRSIG	TYPE65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA==

;; Query time: 21 msec
;; SERVER: 173.245.58.100#53(173.245.58.100)
;; WHEN: Wed Nov 18 07:36:29 PST 2020
;; MSG SIZE  rcvd: 291

Wir arbeiten daran, ODoH zu bestehenden Stub-Resolvern wie cloudflared hinzuzufügen. Wenn Sie daran interessiert sind, eine Unterstützung für einen Client hinzuzufügen, oder wenn Sie auf Fehler in den Implementierungen stoßen, schreiben Sie uns bitte an ask-research@cloudflare.com! Ankündigungen über die ODoH-Spezifikation und den Server werden an die IETF DPRIVE Mailingliste ausgesandt. Um Ankündigungen und Diskussionen über die Spezifikation zu abonnieren und mitzuverfolgen, klicken Sie hier.

Wir setzen uns dafür ein, sie in der IETF voranzubringen, und sehen bereits jetzt Interesse von Kunden und Anbietern. Eric Rescorla, CTO von Firefox, sagt:

„Oblivious DoH ist eine großartige Ergänzung für das secure DNS-Ökosystem. Wir freuen uns über seinen Aufstieg und darauf, in Firefox damit zu experimentieren“.

Wir hoffen, dass weitere Betreiber sich uns so anschließen und das Protokoll unterstützen, indem sie entweder Proxys oder Ziele einsetzen. Zudem hoffen wir, dass auch die Client-Unterstützung mit Zunahme der verfügbaren Infrastruktur steigt.

Das ODoH-Protokoll stellt einen praktischen Ansatz zur Verbesserung des Datenschutzes für Nutzer dar und zielt darauf ab, die Verbreitung verschlüsselter DNS-Protokolle insgesamt zu erhöhen, ohne dabei die Performance und Nutzererfahrung im Internet zu beeinträchtigen.

Marek Vavruša und Anbang Wen waren maßgeblich daran beteiligt, die ODoH-Unterstützung von 1.1.1.1 auf den Weg zu bringen. Chris Wood und Peter Wu halfen dabei, die ODoH-Programmbibliotheken vorzubereiten und zu testen.