Keep It Encrypted, Keep It Safe: Arbeiten mit ESNI, DoH und DoT

Zu den neuesten Entwicklungen zum Schutz der Privatsphäre im Internet gehören die verschlüsselte TLS-Servernamensanzeige (ESNI) und das verschlüsselte DNS in Form von DNS over HTTPS (DoH), die beide von Datensammlern als höchst umstritten angesehen werden.

Hier ist ein kurzer Blick auf die Gründe, warum sie existieren, die Details darüber, was sie sind, und die Technologie hinter ihrer Funktionsweise.

DNS muss richtig funktionieren

Split-Tunnel-VPN-Verbindungen (Virtual Private Network), das Web-Proxy-Auto-Discovery-Protokoll (WPAD), Zero-Configuration-Multicast-DNS (mDNS), Echtzeit-Blacklists (RBL) und viele andere weit verbreitete Technologien brechen zusammen, wenn DNS nicht funktioniert nicht richtig funktionieren.

Breaking the Internet für Profit und Ruhm

Bereits 2003 erfuhren Internetnutzer von der Bedeutung von DNS auf globaler Ebene, als das Unternehmen, das damals die Top-Level-Domain (TLD) .com betrieb, beschloss, die Ausgabe von NXDOMAIN Antworten einzustellen. Stattdessen gaben sie sich als eine nicht existierende Domain aus, um mehr Anzeigen zu schalten, mehr Domains zu verkaufen und letztendlich mehr Umsatz zu generieren. Der unerwartete Dominoeffekt führte zu einer öffentlichen Debatte und einem vernichtenden Bericht des Security and Stability Advisory Committee (SSAC) von ICANN. Dieses Projekt wurde tatsächlich eingestellt, aber aus technischer Sicht blieb die Schwachstelle bestehen.

Später im Jahr 2008 wurde ein weiterer Versuch, DNS zu Profitzwecken zu manipulieren, öffentlich ausgerufen, als einige der größten ISPs schließlich verschiedene Möglichkeiten für Cross-Site-Scripting-Angriffe gegen buchstäblich jede Website einführten. Aufgrund der Art der Schwachstellen können sogar Websites, die in einem privaten Netzwerk gehostet werden und nicht über das Internet zugänglich sind, ausgenutzt werden.

Das gefundene Problem liegt nicht bei den zentralen Internetprotokollen, sondern ist ein Problem, das durch die unangemessene Monetarisierung bestimmter DNS-Funktionen verschärft wird.

Paul Vixie, Internet Systems Consortium (ISC)

Obwohl es stimmt, dass die Protokolle selbst nicht wirklich die Ursache des Problems sind, ist es auch wahr, dass diese Protokolle schlechte Akteure nicht daran hindern, das System zu missbrauchen. Aus technischer Sicht blieb die Schwachstelle also bestehen.

Breaking the Internet für Überwachung und Zensur

Im Jahr 2016 wurde beobachtet, dass ISPs im Iran DNS manipulierten. Anstatt Werbung einzuschleusen, blockierten sie dieses Mal den Zugang zu den E-Mail-Servern von 139 der Top-10.000-Domains im Internet. Es ist nicht klar, ob dies eine absichtliche Denial-of-Service-Politik gegen diese spezifischen Domänen ist – ähnlich der weltberühmten Zensur in China – oder vielleicht nur ein Beispiel für eine schlechte technische Implementierung des Systems, das die DNS-Anfragen abfängt.

Nicht zu wissen, warum DNS abgehört wird, ist wichtig: Auch wenn wir die moralischen und rechtlichen Fragen zur flächendeckenden Überwachung und Zensur beiseite lassen, ist die dafür verwendete Technologie von Natur aus nicht standardkonform und könnte sehr wohl stören Ihre normale, alltägliche, angemessene und rechtmäßige Nutzung des Internets.

Aus technischer Sicht blieb die Schwachstelle jedoch bestehen.

