Datenschutz und Anonymität DNS over HTTPS

Laut Googles eigenem Transparenzbericht vom September 2019 sind 94 Prozent aller HTTP-Verbindungen verschlüsselt. DNS-Abfragen wandern aber nach wie vor im Klartext über das Ether, als ob sich in den letzten 30 Jahren nichts geändert hätte. Die Implikationen für die Privatsphäre und die Datensicherheit sind nicht von der Hand zu weisen.

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Arvato Systems

SEPPmail - Deutschland GmbH

Als Amazons autoritative DNS-Server Ende April letzten Jahres einer BGP-Hijack-Attacke zum Opfer fielen, hat unter anderem Googles rekursiver DNS-Service die gefälschten Routing-Tabellen akzeptiert und eingehende Anfragen an einen betrügerischen DNS-Dienst weitergeleitet, der sie an eine gefälschte Webseite richtete. Der Vorfall illustriert, dass allein HTTPS nicht genügt, um die Internet-Kommunikation wirklich abzusichern.

Das DNS-System (Domain Name System) übersetzt vollqualifizierte Domainnamen (kurz: FQDN für Fully Qualified Domain Names) in IP-Adressen. Gefälschte DNS-Server können betrügerische Webserver als legitime Web-Anbieter tarnen, Login-Daten mitschneiden und nicht zuletzt Malware vertreiben. Standardmäßig wandert eine DNS-Anfrage vom Client zum DNS-Resolver im Klartext; jede Zwischenstelle (jeder sogenannte On-Path-Router) kann diese Kommunikation mitschneiden und so die Aktivitäten des Nutzers mitverfolgen. Dieses Szenario spielt sich in der Realität auch tatsächlich ab, zum Teil mit sehr unangenehmen Konsequenzen für die Betroffenen. Ein MiTM (Man in the Middle) kann die Daten sowohl für den eigenen „Gebrauch“ erfassen als auch im Nachhinein im Darknet kommerziell vertreiben. Zu den unangenehmen Nebenwirkungen zählt ein erhöhtes Risiko von DNS-Spoofing und -Profiling durch unbefugte Dritte.

Video-Tipp: DNS-Sicherheit

DNS in Windows-Netzwerken absichern

Beim Aufruf eines entfernten Hostnamens sendet das lokale Endgerät eine Anfrage an einen rekursiven DNS-Server (die benötigte Adresse ist in den Einstellungen des Betriebssystems verzeichnet). Der rekursive DNS-Server befragt die Root-Server des Internets und wird von diesem auf denjenigen Name-Server verwiesen, der für die betreffende TLD (Engl. top-level domain) verantwortlich zeichnet. Dieser Server liefert dann die Nameserver der betreffenden DNS-Zone zurück, welche den Hostnamen in eine IP auflösen können. Dieser ganze Kommunikationsaustausch erfolgt im Klartext.

Da die Authentizität der NS-Informationsdienste im Normalfall nicht unabhängig verifiziert wird, können MiTM-Angreifer die Anfragen nicht „nur“ ablesen, sondern die Kommunikation auf manipulierte „Ersatzserver“ umlenken. Dem möglichen Missbrauch sind dann kaum Grenzen gesetzt. Die DNS-Server-Impersonation stellt eine ernsthafte Gefahr für die Integrität der Internet-Kommunikation dar.

Die Internet-Gemeinde hat mehrere mögliche Lösungen konzipiert, nur konnte sich bisher keine davon auf breiter Front durchsetzen.

Das Pro und Contra der DNS-Verschlüsselung

DNS over HTTPS (kurz DoH) und DNS über TLS (kurz DoT) stellen zwei Versuche dar, DNS-Abfragen vor der Neugier Unbefugter zu schützen. Bei beiden Lösungen handelt es sich um IETF-Standards bzw. RFC-Entwürfe. (Die IETF, die Internet Engineering Task Force, ist eine gemeinnützige Organisation, die für die Verabschiedung offener Internet-Standards verantwortlich zeichnet und ein hohes Ansehen genießt.)

