Aktualisierungen als RSS-Feed oder
auf unserem Twitter Account @PrHdb

Privacy-Handbuch

DNS (Domain Name Service) ist das Telefonbuch des Internet. Kurze Erklärung:
  1. Der Surfer gibt den Namen einer Website in der Adressleiste des Browsers ein.(z.B. "https://www.privacy-handbuch.de")
  2. Daraufhin fragt der Browser bei einem DNS-Server nach der IP-Adresse des Servers, der die gewünschte Webseite liefern könnte. Üblicherweise wird der DNS-Server des Zugangsproviders gefragt, also z.B. Telekom, Vodafon...
  3. 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 für "www.privacy-handbuch.de".
  4. Wenn ein passender Webserver gefunden wurde, dann wird die IP-Adresse an den Browser zurück gesendet (z.B. "81.169.145.78") oder NIXDOMAIN, wenn der Surfer sich vertippt hat. Der Prozess dauert nur wenige Millisekunden.
  5. Dann sendet der Browser seine Anfrage an die IP-Adresse des entsprechenden Servers und erhält als Antwort die gewünschte Webseite.
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 2009 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 Innenminster Schäuble haben sich besonders Hr. v. Guttenberg und die damalige Familienministerin Ursula von der Leyen für das Gesetz engagiert. Frau v.d.Leyen wurde dafür mit dem Big Brother geehrt. Aufgrund des Widerstandes der Zivilgesellschaft wurde das ZugErschwG wieder aufgehoben.

Aktuell wird die Sperrung von Webseiten in Iran, Türkei, Ukraine oder Vietnam beispielsweise nach diesem Muster umgesetzt und in Großbritannien gibt es konkrete Pläne für eine Zensur­infrastruktur auf Basis von DNS-Manipulationen. Die vom Netzbetreiber Vodafon im Jan. 2018 umgesetzte Sperrung des Zugangs zum Streaming-Portal kinox.to wurde technisch ebenfalls mit einer DNS-Manipulation realisiert.

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-Zertifikaten zu verifizieren oder um mit OPENPGPKEY bzw. SMIMEA krpytografische 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 auch auf dem eigene Rechner validieren. Dafür muss man einen DNS-Cache-Server auf dem Computer installieren und entsprechend konfigurieren (z.B. dnsmasq für Linux). Damit entfällt die unsichere "letzte Meile" zwischen dem DNS-Server und Nutzer.

DNScrypt und DNS-over-TLS

Das DNS-Protokoll enthält keine Authentifizierung die sicherstellt, dass man wirklich mit dem gewünschten DNS-Server verbunden ist. DNS-Anfragen könnten vom Provider einfach auf eigene Server umgeleitet werden. In Vorbereitung auf die Umsetzung des ZugErschwG sollte im DFN Forschungsnetz beispielsweise der Datenverkehr auf dem Port 53 zu eigenen, potentiell kompromittierten DNS-Server umgeleitet werden, um die Zensur durchzusetzen.

Um diese Schwächen zu vermeiden, kann man den DNS-Datenverkehr zum Upstream DNS-Server zusätzlich verschlüsseln. Das stellt kryptografisch sicher, dass man wirklich mit dem gewünschten DNS-Server verbunden ist (Authentifizierung) und verhindert eine Manipulation der Daten durch Dritte. Diese Verschlüsselung ist aber kein Privacy-Feature, das irgendwelche Daten gegenüber dem Provider geheim hält.

Um den Datenverkehr kryptografisch abzusichern, gibt es folgende Möglichkeiten:
  1. DNScrypt stellt mit kryptografischen Verfahren sicher, dass man wirklich den gewünschten DNS-Server verwendet und verschlüsselt die Kommunikation zum DNS-Server. Es basiert auf DNScurve von D.J. Bernstein. Aktuell ist dnscrypt-proxy Version 2.0, die auch DNS-over-HTTPS beherrscht.
  2. DNS-over-TLS wurde von der IETF im Mai 2016 im RFC 7858 spezifiziert. Die DNS-Server Software ldns, Unbound und Knot beherrschen in den aktuellen Versionen DNS-over-TLS. Es gibt einige DNS-Server, die DNS-over-TLS sprechen können.
  3. DNS-over-HTTPS wurde im Sommer 2016 von Google initiiert. Es dient in erster Linie Umgehung von Zensur auf Basis von DNS Manipulationen und ist aufgrund des HTTP Overhead deutlich langsamer als normales DNS. Bisher gibt es mit Dingo nur einen DNS-over-HTTPS Resolver, der in einem frühen Entwicklungsstadium ist. 

    Firefox 60 (geplantes Release am 09. Mai) wird DNS-over-HTTPS direkt nutzen können, um Zensur durch DNS-Server der Provider zu umgehen. Die Konfiguration ist einfacher, als als einen DNS Daemon mit DNS-over-TLS Support zu installieren.

    Folgende Werte sind in Firefox 60 unter der Adresse "about:config" zu setzen:
    • DNS-over-HTTPS bevorzugt nutzen mit Fallback auf normalen DNS-Server: network.trr.mode = 2
    • Konfiguration für Cloudflare DNS-over-HTTPS Server: network.trr.uri = https://cloudflare-dns.com/dns-query
      network.trr.bootstrapAddress = 1.1.1.1
    • Konfiguration für Googles DNS-over-HTTPS Server: network.trr.uri = https://dns.google.com/resolve
      network.trr.bootstrapAddress = 216.58.214.110
    • Road-Warrior, die häufig an Wi-Fi Hotspots unterwegs sind, können nach dem Login im Portal des Hotspot automatisch auf HTTP-over-DNS umschalten: network.trr.wait-for-portal = true
      network.captive-portal-service.enabled = true
      (Die Wi-Fi Hotspot Portalerkennung ist in unserer Firefox Config deaktiviert.)

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. Validierung mittels DNSSEC und Verschlüsselung mit DNScrypt oder DNS-over-TLS funktionieren 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.
Lizenz: Public Domain