Brechen des Internets für schändliche Zwecke

Natürlich sind es nicht nur kommerzielle Unternehmen und Regierungen, die versuchen, den Internetverkehr für ihre eigenen Zwecke abzufangen. Es gibt viele Beispiele für Kriminelle, die versuchen, Verbindungen zu hijacken, normalerweise um Benutzerdaten zu stehlen oder Benutzer dazu zu bringen, wichtige Zugangsdaten preiszugeben. Am prominentesten wurde DNS-Cache-Poisoning verwendet, um Benutzer auf Phishing-Sites zu leiten, Ransomware bereitzustellen, Botnets bereitzustellen, bestimmten Websites den Dienst zu verweigern und vieles mehr.

TLS-Lecks, wer sich mit wem verbindet

Transport Layer Security (TLS) ist die Technologie hinter HTTPS, der sicheren Version von HTTP, auf die wir uns alle täglich verlassen. Der Aufbau einer TLS-Verbindung erfordert eine Reihe von Schritten, in denen der Server seine Identität durch Vorlage eines Zertifikats nachweist und neue Verschlüsselungsschlüssel ausgetauscht werden.

Es ist ein sehr wichtiger Schritt, dass der Server ein Zertifikat verwendet, um seine Identität nachzuweisen, da ein Teil des Zertifikats ein asymmetrischer öffentlicher Verschlüsselungsschlüssel ist.

Wenn der Client eine Nachricht mit diesem Schlüssel sendet, kann nur der Server, der im Besitz des zugehörigen privaten Schlüssels ist, die Nachricht lesen. Infolgedessen wird jeder, der die Verbindung abfängt oder abhört, ausgesperrt und kann den Inhalt nicht lesen.

Dieser anfängliche Austausch erfolgt jedoch immer noch unverschlüsselt ohne Verschlüsselung, was bedeutet, dass ein Beobachter immer die Identität des Servers kennt.

Domain-Fronting

Einige Anti-Zensur-Tools haben dieses Leck in TLS für eine gewisse Zeit mithilfe einer Technik namens Domain Fronting umgangen. Dabei wird die Tatsache ausgenutzt, dass die meisten großen Hosting-Anbieter nach dem Aufbau einer HTTPS-Verbindung nicht prüfen, ob der in jeder HTTP-Anforderung angegebene Hostname mit dem im TLS-Handshake verwendeten übereinstimmt. In Bezug auf Datenschutz-Tools wurde dies als nützliche Funktion angesehen, die eine geheime Kommunikation mit einer versteckten Site ermöglicht. Für Hosting-Anbieter und Datensammler wurde dies als Missbrauch der Art und Weise angesehen, wie die Spezifikation implementiert wurde.

Dies ist an und für sich eine Schwachstelle und wurde als solche von mehreren großen Hosting-Anbietern, einschließlich AWS, behoben.

Lösung des Problems durch Änderung des Standards: Verschlüsseltes SNI (ESNI)

Die Idee hinter ESNI ist es, zu verhindern, dass TLS irgendwelche Daten verliert, indem alle Nachrichten verschlüsselt werden, einschließlich der anfänglichen Client Hello -Nachricht. Dies lässt jeden Beobachter völlig im Dunkeln darüber, welches Serverzertifikat der Server präsentiert.

Dazu benötigt der Client einen Verschlüsselungsschlüssel, bevor er die Verbindung herstellt. Daher erfordert ESNI, dass ein bestimmter Satz von ESNI-Verschlüsselungsschlüsseln in einem SRV-Eintrag in DNS platziert wird.

Die genauen Details dazu sind jedoch noch im Fluss, da die Spezifikation noch nicht abgeschlossen ist. Trotzdem wurde eine Implementierung von ESNI bereits von Mozilla Firefox und Cloudflare in Produktion genommen.

Sichern und Verschlüsseln von DNS

Damit ESNI-Schlüssel unabgefangen übermittelt werden können, ist es wichtig, sich gegen DNS-Manipulationen zu schützen.

