DNS-Verkehr absichern

[nik]

Hier eine kleine Übersicht über die verschiedenen Methoden, den DNS-Verkehr abzusichern.

Augenmerk beim Erstellen wurde hier auf Android gelegt. Das heißt, es kann auch andere Vor- und Nachteile geben, die hier aber nicht zu sehr zum Tragen kommen und deshalb zugunsten der Übersichtlichkeit ausgelassen wurden


DNSSEC:
steht für Domain Name System Security Extensions, Das Ziel ist, Integrität (Antwort ist korrekt) und Authentizität (Antwort kommt auch wirklich vom Absender) sicherzustellen. Um dies zu erreichen, werden die Einträge mit einem geheimen Schlüssel signiert. Mit dem dazugehörigen öffentlichen Schlüssel kann überprüft werden, ob der übermittelte Eintrag korrekt ist.
Der Transportweg wird nicht verschlüsselt.
DNSSEC wird dazu verwendet, das ganze "DNS-Netz" abzusichern und beschränkt sich nicht nur auf die Client-Kommunikation.

Alle folgenden Protokolle können in Kombination mit DNSSEC verwendet werden.

DNScrypt:
Das älteste Protokoll der Aufzählung hier ist ein reines Community-Projekt. Der Vorteil, dass kein großes Unternehmen dahinter steht, ist gleichzeitig ein Nachteil: Es wurde bisher nicht standardisiert. Das führt unter anderem dazu, dass es trotz der langen Zeit noch ein Nieschendasein fristet.

Funktionsweise:
Client und Server tauschen die Schlüssel aus und verschlüsseln den Verkehr mit den selbst erstellten Schlüsseln.

Vorteile:

• Wird bereits lange genutzt und ist entsprechend erprobt

• kleine Angriffsfläche

• wurde explizit dafür entwickelt

Nachteile:

• ist nicht weit verbreitet

Apps:
DNScrypt Poxy, DNS Manager (mit DNSCrypt)

DNS over HTTPS:
Die Technik, die schon beim Web-Protokoll zum verschlüsselten Abruf von Internetseiten genutzt wird, wird nun für DNS verwendet.

Funktionsweise:
Es wird eine verschlüsselte Verbindung zum Server aufgebaut, worüber die DNS-Daten im http-Format übertragen werden.

Vorteile:

• weite Verbreitung

Nachteil:

• die ganzen Nachteile, die man bei https/tls hat wie z.B. Zertifikatsverwaltung und optionale, unsichere Übertragungsstandards, werden hier übernommen

Apps:
Intra, DNScrypt Proxy

DNS over TLS:
Noch relativ neuer Standard

Funktionsweise:
Es wird ein TLS-Tunnel zum Server aufgebaut, worüber die DNS-Daten ausgetauscht werden.

Vorteile:

• Wird ab Android Pie nativ unterstützt

Nachteile:

• TLS wurde ursprünglich für einen anderen Einsatzzweck entwickelt, was das Risiko erhöht, dass es hier zu Implementierungsfehlern kommt.

• die ganzen Nachteile, die man bei https/tls hat wie z.B. Zertifikatsverwaltung, optionale unsichere Übertragungsstandards, werden hier mitübernommen

Apps:
DNSCrypt Prox, stubby for Android


Fazit:
Jedes Protokoll hat seine Vor- und Nachteile. Am Ende wird aber wohl die allgemeine Verbreitung darüber entscheiden, was sich letztendlich durchsetzen wird.
So wird vermutlich die native Unterstützung von DNS over TLS in Android Pie sehr zur Verbreitung beitragen, da die uneingeschränkte Nutzung anderer Protokolle unter Android nur über Umwege möglich ist.

Beim Thema Datensicherheit sollte man aber nicht das Gesamtbild aus den Augen verlieren. So bringt die sicherste DNS-Verschlüsselung nichts, wenn weiterhin die besuchten Seiten dank SNI in Klartext übertragen werden.

 

[rudolf]

Und warum interressiert denn was da mit dem DNS passiert?

Jedesmal wenn ich eine Webseite aufrufe, schickt mein Browser die Adresse an den DNS Server, und der liefert dem Browser dann die IP der Adresse, die ich anschauen will. Ein praktischer Ansatzpunkt für die, die mich überwachen wollen. Aber auch gut um zu Zensieren oder zu betrügen.

Zensieren geht einfach so, dass der DNS Server bei den Adressen die ich nicht sehen soll ein "den gibt es nicht" bekomme, oder gar auf einer Seite lande die protokolliert was ich gerade ansehen will.

Betrügen geht so dass ich erstmal auf einer Kopie der echten Seite lande. Die sieht gleich aus, und ich kanm meine Logindaten, Pins und Tans eintippen. Die werden dann gespeichert, und ich werden dann zur echtem Seite geschickt.