Die IETF definiert DNS über HTTPS in RFC 8484 (HTTPS und HTTP/2 über Port 443) und DNS über TLS (Portnummer 853) in RFC 7858 und RFC 8310. Beide Protokolle verschlüsseln DNS-Anfragen, können die Antworten jedoch nicht authentifizieren.

DNS über TLS erfordert die Freischaltung der Portnummer 853. Die Kommunikation ist dadurch leicht zu identifizieren und zu unterbinden.

DNS über HTTPS „verschwindet“ stattdessen ganz unverdächtig in der Flut der üblichen HTTPS-Kommunikation über die Portnummer 443 (statt wie sonst üblich im Klartext durch den Port 53 zu wandern). DoH erschwert damit aber auch das Inspizieren der Datenpakete in Unternehmen. In Unternehmen, die BYOD erlauben, soll DoH das Monitoring dieser Geräte nahezu unmöglich machen, jammern die schärfsten Kritiker.

DoH stößt insbesondere in Europa im Zusammenhang mit der DSGVO auf Zustimmung. Auch an Kritik mangelt es jedoch nicht.

DNS-over-HTTPS funktioniert auf Anwendungsebene. Apps können intern fest codierte Listen von DoH-kompatiblen DNS-Resolvern führen, über die sich DoH-Abfragen versenden lassen. In diesem Betriebsmodus ist es möglich, die auf Betriebssystemebene vorhandenen Standard-DNS-Einstellungen des ISPs zu umgehen. Anwendungen mit Unterstützung für das DoH-Protokoll könnten sich so den Datenverkehrsfiltern lokaler ISPs effektiv entziehen und auf ansonsten gesperrte Inhalte zugreifen.

Doch einen vollständigen Schutz der Anonymität bieten sie nicht. Denn beim Einsatz von DoH ist es für ISPs möglich, immerhin noch andere unverschlüsselte Teile der Kommunikation mitzuschneiden. Dazu zählen nicht zuletzt SNI-Felder und OCSP-Verbindungen.

SNI, kurz für Server Name Indication, ist eine Erweiterung des TLS-Protokolls zur Bereitstellung mehrerer Zertifikate pro IP-Adresse. Bei OCSP, kurz für Online Certificate Status Protocol, handelt es sich um eine Methode zum Ermitteln der Gültigkeit von X.509-Zertifikaten. Google hat im Übrigen OCSP-Prüfungen in Chrome unter Berufung auf intolerable Latenzen und unzureichenden Datenschutz bereits im Jahre 2012 standardmäßig deaktiviert und vertraut stattdessen auf einen eigenen Dienst. So lassen sich nämlich die Anfragen mehrerer Endgeräte aggregieren und die Anonymität der einzelnen Nutzer gegenüber der Zertifikatsbehörde wahren.

Firefox nutzt stattdessen OCSP-Stapling (der Browser vertraut also auf die Aussagen der betreffenden Webseite, statt auf die Bestätigung der Zertifikatsbehörde zu warten, was im Falle von DNS-Spoofing natürlich nach hinten los geht) und nutzt OCSP als ein Fallback. Sollte beim OCSP-Fallback die authoritative Antwort der zuständigen Zertifikatsbehörde ausbleiben, geht Firefox allerdings leider stillschweigend zur Tagesordnung über, statt den Verbindungsaufbau abzubrechen. Mit der about:config-Option security.OCSP.require lässt sich das Verhalten abstellen.

Wie dem auch sei. DoH ist kein Allheilmittel. Hinzu kommt ja auch noch die ganze Problematik der zuverlässigen Authentifizierung der Gegenseite der DNS-Anfragen.

Herausforderungen der DNS-Authentifizierung

