Privacy Handbuch
- Der Surfer gibt den Namen einer Webseite in der Adressleiste des Browsers ein (beispielsweise "https://www.privacy-handbuch.de/hanbuch_93.htm" oder einfach "privacy-handbuch.de").
- Daraufhin fragt der Browser einen DNS-Server, welche IP-Adresse der Webserver mit dem Namen "privacy-handbuch.de" hat. Üblicherweise wird der DNS-Server des Zugangsproviders gefragt, also z.B. Telekom, Vodafone, SNAFU...
- Der angefragte DNS-Server erkundigt sich daraufhin bei den Servern der Root-Zone nach dem DNS-Server, der für die Toplevel Domain ".de" zuständig ist. Dann fragt er dieses Server nach dem DNS-Server, der für die Domain "privacy-handbuch.de" zuständig ist. Abschließend fragt er diesen DNS-Server nach der IP-Adresse des Webservers "www.privacy-handbuch.de".
- Wenn ein passender Webserver gefunden wurde, dann wird die IP-Adresse an den Browser zurück gesendet (z.B. "81.169.145.78") oder NXDOMAIN, wenn man sich vertippt hat.
- Dann sendet der Browser seine Anfrage (Request) an die IP-Adresse des entsprechenden Servers und erhält als Antwort die gewünschte Webseite (Response).
DNS-Server werden nicht nur beim Surfen verwendet. Alle Dienste verwenden das DNS-System, um die IP-Adressen der Server zu ermitteln (E-Mail, Chat.... usw.)
Ein DNS-Server kennt also alle Internet Dienste und alle Webseiten, die man aufruft. Außerdem kann der DNS-Server durch Manipulation der Antworten entscheiden, welche Webseiten der Surfer sehen kann und welche Dienste man nutzen kann.
Möglichkeit zur Zensur
Die Möglichkeit der DNS-Manipulation zur Zensur des Internetzugangs sollte 2010 mit dem Zugangserschwerungsgesetz (ZugErschwG) genutzt werden. Alle Provider sollten eine geheime, vom BKA gelieferte Sperrliste von Domainnamen sperren und die Surfer beim Aufruf dieser Webseiten durch manipulierte DNS-Anworten auf eine Stopp-Seite umlenken.
Durch zumutbare technische Maßnahmen gemäß dem Stand der Technik sollten die Provider die Nutzung alternativer, unzensierter DNS-Server verhindern.
Neben dem damaligen Innenminister Schäuble haben sich besonders Hr. v. Guttenberg und die damalige Familienminsterin Ursula v.d.Leyen für das Gesetz engagiert. Frau v.d.Leyen wurde dafür mit dem Big Brother geehrt (was ihre weitere Karriere aber nicht negativ beeinflusst hat).
Aufgrund des Widerstandes der Zivilgesellschaft wurde das ZugErschwG wieder aufgehoben.
Aktuell wird die Sperrung von Webseiten im DNS in der EU, im Iran, Türkei, Ukraine. Süd Korea oder Vietnam nach diesem Muster umgesetzt. In Großbritannien gibt es konkrete Pläne für eine Zensurinfrastruktur auf Basis von DNS-Manipulationen. Für die Türkei wurde auch nachgewiesen, dass die Nutzung alternativer DNS Server blockiert wird und DNS Anfragen auf immer an kompromittierte Server umgeleitet werden. Nur verschlüsseltes DNS ermöglicht eine Umgehung.
DNSSEC Validierung
DNSSEC verbreitet sich langsam aber immer weiter als Sicherheitskomponente. Ein DNSSEC validierender DNS-Server kann die Echtheit der DNS Informationen anhand kryptografischer Signaturen verifizieren und damit Manipulationen erkennen und verwerfen, wenn der Domaininhaber die DNS-Daten signiert hat. Damit wird verhindert, dass Dritte die Daten manipulieren und den Surfer irgendwie umleiten (Zensur? Phishing?). Wie das konkret funktioniert, ist eine Menge Krypto-Voodoo. Nehmen wir mal an, dass es funktioniert.
DNSSEC ist außerdem die Basis, um via DANE/TLSA die SSL-Zertifikate zu verifizieren oder um mit OPENPGPKEY bzw. SMIMEA kryptografische Schlüssel sicher zu verteilen.
Im ersten Schritt ist es also ein Sicherheitsgewinn, wenn man einen DNSSEC validierenden DNS-Server verwendet. DNSSEC sichert aber nur die Auflösung der DNS-Anfragen auf dem DNS-Server, die "letzte Meile" zwischen DNS-Server und Nutzer bleibt ungeschützt.
Um diese Schwäche zu vermeiden, könnte man die DNSSEC Signaturen zusätzlich auf dem eigenen Rechner validieren:- Windows bietet out-of-the-box noch keine Möglichkeit, DNSSEC zu nutzen.
- Die meisten Linux Distributionen verwenden inzwischen systemd-resolve für die DNS Namensauflösung. Um DNSSEC zu aktivieren, ist eine Config Datei "dnssec.conf" im Verzeichnis "/etc/systemd/resolved.conf.d/" anzulegen mit folgendem Inhalt:
[Resolve]
DNSSEC=true
DNS Datenverkehr verschlüsseln
Das DNS-Protokoll enthält keine Authentifizierung die sicherstellt, dass man wirklich mit dem gewünschten DNS-Server verbunden ist. DNS-Anfragen können vom Provider auf eigene, zensierende Server umgeleitet werden, wie es zu Durchsetzung des des ZugErschwG im DFN Forschungsnetz geplant war und z.B. in der Türkei seit Jahren umgesetzt wird.
Um diese Schwächen zu vermeiden, kann man den Datenverkehr zum DNS-Server verschlüsseln. Das stellt kryptografisch sicher, dass man wirklich mit dem gewünschten Server verbunden ist (Authentifizierung) und verhindert eine Manipulation der Daten.
Die Verschlüsselung der DNS-Daten in Kombination mit ESNI (Encrypted Server Name Indication) in TLS 1.3 hat das Potential, die staatliche Infrastruktur zur Zensur des Internet in den meisten Länder auszutricksen. Aus diesem Grund versuchen einige Länder, diese technischen Entwicklungen zu blockieren:
- Die Great Firewall von China blockiert TLS 1.3, um anhand der unverschlüsselt übertragenen Servernamen im TLS Handshake unerwünschte Webseiten zu blockieren.
- In Großbritannien wurde auf Druck der Internet Service Betreiber ein Deal mit Mozilla geschlossen, dass DNS-over-HTTPS nicht wie geplant standardmäßig aktiviert wird. Man rechnet damit, dass die meisten Nutzer noch nie etwas davon gehört haben.
- In Russland wurde im September 2020 vom Ministerium für Digitale Entwicklung ein Gesetzentwurf zur Diskussion vorgelegt, der den Einsatz von verschlüsseltem DNS und ESNI im RuNet verbieten soll. Begründet wurde der Entwurf mit Wirkungslosigkeit von staatlichen Zensurmaßnahmen, wenn sich die Techniken verbreiten. IP-Adressen von DNS-Servern mit DNS-over-TLS oder DNS-over-HTTPS sollen blockiert werden.
DNScrypt ist die älteste Technik für verschlüsseltes DNS und basiert auf DNScurve von D.J. Bernstein. DNScrypt stellt mit kryptografischen Verfahren sicher, dass man wirklich den gewünschten DNS-Server verwendet und verschlüsselt die DNS Daten.
Um DNScrypt zu verwenden, muss man den dnscrypt-proxy installieren, den es für verschiedene Betriebssystem und Smartphones gibt. Nach der Installation sollte man die Konfiguration anpassen und die vertrauenswürdigen Server auswählen, standardmäßig verwendet dnscrypt-proxy auch Google und Cloudflare.
DNS-over-TLS (DoT) wurde von der IETF im Mai 2016 im RFC 7858 spezifiziert. Die meisten aktuellen Versionen der Linux DNS-Server beherrschen inzwischen DNS-over-TLS.
DNS-over-HTTPS (DoH) wurde 2016 von Google initiiert. Es dient in erster Linie der Umgehung von Zensur durch DNS Manipulation und kommt auch durch "Fascist Firewalls".
Verglichen mit DNS-over-TLS ist DoH aufgrund des HTTP Overhead weniger performant. Außerdem ergeben sich durch die Nutzung des HTTP-Protokoll Implikationen für die Privatsphäre. Ein Server könnte HTTP-Auth-Header, E-Tags sowie SSL-Session-ID für das Tracking instrumentalisieren oder HTTP-Header wie User-Agent, Accept-Language usw. für das Fingerprinting des Browsers nutzen. Simples Tracking via Cookies wäre aber zu einfach. Die Cookies soll ein DoH Client ignorieren, wie die IETF in RFC 8484 schreibt.
Wenn man die Wahl hat, sollte man DNS-over-TLS statt DNS-over-HTTPS bevorzugen.
Es gibt einige Clients, die DNS-over-HTTPS sprechen können:
- Der dnscrypt-proxy kann als lokaler DNS Resolver für Desktop PCs genutzt werden und kann auch DNS-over-HTTPS Server verwenden.
- Firefox und Thunderbird können die DNS Einstellungen des Systems umgehen und DNS-over-HTTPS Server als Trusted Recursive Resolver verwenden.
- iOS 14+ kann statt DNS-over-TLS auch DNS-over-HTTPS verwenden mit einem passenden Konfigurationsprofil (Anleitung).
DNS-over-QUIC (DoQ) soll die Vorteile von DoT und DoH verbinden. Statt TCP soll das QUIC Protokoll mit TLS 1.3 Verschlüsselung genutzt werden, dass auch bei HTTP/3 zum Einsatz kommen soll. DoQ soll nicht manipulierbar sein, die gleiche Privatsphäre wie DoT bieten, eine geringe Latenz wie unverschlüsseltes DNS über UDP und nicht blockierbar sein wie DoH.
Aktuell gibt es nur einen Draft der IETF und noch keine exakte Spezifikation.
DNS-over-HTTPS-over-Tor (DoHoT) kann man machen, wenn ein sinnvolles Gesamtsicherheitskonzept es erfordert. Man kann beliebigen HTTPS Traffic durch Tor tunneln, um zu verhindern, dass der/die DNS-Server die eigene IP-Adresse protokollieren kann.
Man erreicht das gleiche Ziel aber auch ohne Perfomance Einbußen, indem man einen vertrauenswürdigen DNS-Server mit No-Logging-Policy verwendet.
Abgesehen von einigen Szenarien mit höchsten Sicherheitsanforderungen, für die es schwer fällt, ein plausibles Beispiel zu konstruieren, ist DoHoT meist Overkill.
Oblivious DNS-over-HTTPS (ODoH) wurde von Cloudflare im Dez. 2020 initiert, weil es Vorbehalte in Europa gegen die Nutzung von Cloudflare als Defaut Trust-Recursive-Resolver (DoH) in Firefox gab. Derzeit läuft der Standardisierungsprozess.
Cloudflare ist nicht daran interessiert, welche Webseiten Lieschen Müller oder Pitschie Hufnagel aufrufen. Sie interessieren sich für eine globale Sicht, welche neuen Ideen gewinnen an Popularität, was ist der neue "heiße Shit" und was ist anderseits auf dem absteigenden Ast. Diese Informationen frühzeitig zu haben ist wertvoll, wie es Google mit seiner Suchmaschine demonstriert. Für Cloudfare besteht die einmalige Chance, als Default DNS-over-HTTPS Server für alle Firefox Nutzer millionenfach diese Daten zu sammeln, wenn sie die Bedenken der Privacy Community ausräumen können.
Aus technischer Sicht verwendet Oblivious DNS-over-HTTPS einfach Onion Routing mit nur einem Hop. Wenn die Betreiber der Hops nicht mit Cloudflare kooperieren, bleibt die Privatsphäre der Nutzer ähnlich gut geschützt, wie bei DoHoT mit wesentlich geringeren Einbußen bei der Performance.
Kann sein, dass ich mich täusche und ODoH ein neuer "heißer Trend" wird. Aber man muss nicht unbedingt Cloudflare DNS-Server nutzen. ;-)
Hinweis für Wi-Fi Hotspots
Die Anmeldung für viele Wi-Fi Hotspots (zum Beispiel in Hotels, U-Bahn usw.) arbeitet in der Regel mit einer Manipulation des DNS. Auf Laptops funktioniert die DNSSEC Validierung und Verschlüsselung mit DNScrypt oder DNS-over-TLS daher an Wi-Fi Hotspots nicht.
Wer mit seinem Laptop unterwegs einen Wi-Fi Hotspot nutzen möchte, muss den DNS-Server des Hotspot Betreibers verwenden und die lokale DNSSEC Validierung abschalten.
Bei Android Smartphones und iPhones besteht dieses Problem nicht. Bei einem Wechsel des Netzwerkes wird erst der Captive Portal Check mit dem zugewiesenen DNS-Server ausgeführt und danach auf DNS-over-TLS umgeschaltet (wenn es aktiviert ist).