Aktualisierungen gibt es im Changelog, als RSS-Feed
oder im [matrix] Raum #prhdb-changes:nitro.chat

Privacy-Handbuch

DNS (Domain Name Service) ist das Telefonbuch des Internet. Eine kurze Erklärung:
  1. Der Surfer gibt den Namen einer Webseite in der Adress­leiste des Browsers ein (beispiels­weise "https://www.privacy-handbuch.de/hanbuch_93.htm" oder einfach "privacy-handbuch.de").
  2. 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 Zugangs­providers gefragt, also z.B. Telekom, Vodafone, SNAFU...
  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 "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 NXDOMAIN, wenn man sich vertippt hat.
  5. 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 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 Zivil­gesellschaft wurde das ZugErschwG wieder aufgehoben.

Aktuell wird die Sperrung von Webseiten in Iran, Türkei, Ukraine. Süd Korea oder Vietnam beispw. nach diesem Muster umgesetzt und in Großbritannien gibt es konkrete Pläne für eine Zensur­infrastruktur 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 der Zensur.

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 Domain­inhaber 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:

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:

Um den DNS Datenverkehr kryptografisch abzusichern, gibt es folgende Möglichkeiten:
  1. 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.

  2. 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.

    • Android Smartphones können DNS-over-TLS nutzen. Die Option heißt "Privates DNS" und verbirgt sich in den erweiterten Einstellungen für "Netzwerk & Internet". (Anleitung)
    • iPhones können seit iOS Version 14 DNS-over-TLS nutzen. (Anleitung)
    • Fritz!Boxen mit Fritz!OS 7.20+ können DNS-over-TLS verwenden. Allerdings rät AVM wegen von Fehlern davon ab, diese Option in den Fritz!OS 7.20 und 7.21 zu nutzen. 
  3. 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 "Facist 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 Privat­sphä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 Finger­printing 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 Konfigurations­profil (Anleitung). 
  4. 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. 

  5. DNS-over-HTTPS-over-Tor (DoHoT) kann man machen, wenn ein sinnvolles Gesamt­sicherheits­konzept 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 vertrauens­würdigen DNS-Server mit No-Logging-Policy verwendet.

    Abgesehen von einigen Szenarien mit höchsten Sicherheits­anforderungen, für die es schwer fällt, ein plausibles Beispiel zu konstruieren, ist DoHoT meist Overkill.

  6. 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 Privat­sphä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 aus­geführt und danach auf DNS-over-TLS umgeschaltet (wenn es aktiviert ist).