Bereits seit 1993 versucht die Internet-Gemeinde DNS zu sichern. Die IETF stellt fest, dass bei frühen Problemlösungsmeetings Folgendes besprochen wurde:

1. Schutz vor der Weitergabe von DNS-Daten an Unbefugte
2. Gewährleistung der Datenintegrität
3. Datenursprungsauthentifizierung

Diese Treffen führten 1997 zum DNSSEC-Standard (Domain Name System Security Extensions). Der Standard entschied sich dafür, zwei von drei dieser Bedenken auszuräumen, da das Designteam eine ausdrückliche Entscheidung traf, alle Bedrohungen durch die Offenlegung von Daten ausdrücklich aus dem Geltungsbereich auszuschließen.

Als solches bedeutet DNSSEC, dass Benutzer darauf vertrauen können, dass die Antworten auf ihre DNS-Abfragen so sind, wie sie von Domaininhabern beabsichtigt sind. Im Zusammenhang mit ESNI bedeutet dies, dass wir wissen, dass der Schlüssel, den wir erhalten, nicht manipuliert wurde, und glücklicherweise verschwinden viele der oben erwähnten Schwachstellen, wenn DNSSEC verwendet wird. Es gewährleistet jedoch keine Privatsphäre und ist daher immer noch anfällig für Probleme, die durch Überwachungs- und Zensursysteme eingeführt werden.

Da es mit „unsicherem DNS“ vollständig abwärtskompatibel und ziemlich schwierig korrekt zu implementieren ist, ist die Akzeptanz von DNSSEC leider sehr gering. Viele Domain-Besitzer geben mitten im Versuch auf, sie zu konfigurieren, wie zahlreiche ungültige und halb eingerichtete Konfigurationen zeigen, die in freier Wildbahn zu sehen sind.

DNS über HTTPS (DoH)

Damit ESNI-Schlüssel übermittelt werden können, ohne dass Beobachter wissen, welche Website Benutzer zu besuchen versuchen, ist es wichtig, sich gegen DNS-Abhören zu schützen. Daher ist es ganz logisch und verständlich zu sagen, dass verschlüsseltes DNS (wie bei DoH) eine gute Sache ist. So wie es heute aussieht, ist DNS jedoch nicht verschlüsselt.

Es gibt Schritte von Mozilla, Google, APNIC, Cloudflare, Microsoft und anderen, dies zu ändern.

Die ideale verschlüsselte Benutzererfahrung

Ein Benutzer, der die oben genannten Technologien nutzen möchte, hat möglicherweise eine ziemlich lange Liste von Anforderungen, wenn es um die praktischen UX-Details für die Arbeit mit Verschlüsselung geht. Wahrscheinlich möchten sie Folgendes vermeiden:

• Gezwungen zu sein, einen bestimmten DNS-Dienstanbieter zu verwenden (egal wie gut er ist) oder dass die Auswahl unsichtbar oder schwer zu finden ist
• Jede App auf einem Gerät handhabt DNS anders (z. B. kann Firefox Dinge finden, die Safari nicht kann)
• Alle Apps auf einem Gerät müssen ihre eigene sichere DNS-Implementierung in sich selbst erstellen
• DNS mehrmals manuell konfigurieren müssen
• Sie müssen sich für Datenschutz und Sicherheit entscheiden
• Apps, die ohne Zustimmung des Benutzers auf einen unsicheren Betrieb zurückfallen

Datenschutzbewusste Benutzer möchten stattdessen:

• Schutz vor ungerechtfertigter Überwachung durch Dritte
• Schutz vor gezielter Werbung, der sie nicht zugestimmt haben
• Schutz der eigenen veröffentlichten Inhalte (z. B. auf einer eigenen Website) vor Veränderung oder Manipulation auf dem Weg zu anderen Betrachtern
• Gewissheit, dass Betrachter ihrer eigenen veröffentlichten Inhalte nicht in Schwierigkeiten geraten, nur weil sie darauf zugreifen
• Um weiterhin die Möglichkeit zu haben, DNS in ihren eigenen Netzwerken zu kontrollieren (weil Split-Horizon-DNS manchmal gut ist, um interne Ressourcen auf interne Benutzer zu beschränken)
• Die Möglichkeit, der Filterung auf DNS-Ebene zuzustimmen oder sie zumindest abzulehnen (z. B. Quad9, CleanBrowsing und OpenDNS Family Shield)
• Einfache, problemlose Konfiguration (z. B. DHCP)
• Um die Zustimmung zur Verwendung von DNS ohne Verschlüsselung gebeten zu werden
• Schutz nicht nur für Browserverkehr, sondern für alle Arten von Verkehr, z. B. E-Mail, Slack, VoIP, SSH, VPN usw.

Aktuelle Verschlüsselungsbemühungen

Welche Optionen gibt es für Benutzer mit den oben genannten Zielen?

Mozillas Lösung ist ein Anfang, aber alles andere als ideal. Sie sichern nur Firefox; Die Standardeinstellung besteht darin, Ihre Betriebssystemeinstellungen zugunsten der Wahl des Anbieters (Cloudflare) zu überschreiben, ohne dies zu sagen, und es fällt stillschweigend auf unsicher zurück (in Fällen, in denen verschlüsseltes DNS blockiert wird usw.).

Die Lösung von Google ist ein besserer Ansatz. Sie sichern Android 9+ ab – was für alle Apps gilt. (Ich bin mir nicht sicher über ihre Pläne für Chrome OS, aber ich vermute, dass es in Arbeit ist.) Sie sichern Chrome auch auf allen Plattformen, aber es löst nur Sicherheit aus, wenn die Host-Plattform so konfiguriert ist, dass sie einen Anbieter verwendet, der Sicherheit unterstützt. Dies ist in Bezug auf die Benutzerauswahl gut, aber nicht ideal, da es stillschweigend auf Unsicherheit zurückfällt.

Alle anderen gängigen Browser implementieren ebenfalls Unterstützung.

In der idealen Situation für Benutzer würde die breitere Gemeinschaft von Software- und Betriebssystementwicklern:

1. Stoppen Sie die Implementierung neuer DNS-Sicherheitsfunktionen auf Anwendungsebene
2. Beginnen Sie mit der Implementierung auf Betriebssystemebene
3. Beachten Sie die Konfiguration auf Betriebssystemebene oder holen Sie die Zustimmung des Benutzers ein

Durch die Implementierung von verschlüsseltem DNS auf Betriebssystemebene könnten wir weiterhin dem gleichen verteilten Modell folgen, das wir derzeit für DNS-Auflöser haben. Das Betreiben eines eigenen DNS-Servers im eigenen Netzwerk und die Möglichkeit, diesen Resolver sicher zu machen, ist weiterhin eine sinnvolle Option, ebenso wie die Verwendung eines zentralisierten Anbieters.

Linux und BSD verfügen bereits über diese Funktionalität mit einer Vielzahl verfügbarer Optionen. Leider aktiviert keine Distribution sie standardmäßig, soweit ich weiß. Schauen Sie sich nss-tls an, wenn Sie etwas wollen, das sich einfach in glibc einklinken lässt.

Auch die DNS-over-TLS-Implementierung von Google in Android 9+ tut dies bereits. Es funktioniert, indem der DNS-Server auf Verschlüsselungsunterstützung getestet wird. Wenn es es hat, dann wird es es benutzen. Wenn dies nicht der Fall ist, wird es – wie bei Chrome – auf unsichere Weise fortgesetzt, ohne dass Sie zur Zustimmung aufgefordert werden.

