Verschlüsseltes DNS: DoH und DoT

Die vorige Lektion beschrieb eine gewöhnliche DNS-Abfrage als Postkarte: lesbar für jeden, der sie unterwegs in die Hand bekommt. Zwei IETF-Standards existieren, um diese Postkarte in einen Umschlag zu stecken: DNS over TLS (DoT, RFC 7858) und DNS over HTTPS (DoH, RFC 8484). Beide verschlüsseln dieselbe Abfrage; sie unterscheiden sich vor allem darin, wie sie sie transportieren.

DNS over TLS

RFC 7858 nennt sein Ziel unmissverständlich: „Die von TLS bereitgestellte Verschlüsselung beseitigt Möglichkeiten des Abhörens und der Manipulation von DNS-Abfragen auf dem Übertragungsweg“, als Antwort darauf, dass „nahezu alle DNS-Abfragen unverschlüsselt gesendet werden, was sie anfällig für das Abhören durch einen Angreifer macht.“ DoT verwendet einen eigenen, dedizierten Port, 853, statt des üblichen Ports 53. Das RFC erklärt warum: „Diese Empfehlung gegen die Nutzung von Port 53 für DNS over TLS soll Komplikationen bei der Wahl zwischen Nutzung und Nichtnutzung von TLS vermeiden und das Risiko von Downgrade-Angriffen verringern.“

DNS over HTTPS

RFC 8484 wählt einen anderen Weg: „Jedes DNS-Abfrage-Antwort-Paar wird auf einen HTTP-Austausch abgebildet“, transportiert über denselben Port 443, den gewöhnlicher HTTPS-Verkehr nutzt. Das RFC merkt einen Nebeneffekt an: „Der HTTPS-Standardport 443 und die Möglichkeit, DoH-Datenverkehr mit anderem HTTPS-Datenverkehr auf derselben Verbindung zu mischen, können nicht privilegierte Geräte auf dem Übertragungsweg davon abhalten, in DNS-Vorgänge einzugreifen“, weil eine Abfrage schwerer herauszugreifen und zu blockieren ist, wenn sie wie jede andere Webanfrage aussieht.

Was Verschlüsselung verbirgt, und was noch nicht

Beide Standards hindern einen Netzwerkbetreiber oder WLAN-Lauscher daran, Ihre Abfragen bei der Übertragung zu lesen. Keiner verbirgt sie vor dem Resolver, an den Sie sie gesendet haben. RFC 8484 stellt ausdrücklich klar, dass DoH nicht ändert, was der Server selbst sehen kann: Es merkt an, dass „verschiedene Übertragungswege von DNS-Abfragen und -Antworten Daten liefern, die zur Zuordnung von Anfragen genutzt werden können“, und dass gewöhnliche Web-Mechanismen wie Client-IP-Adressen, Cookies und TLS-Sitzungsinformationen bedeuten, dass „DoH bekanntermaßen keine neuen Bedenken über die mit HTTPS verbundenen hinaus einführt“ auf Serverseite. RFC 7858 merkt ähnlich an, dass DoT „andere Sicherheitsprobleme in DNS nicht adressiert“ und dass „selbst bei verschlüsselten Nachrichten eine gut positionierte Partei möglicherweise bestimmte Details aus einer Analyse von Nachrichtenzeitpunkten und -größen ableiten kann.“ Kurz: Verschlüsseltes DNS verlagert, wer Ihre Abfragen sieht, zurück zum von Ihnen gewählten Resolver-Betreiber, es entfernt die Sichtbarkeit nicht vollständig.

Es gibt eine zweite Lücke, die zu kennen sich lohnt. Die Verschlüsselung der DNS-Abfrage verbirgt für sich genommen nicht, mit welcher Seite Sie sich dann verbinden: Der anschließende TLS-Handschlag zeigt den Hostnamen normalerweise offen an. Wie Cloudflares Erklärung zu Server Name Indication (SNI) es ausdrückt: „SNI enthält den Hostnamen in der Client-Hello-Nachricht, dem allerersten Schritt eines TLS-Handschlags“ — gesendet, bevor Verschlüsselung überhaupt einsetzt. Eine Erweiterung namens Encrypted SNI (ESNI), so dieselbe Quelle, „baut auf der SNI-Erweiterung auf, indem sie den SNI-Teil der Client-Hello-Nachricht verschlüsselt“, was „verhindert, dass jemand, der zwischen Client und Server mithorcht, sehen kann, welches Zertifikat der Client anfordert.“ Die Unterstützung, SNI zu verbergen, hängt weiterhin davon ab, dass sowohl Browser als auch Website sich darauf einigen, und ist noch nicht Standard bei jeder Verbindung.

Wie macOS das unterstützt

Apple dokumentiert eine DNS-Einstellungskonfiguration für Mac, iPhone und iPad, die genau das tut: Sie lässt ein Gerät „die DNS-Abfragen eines Geräts über einen verschlüsselten DNS-Server mittels DNS over HTTPS oder DNS over TLS leiten.“ Sie wird als Konfigurationsprofil ausgeliefert, das den verschlüsselten Resolver über „zusätzliche Übereinstimmungsdomains“ auf bestimmte Domains beschränken oder nur in bestimmten Netzwerken über „On-Demand-Regeln“ anwenden kann, die etwa auf die SSID des Netzwerks abgestimmt sein können.