 Einen wunderschönen guten Morgen hier auf der Remote Rhein-Ruhr-Stage aus dem schönen Monheim. Wir haben jetzt schon einen Ersatzvortrag gefunden, nach dem wir gestern unseren eigentlich geplanten Vortrag über ESP känzeln mussten. Es geht jetzt über DNS, genau genommen über Encrypted DNS, Episode 2 von Karsten Strutmann. Ja, vielen Dank. Hallo, herzlich willkommen. Guten Morgen. Ich spreche über das Thema Encrypted DNS und dies ist ein Update zu meinem Vortrag vom Camp im letzten Jahr. Daher werde ich auf die grundlegenden Sachen nur kurz eingehen und hauptsächlich darüber sprechen, was sich geändert hat in den letzten anderthalb Jahren. Es geht um DNS Privacy, um neue Protokolle wie DNS over HTTPS, DNS over TLS oder DNS over Quick. Was ist der derzeitige Status und speziell möchte ich was erzählen über Adaptive DNS Resolver Discovery, eine neue Technologie, die jetzt in den Apple-Betrieb-Systemen eingebaut ist. Das Beispiel bringen wir in den vergangenen Jahren hat die ITF, das sind die Leute, die die Internetstandards machen, das DNS Protokoll mit zusätzlichen Datenschutzfunktionen ausgerüstet. Und da gibt es mehrere, zum Beispiel das DNS über TLS, DNS über HTTPS, aber auch solche Sachen wie Q Name Minimization oder das DNS Padding. Wir werden hier in diesem Talk über Transportverschlüsselung sprechen und das ist so was wie DNS über TLS und DNS über HTTPS. So, warum braucht man überhaupt DNS Privacy? In der ITF-Sitzung 105 im Sommer 2019 wurde in einem Vortrag eine Forschung veröffentlicht, die zeigte, dass ca. 8,5 aller Netzwerke in der Welt DNS Anfragen abfangen und irgendwas damit machen. Und innerhalb von China zum Beispiel ist diese Rate noch höher. Da sind es fast ein Drittel aller DNS Abfragen oder aller Netzwerke, die DNS Abfragen dort abfangen und möglicherweise auswerten oder aber später auch noch verändern. Und das ist die Gefahr, weil das DNS Protokoll an sich, so wie es klassisch implementiert ist, nicht verschlüsselt ist und nicht authentisiert ist, da gibt es halt die Gefahr, einmal dass über die Auswertung der DNS Daten Leute bewacht werden oder aber, dass die DNS Daten geändert werden, um damit Angriffe zu fahren. Eine Lösung hier ist, dass man den Transport der DNS Daten vom Kleingerät zum DNS Server verschlüsselt. Und da gibt es mehrere Technologien und da haben sich jetzt neue Thermologien, das heißt neue Begriffe herausgebildet. Das klassische DNS, das über UDP oder TCP port 35 geht, das wird heute auch oft jetzt DO 53 genannt, also DNS über port 53. Im Gegensatz dazu die neuen Technologien, DOT, DNS über TLS läuft über port 853 oder DNS über HTTPS, das ist DNS über port 443 und HTTPS. In der Zukunft werden wir noch DNS über Qwik sehen, ein neues Transport Protokoll, kein Transport Protokoll, aber auch ein neuer Begriff ist DOC, DNS über Cloud und damit meint man DNS Namensauflösung über Cloud Service, so was wie Quartenein, Cloudflare oder Google. So, es gibt das DNS über TLS, das gibt es schon ein bisschen länger, schon 4, 5 Jahre lang und das benutzt einen dedizierten Port, port 853 und ermöglicht uns Verschlüsselung und Authentisierung der DNS Daten. Als Alternative dazu wurde ein wenig später, dass DNS über HTTPS entwickelt. Grund hierfür ist, dass das vorherige Protokoll, das DNS über TLS, einen dedizierten Port benutzt, nämlich 853. Und dieser Port in vielen Netzwerken blockiert ist und das neue Protokoll deswegen nicht benutzt werden kann. DNS über HTTPS benutzt port 443, benutzt HTTPS, das gleiche, was Benutzer auch zum Rausen von verschlüsselten Webseiten verwenden und der port 443 ist in den allermeisten Netzwerken offen und kann benutzt werden. Die Idee hierbei ist, dass man die DNS Anfragen und auch Antworten innerhalb des normalen DNS Datenverkehrs verstecken kann. Also bietet uns das DOH Verschlüsselung, Authentisierung und das Verstecken der Daten. Hier nochmal die Unterschiede zwischen DOT und DOH. DOT kann einfach geblockt werden, da es auf einem dedizierten Port läuft. Bei DOH ist das nicht so einfach, weil wenn wir port 443 oder wenn ein Provider port 443 blockt, dann geht auch das normale Web-Brausen nicht mehr. Intern ist das DNS über HTTPS so gebaut worden mit Padding zum Beispiel, dass die DNS Datenpakete größer sind, sodass sie möglichst nicht unterscheidbar sind von normalem HTTPS-Treffling, sodass selbst mit Deep Inspection Technologien es sehr schwierig sein soll, aber wohl nicht unmöglich, dass man DOH Verkehr selektiv blockt. Zudem ist DOH einfach zu implementieren oder einfacher zu implementieren. Es gibt ganz, ganz viele HTTPS Bibliotheksfunktionen in allen möglichen Programmiersprachen, Python, Ruby, Go und so weiter. Und Programmierer müssen nicht das Rad neuer finden, müssten keine eigene DNS Bibliothek erzeugen, sondern können auf die schon bestehenden HTTPS Bibliotheksfunktionen aufbauen. Und mit DOH können Entwickler denes Namensauflösung auf der Applikationsebene machen. Das ist für die Anwendungsentwickler erst mal etwas Tolles, weil es einfacher ist und sie das unabhängig vom Betriebssystem machen können. Es gibt aber Leute wie Systemadministratoren, die durchaus sagen, ja, das ist jetzt ein Wildwuchs, macht die Fehlersuche und auch das Betreiben eines Netzwerks eblich schwieriger und auch das ist wahr und richtig. Jetzt gibt es bei dem DNS bei HTTPS ein Dilemma. Um möglichst viele Internetbenutzer zu erreichen, müsste das DOH in Applikationen standardmäßig angeschaltet werden. Und das hat zum Beispiel Mozilla im Firefox gemacht in Amerika. Sie haben sich zwei, drei Partner gesucht, mit denen sie das implementiert haben. Diese Partner haben DOH Server laufen, unter anderem ist das Cloudflare und NS1, aber auch Comcast und diese Partner bekommen dann die DNS-Anfragen vom Firefox-Browser. Das ist aber aus anderer Sicht schlecht, weil es führt zu einer Zentralisierung aller DNS-Anfragen auf ein paar wenige DNS-Betreiber und diese DNS-Betreiber haben dann eine sehr große Datenquelle und können damit Leute überwachen, Internetbenutzer überwachen. Dieses Problem dieses Dilemma ist der ITF bekannt und daher arbeitet die ITF an alternativen Implementationen und Erweiterungen des DOH, zum Beispiel an dem Adaptive DNS Discovery. Wenn man das DOH in seinem Netzwerk nicht haben möchte, dann kann man eine sogenannte Canary Domain definieren, die ist zurzeit use-application-dns.net und wenn diese Domain aufgelöst werden kann und zwar über klassisches DNS, dann wird davon ausgegangen vom Browser, also vom Firefox-Browser, dass dies ein nicht gemanagetes DNS in einem Netzwerk ist. Das heißt DNS über HTTPS wird automatisch angeschaltet. Kann diese Domain jedoch nicht aufgelöst werden, das heißt sie ist geblockt, das müsste wirklich im Netzwerk manuell jemand eingerichtet haben, dann wird davon ausgegangen, dass DOH in diesem Netzwerk nicht gewünscht ist und der Browser wird es denn nicht anschalten. Der Benutzer kann es trotzdem weiterhin manuell anschalten. Diese Domain, use-application-dns.net, ist von Mozilla sich so implementiert worden. Es gibt aber in der ITF eine Diskussion, um das Ganze zu standardisieren, um einen Standard zu haben, wie man DOH kontrollieren kann und wie man signalisieren kann, was denn der Betreiber des Netzwerkes gerne zeigen oder haben möchte in seinem Netzwerk. Zusätzlich zudem prüft der Firefox noch andere Sachen ab, das heißt, guckt, ob die Safe-Search-Varianten von Google oder YouTube benutzt werden oder unter Windows oder macOS, ob spezielle Kinderschutzprogramme installiert sind, die den Content filtern und ob der Firefox in einem gemanagten Enterprise-Netzwerk läuft, das heißt, ob es da eine spezielle Enterprise-Konfiguration für den Firefox gibt. So, jetzt kommt der Update. Was ist der derzeitige Status von DOT und DOH? Im Firefox ist es implementiert und Cloudflare ist default eingestellt, Next-Dns ist eine Alternative und Comcast-Exfinity müsste jetzt schon langsam drin sein, im Firefox allerdings in Amerika. In Europa ist der Rollout noch nicht gestartet. In Amerika läuft der Rollout seit Februar 2020. Die Chrome-Browser haben was implementiert, haben den es über HTTPS implementiert, jedoch nicht automatisch angeschaltet. Google experimentiert derzeit mit dem Adaptive, DOH Resolver Discovery, da werde ich gleich im Detail noch zeigen, wie das funktioniert anhand der Apple-Implementierung. Der Safari-Browser hat es jetzt mit dem iOS 14 und MacOS 11 implementiert. Im Windows 10 wird es in dem Frühjahrs-Update 2021 drin sein. Der System-D Resolve-D im Linux, der unterstützt den es über TLS, schon längere Zeit, allerdings nur in einem opportunistischen Modus, das heißt, es gibt einen automatischen Fallback auf das klassische DNS und es gibt keine Authentisierung des Servers. Das heißt, die Sicherheit hier ist nur so nicht so gut, weil man in der Mittelangriffe sind weiterhin noch möglich. Es ist auch nicht von Hause aus angeschaltet, sondern der Benutzer muss reingehen in die Config-Datei und das dort anschalten. DOT, den es über TLS wird im OpenBSD durch den Unwind-Demon unterstützt, muss es auch angeschaltet werden. Gegenüber der Linux-Variante gibt es hier aber einen Strict-Modus und der Server wird über ein TLS-Zertifikat auch authentisiert. Der Strict-Modus bestimmt, dass nur verschlüsselt des DNS zulässig ist und kein Fallback auf unverschlüsselt des DNS durchgeführt wird. Im Endrate ist DNS über TLS seit Endrate 9 drin. Das ist eine manuelle Einstellung. Es muss manuell angeschaltet werden. Und die neuen Apple-Betriebssysteme, das MacOS 11 und das iPadOS 14 oder iOS 14, unterstützen sowohl DNS über TLS und DNS über HTTPS und hier hat Apple etwas Neues implementiert, nämlich das Adaptive Resolver Discovery und das werde ich jetzt mal im Detail noch vorstellen. Die Idee beim Adaptive DNS über HTTPS ist, dass niemand außer dem Client und dem Endserver sehen kann, wer denn überhaupt anfragt und was überhaupt angefragt werden soll. Wobei der Server, der hinter die DNS-Anfrage beantwortet, der soll gar nicht mitkriegen, welcher Client denn überhaupt die Anfrage gestellt hat, sodass keine zentrale Datensammlung möglich ist. Das Ganze ist implementiert über neue DNS-Resource-Rekords. Da gibt es den HTTPS-VC und den HTTPS-Rekord und zusätzlich kann es noch über spezielle All-Service-Header auf einer Website implementiert sein oder über sogenannte Well-known-URLs, die dann einfach ausprobiert werden können. Eine weitere Möglichkeit in IPv6-Netzwerken ist eine lokale Provisioning-Domain. So dieser HTTPS-SVC-Rekord oder auch HTTPS-Rekord, der gibt alle möglichen Informationen. Es ist sozusagen ein neuer Rekord, der auf längere Ansicht den A- und Quad-A-Rekord ablösen soll. Weil heute, wenn wir eine Website aufrufen, muss unser Browser mehrere DNS-Anfragen stellen. Er fragt erst mal für die IPv6-Adresse, er fragt dann für die IPv4-Adresse. Für verschlüsseltes ESNI braucht er auch noch einen Public-Key für das Encrypted-Client-Hello. Der würde auch noch mal über den DNS angefragt und das würde den Aufruf der Seite doch rechtlich verzögern. Und deswegen hat man sich gedacht, man packt alle diese Informationen in einen neuen DNS-Ressource-Rekord. Das ist der HTTPS-Rekord. Der wird einmal angefragt und dort befindet sich die IPv6-Adresse-Information, die IPv4-Adresse-Information. Erfindet sich Informationen über welches Protokoll, den der Web-Server reichbar ist, ist das HTTPS, HTTPS2 oder sogar schon HTTPS3 Quick. Die Public-Key für das Encrypted-Client-Hello finden wir da drin. Und andere Informationen wie zum Beispiel den DOH-Server, den Encrypted-DNS-Resolver, der benutzt werden soll. Und hier ist so ein Example, wie so ein HTTPS oder HTTPS SVC-Rekord aussehen kann. Das spinge ich mal drüber. Genau, das wollte ich hier zeigen. Diese Grafik zeigt jetzt, wie so eine Namensauflösung mit Adaptive DNS-Discravory funktioniert. Es ist ein bisschen wie Onion-Routing. Das heißt, wer das Tor-Netzwerk kennt, dem kommen vielleicht einige Sachen hier bekannt vor. Zuerst fragt unser Client über ganz normales DNS nach dem HTTPS-Rekord für Resolver.apa, um herauszukriegen, ob es einen lokalen HTTPS-Resolver gibt. Da kommt eine Antwort zurück. Zusätzlich kann er noch weitere Informationen über lokale Resolver bekommen, zum Beispiel über das Router-Advertisement mit der Provisioning-Domain von einem IPv6-Router. Alle diese Daten werden gesammelt und diese Daten werden dann nochmal verifiziert. Das heißt, wenn er von einem IPv6-Router Informationen über die Provisioning-Domain bekommen hat, über einen speziellen HTTPS-fähigen DOH-Server, dann fragt er den schon mal an und guckt, ob er den erweichen kann, ob er den authentisieren kann. Ist das geschehen, möchte jetzt der Client in der Verbindung aufbauen zu der Webseite, example.com und deswegen stellt er erst mal eine normale DNS-Anfrage über einen klassischen DNS-Server und fragt jetzt nach dem HTTPS-Rekord für diese Webseite und dieser DNS-Rekord beinhaltet jetzt auch Informationen über die designated DOH-Resolver, das heißt, die von dem Betreiber der Webseite vorgeschlagenen DOH-Resolver, die die Ressourcen für die Webseite auflösen können. Das heißt, wir haben jetzt noch nicht zwangsläufig die IP-Adresse von der Webseite, sondern wir wissen jetzt erst mal, welchen Server dürfen wir benutzen. Dieser designated DOH-Server wird jetzt angefragt und wir bekommen eine Antwort zurück für diesen Server, für welche Domain namen dieser Server denn der designierte DNS-Resolver ist. Diese Kommunikation sollte idealerweise mit DNS-Sec abgesichert sein. Und jetzt beginnt das Spannende. Der Client möchte jetzt www.example.com kontaktieren, den Web-Server, der oben in der Mitte steht. Er erzeugt sich einen neuen Schlüssel und sendet die Anfrage verschlüsselt mit dem öffentlichen Schlüssel des DOH-Resolvers, DOH-Example.com, der auf der rechten Seite in der Mitte steht, den er soeben angefragt hatte. Bei der Anfrage hatte er den öffentlichen Schlüssel bekommen. Er verschlüsselt diese Anfrage für diesen Server. Er sendet die Anfrage aber nicht an den Server, sondern sendet die Anfrage an einen beliebigen anderen DOH-Resolver im Internet, den er kennt. Hier ist es der DOH-Resolver ganz unten, der DOH-Example X, Y und Z. Dieser bekommt jetzt die Anfrage und sieht, Die Anfrage ist gar nicht für mich. Die Anfrage ist für den Resolver-DOH-Example.com. Die Anfrage ist selbst verschlüsselt, sodass dieser erste Hopp, dieser DOH-Resolver-Example X, Y und Z, nicht reingucken kann und nicht sehen kann, für welchen Namen dieser Anfrage überhaupt ist. Das heißt, dieser erste Hopp kennt nur die IP-Adresse des Absenders, des Clients, weiß aber nicht, was gefragt wird. Er weiß aber, wo die Frage hingesendet werden soll und liefert diese Verschüssteanfrage weiter an den DOH-Resolver in der Mitte, den DOH-Example.com. Der bekommt jetzt diese DNA-Anfrage und die ist mit seinem öffentlichen Schlüssel verschlüsselt. Das heißt, er kann sie mit seinem privaten Schlüssel entschlüsselt und kann reingucken und sieht, das ist eine DNA-Anfrage für www.example.com. Entweder kann er das direkt selber beantworten, weil er das schon im Cash hat oder aber ergibt es an einen klassischen DNA-Autoritiven Server weiter, das ist der, der weiter oben steht, der autorative DNA-Example.com. Dieser DOH-Resolver weiß jetzt, was gefragt wurde, weil er weiß, es wurde nach www.example.com gefragt. Er weiß aber nicht, von wem diese Frage gestellt wurde, weil er hat das Paket von einem anderen DOH-Resolver bekommen und das ist jetzt, was so ein wenig wie das Onion-Routing ist. Die einzelnen Server, die hier zusammenspielen, sehen immer nur ein Teil der Information. Ein Server weiß, welcher Klein gefragt hat, weiß aber nicht, was gefragt wurde, während der andere Server weiß, was gefragt wurde, aber nicht weiß, wer hat die Frage gestellt, so dass eines zentrales Datensammel nicht mehr so möglich ist, wie das bei den ersten Implementationen von DOH der Fall ist. Der autorative Server antwortet über klassisches DNS. Der DOH-Resolver verschlüsselt jetzt die Antwort mit dem Schlüssel, den der DOH Klein mitgesendet hat mit der Anfrage und sendet jetzt das verschlüsselte Paket an den DOH-Resolver ganz unten. Der kriegt jetzt die Antwort, kann ihn die Antwort aber nicht reingucken, weil sie für den Klein verschlüsselt ist. Er weiß aber, dass diese Antwort von dem Klein, oder Entschuldigung, dass diese Anfrage eine Antwort für den Klein ist. Er schickt es an den Klein weiter. Der Klein kann die Anfrage entschlüsseln und kann eine Verbindung zu dem Web-Server aufbauen. Das sieht jetzt aus, dass wenn das viel viel mehr Arbeit ist als klassisches DNS. Implementationsversuche haben aber gezeigt, dass aufgrund von Caching und dadurch, dass zum Beispiel der DOH-Resolver gleichzeitig auch autorativer DNS-Server sein kann, dass wir genauso viele Hops, genauso viele Server haben, wie bei dem klassischen DNS, dass die Geschwindigkeit auch vergleichbar ist. Ja und damit bin ich am Ende meines kleines kleinen Updates über DNS-Transportsicherheit und was ich in den letzten anderthalb Jahren da getan hat. Danke schön, lieber Karsten. Wir haben, wenn ich das richtig sehe, aktuell noch keine Fragen bekommen. Aber ich glaube, es haben einige schon einen Vortrag heute Morgen gesehen um diese nachtschlafenden Zeit. Gleich geht es weiter hier auch mit dem nächsten Vortrag und wir hoffen, dass du irgendwann noch mal vortragst, auch vielleicht dann mal persönlich. Danke schön. Gerne. Viel Spaß noch.