Es ist erwähnenswert, dass die meisten Netzwerke so konfiguriert sind, dass sie DNS-Server verwenden, die keine Verschlüsselung unterstützen, sodass die in Android integrierte Lösung für die meisten Benutzer noch nichts ändert. Vielleicht wäre es besser anzubieten, auf ein zentralisiertes verschlüsseltes DNS zurückzugreifen, wenn die dezentrale Verschlüsselung nicht unterstützt wird.

Für Apple- und Microsoft-Flavour-Geräte muss die Unterstützung für verschlüsseltes DNS zum jetzigen Zeitpunkt noch offiziell eintreffen. Nachdem Microsoft im November 2019 seine Absicht angekündigt hat, verschlüsseltes DNS zu unterstützen, wird Apple hoffentlich bald folgen.

Verschlüsselte DNS-Problemumgehungen

Es gibt einige Problemumgehungen in Form von Proxys, die lokal ausgeführt werden können. Mit diesen spricht der Computer eines Benutzers unverschlüsseltes DNS mit sich selbst, der dann verschlüsseltes DNS mit dem Provider spricht, für dessen Verwendung er konfiguriert ist. Dies ist keine ideale Lösung, aber als Problemumgehungen ist es anständig.

Die Inspiration zum Schreiben dieses Artikels war der DNSCrypt-Proxy, der sehr stabil ist, viel Schnickschnack hat und plattformübergreifend ist. Es unterstützt das ältere DNSCrypt-Protokoll sowie die neueren Protokolle DNS über TLS (DoT) und DNS über HTTPS (DoH).

Für Windows-Benutzer gibt es ein Installationsprogramm und eine GUI namens Simple DNSCrypt, die alle Funktionen enthält und sehr einfach zu bedienen ist.

Ich empfehle es, aber seien Sie sich bewusst, dass die Welt wahrscheinlich noch nicht bereit für Sie ist und Sie es möglicherweise von Zeit zu Zeit deaktivieren müssen (z. B. wenn Sie ein Captive-Portal in Ihrem Lieblingscafé oder in einem LAN verwenden müssen Gruppe).

Andere Optionen

Darüber hinaus gibt es den Technitium-DNS-Server, der verschlüsseltes DNS unterstützt, plattformübergreifend ist (Windows, MacOS, Linux auf ARM/Raspberry Pi) und über eine schicke Weboberfläche verfügt. Es steht unter „Sonstiges“, weil es eher ein Allround-Tool als eine spezifische Lösung für dieses Problem ist. (Es wäre wahrscheinlich eine gute Wahl, wenn Sie Ihren Raspberry Pi-DNS-Server zu Hause betreiben möchten. Ich wäre daran interessiert, Feedback von Leuten zu hören, die es in den Kommentaren unten ausprobieren.)

Für Ihre Android- oder iOS-Geräte (iPhone, iPad usw.) gibt es auch die 1.1.1.1-App, die alle Ihre DNS-Abfragen über den verschlüsselten DNS-Dienst von Cloudflare erzwingt. Ich habe gehört, dass es auch flexiblere Apps wie Intra gibt, aber ich habe noch nicht die Zeit damit verbracht, sie zu testen.

Natürlich können Sie verschlüsseltes DNS auch in Firefox und Chrome aktivieren – denken Sie nur an alle oben besprochenen Einschränkungen.

DNS-Zuverlässigkeit: Job Nummer eins

Es gibt viele Kontroversen über die Datenschutztechnologie im Internet. Bei der Implementierung von Sicherheits- und Datenschutzmaßnahmen geht es bei der betreffenden Technologie jedoch nicht in erster Linie um die Wahrung von Geheimnissen. Es geht darum, Zuverlässigkeit zu gewährleisten und zu gewährleisten, dass die Technik trotz des Verhaltens anderer weiterhin korrekt funktioniert. Wir müssen uns jedoch darüber im Klaren sein, dass Technologie ohne Schutzmaßnahmen für die Privatsphäre ebenso schlecht ist wie schlecht implementierte Schutzmaßnahmen die Situation nur verschlimmern können.