Ein weiterer Ansatz namens DNSSEC zielt darauf ab, die Kommunikation mit NS-Informationsdiensten des Internets durch den Austausch von kryptografischen Signaturen zu authentifizieren. Bei DNSSEC handelt es sich um eine DNS-Erweiterung (kurz für DNS security extensions), die beim Registrar implementiert werden muss. Domain-Registrars haben die Lösung – vor allem aus Kosten- aber auch aus Latenzgründen – größtenteils ignoriert; nur etwa ein von zehn Anbietern bietet sie standardmäßig an.

Da DNSSEC bei den Registrars nur in begrenztem Umfang Akzeptanz finden konnte, ist es auch mit vielen Endgeräten und Softwarelösungen nicht kompatibel. Zudem kann es zwar die Authentizität sicherstellen, jedoch nicht die Überwachung verhindern.

DNSCrypt, ein quelloffenes Protokoll zum Authentifizieren der Kommunikation zwischen einem DNS-Client und einem DNS-Resolver, soll Abhilfe schaffen. Doch bei allen vermeintlichen Vorteilen dieser Lösung hat sich bisher noch keine unabhängige Standardsorganisation dafür ausgesprochen. Angesichts mangelnder Transparenz hinsichtlich der wahren Lenker hinter DNSCrypt ist hier vorerst höchste Vorsicht geboten.

DoH mit TRR

Google Chrome und Mozilla Firefox lassen sich bereits mit DoH nutzen.

Mozilla hat sich für die DNS-Problematik eine ganzheitliche Lösung einfallen lassen. In der aktuellen Version von Firefox kombiniert Mozilla DoH mit einem Trusted Recursive Resolver (TRR) von Cloudflare zum Schutz vor Deanonymisierung der Benutzeranfragen. (Optional lassen sich in Firefox auch andere TRR einstellen.)

CloudFlare hat sich hierzu verpflichtet, alle identifizierbaren Daten nach 24 Stunden zu löschen. Damit die On-Path-Router Dritter die Kommunikation nicht so leicht auswerten können, vertraut Cloudflare auf Maßnahmen wie die QNAME-Minimierung und Geolocation-freundliche Anonymisierung der Anfragen.

Normalerweise sendet ja ein Resolver den gesamten Domainnamen sowohl an den Root-DNS-Server als auch an den TLD-Name-Server. Cloudflare beschränkt diese Anfragen auf den wirklich relevanten Ausschnitt des Domainnamens (Engl. QNAME minimization), ohne weitere Details preiszugeben.

Ein Resolver übermittelt normalerweise innerhalb einer jeden Anfrage einen Teil der IP-Adresse des Endbenutzers; Cloudflare wird stattdessen die IP des eigenen Resolvers übersenden. Dadurch kann der Dienst Geolocation gewährleisten, ohne auf die Anonymisierung verzichten zu müssen.

Die erste Anfrage nach einer URI trägt das größte Risiko der Deanonymisierung, da einige Pakete noch unverschlüsselt durch das Internet wandern; alle weiteren URIs vom betreffenden Server lassen sich dann aber in dem bereits geöffneten HTTP/2-Kanal vollständig verschlüsselt übertragen. Dadurch kann das CDN die Kommunikation vor Augen Unbefugter abschirmen.

Chrome-Nutzer können DoH in den experimentellen Einstellungen aktivieren (chrome://flags #dns-over-https).

Fazit

Solange das DNS-System ohne jegliche Verschlüsselung arbeitet, ist das Protokollieren von Benutzeraktivitäten durch Dritte ein Leichtes und das DNS-Spoofing stellt eine nicht zu unterschätzende Gefahr dar. Doch selbst beim Einsatz von DoH und HTTPS lässt sich Missbrauch nicht ganz ausschließen. Erst eine ganzheitliche Lösung wie die von Mozilla und Cloudflare kann dem MiTM-Sniffing einen Riegel vorschieben.

Das DNS-System ist reif für ein Datenschutzupgrade.

Über die Autoren: Anna Kobylinska und Filipe Pereira Martins arbeiten für McKinley Denali Inc. (USA).

(ID:46310437)