Wenn ich per Mobilfunk oder DSL zuhause verbunden bin,
dann nehme ich meist den DNS meines Providers. Der bekommt dann jedesmal die Seite die ich will und meine IP, und hat ein ganz bequemes Protokoll aller Seiten die ich besuche. Meine Personalien hat er ja auch. Dem kann ich begegnen, indem ich einen anderen DNS nutze. Dann muss der Provider den Datemstrom komplett überwachen um meien DNS Anfragen mitzuschneiden. Das ist wesentlich mehr Aufwand, und auch kein "technisches Protokoll" mehr, sondern echtes Überwachen. Aber immer noch recht bequem weil der muss ja nur die Pakete mitschneiden die an die Adresse des DNS gehen. Dem kann ich wiederum begegnen, indem ich einen verschlüsselten DNS nehme, also mein Provider diese nicht mehr mitlesen kann. Nun könnte ich mich sicher fühlen, weil meine besuchten Web seiten sind ja auch verschlüsselt. Leider doch nicht, denn wie @nik schon schreibt gibt es dieses SNI. Das bewirkt, dass trotz https der Name des Servers wo ich mir was anschaue im Klartext im Datenstrom steht. Dafür müsste nun mein Provider den kompletten Datemstrom mitschneiden, was dann richtig Aufwand ist. Aber trotz verschlüsselter DNS und https kann im gewissen masse gelausch werden.
Der Betrug ist kaum möglich wenn ich Mobilfunk oder mein DSL nehme.

Wenn ich ein fremdes Wlan nutze
dann kann der Besitzer des Routers oder Hotspots an dem ich angemeldet bin vorgeben welchen DNS ich nehme. Das kann auch einer sein der auf seinem Computer läuft und sich persönlich um mein Banking und meine Passwörter kümmert. Betrug ist sehr einfach. Dem Betrug kannmman entgegnen indem man eigene DNS Server umd auch DNSSEC nutzt.
Mitschneiden geht auch, nur hat der im Gegensatz zu meinem Provider von DSL/Mobilfunk nicht auch gleich meinen Namen umd meine Adresse. Ansonsten gilt auch hier das gleiche wie oben schon geschrieben. Wegen der hohen Risiken nutzen einige fremde Wlanms nur mit VPN, so dass der Besitzer des Wlans nichts mehr machen kann. Wenn man aber z.B. ein gerootetes Gerät mit Afwall nutzt, nur Firefox erlaubt, und denn auch noch auf DoH umstellt, dann ist man auch ohme VPN sicher.

Ich hoffe ich konnte klar machen warum Leute sicheres DNS wollen, es "dank" SNI aber nicht ganz sicher wird.
Server Name Indication – Wikipedia

 

[MrT69]

Also ich würde gern mal wissen was SNI und DNS zu tun haben. SNI (Server Name Indication) ist ein TLS Protokoll Feature. Das hat Null und nix mit DNS zu tun. DNSSEC hat leider auch mehr Fehler und Probleme das es eigentlich besser ist das nicht einzusetzen.

Siehe hier:
DNSSEC Downtime: List of Outages & Validation Failures

Bei der Zensur geb ich dir vollkommen recht, das ist das Problem warum sicheres DNS gewollt ist. Was allerdings leider auch falsch ist:

Dafür müsste nun mein Provider den kompletten Datemstrom mitschneiden, was dann richtig Aufwand ist.

Das stimmt leider nicht. Jede bessere Firewall liest den HTTPS Traffic problemlos aus und kann das filtern.

 

[nik]

Also ich würde gern mal wissen was SNI und DNS zu tun haben.

Auf dem Papier nichts. Aber wenn du nun deinen DNS-Traffic verschlüsselt und immer https nutzt, um dem Provider gegenüber zu verschleiern, welche Webseiten du nun besuchst, kann dir da eben SNI nen Strich durch die Rechnung machen.

 

[MrT69]

Ok. Von dem her richtig. Das sehe ich mit keweon und DoH. Es gibt Zensur Provider die es machen, gibt allerdings auch welche die es nicht machen.

Gerade in Asien hab ich mit den Usern das Problem. Ein grosser Teil kommt trotz SNI um die Zensur. Aber gerade Indonesien und Malaisia da geht gar nix. Malaisia ist z.B. die Hardware Entwicklung von Cisco, nur mal erwähnt warum es kaum Aufwand IST. Von China rede ich gar ned obwohl immer noch einer meiner DNS Server in Singapur steht und erreichbar ist. Na ja, auch nur ein normaler Port 53 DNS.

Aber inzwischen gibt es die eine Erweiterung von SNI, nämlich ESNI. Das bedeutet Encrypted SNI.

Im TLS steht ja der Servername unverschlüsselt bis jetzt. Reicht eigentlich auch aus. Durch ESNI wird der jetzt auch verschlüsselt so das die Zensur keine Chance hat z.B. reddit.com zu filtern. Als Provider muss ich ja nur wissen wohin der Traffic geht und kann es über SNI lesen. Kann man recht einfach z.B. mit Haproxy nachbauen. Is voll easy.

Somit kommt der User nicht mehr drauf. Wenn jetzt ESNI kommt bin ich gespannt wie China drauf reagiert. Zumindest kam zum Thema ESNI kein Veto.

Deswegen hab ich persönlich noch ein Problem damit, denn wenn die chinesische Zensur kein Problem damit hat scheint das noch nicht ganz sicher zu sein.

Mal abwarten. Ich glaub es zwar nicht, aber wir werden sehen.