Original-URL des Artikels: https://www.golem.de/news/imho-dnssec-ist-gescheitert-1506-114940.html    Veröffentlicht: 30.06.2015 10:24    Kurz-URL: https://glm.io/114940

Protokoll

DNSSEC ist gescheitert

PR für ein totes Protokoll: Am heutigen 30. Juni wird der DNSSEC-Day begangen. Dabei ist das Protokoll in seiner heutigen Form nahezu nutzlos - und wird es wohl auch bleiben.

Das DNSSEC-Protokoll ist ein inzwischen über 20 Jahre alter Ansatz, um die Sicherheit im Domain Name System (DNS) zu verbessern. Doch durchsetzen konnte sich das Protokoll nie, bis heute ist ein praktischer Nutzen nahezu nicht vorhanden. Dafür gibt es eine Reihe von Gründen - und realistischerweise ist kaum damit zu rechnen, dass sich das irgendwann ändert. DNSSEC ist ein veraltetes, gescheitertes Konzept, das man am besten beerdigen sollte.

Doch ungeachtet seiner Erfolglosigkeit hat DNSSEC einige Fans. Praktisch jedes Mal, wenn auf Golem.de oder anderswo ein Artikel über die Probleme mit TLS-Zertifikaten und Zertifizierungsstellen berichtet wird, fordern Kommentatoren, dass man endlich das auf DNSSEC aufbauende DANE einsetzen müsse, um Zertifikate abzusichern. Das BSI, die für .de-Domains zuständige Denic und der Heise-Verlag haben für den heutigen 30. Juni einen DNSSEC-Day ausgerufen, nach ihren Angaben "eine Aktion zur Förderung der Internetsicherheit".

DNSSEC signiert, aber verschlüsselt nicht

Um nachzuvollziehen, warum DNSSEC wenig zur Internetsicherheit beiträgt, sollte man zunächst verstehen, was das Protokoll tut. Es ist ein hierarchisches System, das DNS-Einträge signiert. Ein von der Icann und der Firma Verisign verwalteter Root-Schlüssel signiert die jeweiligen Keys der Verwalter von Top-Level-Domains. Diese wiederum signieren die Schlüssel der darunterliegenden Domains. Dazu kommt noch eine Unterscheidung in Key Signing Keys (KSKs) und Zone Signing Keys (ZSKs), die Letzteren werden häufiger gewechselt.

DNSSEC authentifiziert nur die DNS-Abfragen selbst, die anschließende Verbindung jedoch nicht. Hierfür müssen weiterhin Schutzsysteme wie TLS oder SSH zum Einsatz kommen. Konkret bedeutet das beispielsweise, dass man bei funktionierendem DNSSEC sicher sein kann, dass die Domain denic.de zur IP-Adresse 81.91.170.12 gehört. Das Protokoll kann aber nicht gewährleisten, dass die Verbindungen zur IP 81.91.170.12 auch wirklich von dort kommen.

Ebenfalls keinen Beitrag leistet das Protokoll zur Geheimhaltung des Surfvorgangs. Denn DNSSEC verschlüsselt nicht, es handelt sich um ein reines Signatursystem, ein Angreifer kann nach wie vor alle DNS-Anfragen und Antworten mitlesen. Der Grund für die fehlende Verschlüsselung dürfte im Alter von DNSSEC liegen. In den späten Neunzigern, als DNSSEC standardisiert wurde, war Verschlüsselung noch vergleichsweise problematisch und rechenaufwendig. Der standardisierte Verschlüsselungsalgorithmus DES wurde gerade gebrochen, die verbreitete Alternative Triple-DES galt zwar als sicher, war aber extrem langsam. Der AES-Algorithmus war noch nicht erfunden, und von Verschlüsselungsinstruktionen auf Standard-CPUs, die heute üblich sind, wagte vermutlich noch niemand zu träumen. Heute würde vermutlich niemand mehr auf die Idee kommen, ein "sicheres" Protokoll ohne Verschlüsselung zu entwickeln.

DNSSEC: Viele Parteien müssen mitspielen

Wer DNSSEC ganz praktisch einsetzen möchte, muss einige Hürden überwinden. Zunächst einmal funktioniert DNSSEC nur dann, wenn die entsprechende Top-Level-Domain das überhaupt unterstützt. Inzwischen bieten die meisten Top-Level-Domain-Verwalter DNSSEC an, aber längst nicht alle. Wer sich beispielsweise für eine der neueren Domains wie .tel, .jobs oder .mobi entschieden hat, hat Pech gehabt. Auch eine ganze Reihe von Länderdomains unterstützt das Protokoll nicht. DNSSEC ist somit eines der wenigen Features im Netz, bei denen es von der Top-Level-Domain abhängt, ob man es überhaupt nutzen kann.

Doch selbst wenn man eine Top-Level-Domain hat, die DNSSEC theoretisch unterstützt: Einfach anschalten kann man es trotzdem nicht. Selbst wer seinen eigenen DNS-Server betreibt, benötigt die Unterstützung des jeweiligen Domainhändlers. Der muss mit den jeweiligen Top-Level-Domain-Betreibern ein Verfahren dafür vereinbaren, wie die entsprechenden Keys übermittelt werden.

Wer DNSSEC nutzen möchte, sieht sich also im ungünstigsten Fall damit konfrontiert, dass er zuerst den Domainnamen und anschließend auch den Domainprovider wechseln muss. Das dürfte einer der Hauptgründe dafür sein, dass das Protokoll sich nie durchsetzen konnte. Es ist schlicht zu komplex und involviert zu viele unterschiedliche Parteien. Alleine, um auf Serverseite DNSSEC umzusetzen, müssen der Verwalter der Top-Level-Domain, der Domainhändler und der DNS-Serverbetreiber das Protokoll unterstützen.

Die Komplexität von DNSSEC führt immer wieder zu Schwierigkeiten. Die Liste der Fehlschläge bei DNSSEC ist lang. Selbst die Betreiber von Top-Level-Domains haben immer wieder Schwierigkeiten, es korrekt zu betreiben.

DNSSEC auf Clients praktisch nicht vorhanden

Doch selbst wenn alle Hürden überwunden und die Records einer Domain via DNSSEC signiert werden: Viel nützt das nicht. Denn Signaturen nützen logischerweise nur dann etwas, wenn sie auch geprüft werden.

Das Konzept von DNSSEC sieht vor, dass die DNS-Signaturen im Resolver geprüft werden. Im Normalfall betreiben gewöhnliche Clientsysteme, also Desktop-PCs, Smartphones und Ähnliche, keine eigenen Resolver. Der Resolver steht vielmehr beim jeweils zuständigen Internetzugangsprovider. Somit kann DNSSEC zwar die Verbindung vom für eine Domain zuständigen autoritativen Name-Server zum Resolver des Providers absichern. Aber der Nutzer kann nach wie vor nicht darauf vertrauen, dass die DNS-Antworten korrekt sind. Insbesondere bei heute üblichen Nutzungsszenarien - Stichwort öffentlich zugängliche WLAN-Netze - ist es kaum sinnvoll, auf den DNS-Resolver des Providers zu vertrauen.

Um eine richtige Absicherung der DNS-Antworten zu gewährleisten, müsste der Anwender selbst einen DNS-Resolver betreiben. Das könnte entweder das Betriebssystem oder eine Anwendung wie beispielsweise der Browser tun. Allerdings: Kein relevantes Betriebssystem und kein Browser machen das bislang. Es gibt auch keine ernsthaften Bemühungen, hieran etwas zu ändern.

Resolver auf dem Client kaum realistisch

Ob ein solcher Resolver auf dem Client überhaupt umsetzbar wäre, ist mehr als fraglich. Der Google-Entwickler Adam Langley hat vor einiger Zeit die möglichen Probleme in einem Blogbeitrag ausgeführt. Bei einem Experiment mit dem Chrome-Browser stellte sich heraus, dass auf fünf Prozent der Clients bestimmte DNS-Anfragen nach TXT-Records nicht ankamen. Viele Netzwerke filtern demnach DNS-Pakete mit ungewöhnlichen Anfragen. DNSSEC dürfte damit noch mehr Probleme haben.

Eine Umsetzung von DNSSEC in Clients hätte also zwei Möglichkeiten: Entweder man akzeptiert, dass die Internetverbindung in vielen Netzen nicht funktioniert, oder man baut in diesem Fall einen Fallback ein. Ersteres dürfte kaum ein Anwender für akzeptabel halten, Letzteres wiederum ist völlig sinnlos, denn wenn es einen Fallback gibt, kann auch ein Angreifer einfach entsprechende Pakete ausfiltern und somit den DNSSEC-Schutz aushebeln.

Abgesehen von wenigen Anwendern, die spezielle Browser-Plugins nutzen oder eigene DNS-Resolver betreiben, ist aus heutiger Sicht DNSSEC auf Clients praktisch nicht vorhanden. Das muss man immer bedenken, wenn man Zahlen über das Protokoll hört, die beispielsweise angeben, dass eine bestimmte Zahl von Domains bereits darüber abgesichert ist. Diese Zahlen sind rein theoretisch. Für ein funktionierendes Deployment muss der gesamte Stack - von der DNS-Root-Zone bis zum Client - implementiert werden. Das reale Deployment von DNSSEC dürfte sich maximal im Promillebereich bewegen.

Luftschloss DANE

Eine grundsätzliche Frage, die sich bei DNSSEC stellt: Wozu soll das System überhaupt dienen? Es würde - wenn es funktioniert - teilweise dazu beitragen zu gewährleisten, dass man nicht mit der falschen IP-Adresse verbunden ist. Verkürzt könnte man sagen: DNSSEC soll - teilweise - sicherstellen, dass man mit der richtigen Gegenstelle verbunden ist. Doch hierfür gibt es bereits ein System: TLS und die dazugehörigen X.509-Zertifikate.

TLS-Zertifikate sind allerdings über die Jahre in Verruf geraten - und das aus gutem Grund. Das System krankt daran, dass es eine unüberschaubar große Zahl von Zertifizierungsstellen gibt. Klassischerweise war es so, dass jede Zertifizierungsstelle für jede Domain ein Zertifikat ausstellen konnte. Eine einzige kompromittierte Zertifizierungsstelle reicht, um Schaden anzurichten und Zertifikate zu fälschen. Das führte in der Vergangenheit immer wieder zu Problemen. Falsch ausgestellte Zertifikate von Comodo, Diginotar, ANSSI, CNNIC und vielen anderen stehen für die Probleme des Zertifikatssystems.

DANE ist keine brauchbare Alternative zu Zertifizierungsstellen

Das DANE-Protokoll (DNS-based Authentication of Name Entities) wird gerne als Lösung für die Probleme mit TLS-Zertifikaten beworben. Die Idee von DANE: Wenn DNS-Antworten bereits abgesichert sind, könnte man darüber ja weitere Informationen verteilen, beispielsweise die Fingerprints von Zertifikaten. Damit könnte man die Prüfung von TLS-Zertifikaten zusätzlich absichern.

Das wäre möglicherweise eine sinnvolle Idee, wenn DNSSEC funktionieren würde. Doch wie bereits erläutert, ist funktionierendes DNSSEC - insbesondere auf gängigen Endnutzerclients - nahezu nicht verbreitet. Das gesamte DANE-Konzept scheitert daran, dass hier versucht wird, auf etwas aufzubauen, was in der Praxis überhaupt nicht vorhanden ist.

Key Pinning und Certificate Transparency

DANE ist jedoch nicht der einzige Versuch, die Sicherheit von TLS-Zertifikaten zu verbessern. Bereits funktionstüchtig ist das von Google entwickelte HTTP Public Key Pinning (HPKP), ein HTTP-Header, mit dem eine Webseite dem Browser signalisieren kann, dass er das Seitenzertifikat und ein Ersatzzertifikat speichern und künftig Verbindungen mit anderen Zertifikaten ablehnen soll.

HPKP verhindert bereits sehr viele Probleme mit TLS-Zertifikaten und im Gegensatz zu DANE und DNSSEC ist das Deployment relativ simpel. In Firefox und Chrome/Chromium ist die Unterstützung bereits vorhanden, serverseitig benötigt man keinerlei Änderungen an der Software, lediglich ein entsprechender HTTP-Header muss gesendet werden.

Noch nicht ganz so weit, aber sehr vielversprechend ist ein weiteres Konzept zur Stärkung des Zertifikatssystems: das Protokoll Certificate Transparency, ebenfalls von Google entwickelt. Die Idee dabei sind öffentlich verifizierbare Logs, in die alle Zertifikate eingetragen werden sollen. Taucht ein Zertifikat auf, das nicht in einem Log steht, kann der Browser Alarm schlagen.

Die Kritik am TLS-Zertifikatssystem und den Zertifizierungsstellen ist in vieler Hinsicht völlig berechtigt. Doch man sollte dabei nicht vergessen, dass in den vergangenen Jahren einiges dafür getan wurde, die Sicherheit dieses Systems zu verbessern. DANE hat bislang allerdings hierzu nicht viel beigetragen.

Einige kleinere E-Mail-Anbieter in Deutschland nutzen DANE, um die Server-zu-Server-Verbindungen von SMTP abzusichern. Das ist tatsächlich eine der wenigen Nischenanwendungen, wo DNSSEC funktionieren könnte, denn die oben erwähnten Probleme mit dem Deployment auf Clients treffen hier nicht zu. Große Verbreitung hat dies jedoch bisher nicht gefunden und angesichts der unsicheren Zukunft von DNSSEC stellt sich die Frage, ob man hier besser auf Alternativen setzen sollte.

Schwache Krypto und Reflection-Angriffe

DNSSEC hat einige weitere Probleme, für die es zwar theoretisch Lösungen gibt, die aber in der Praxis oft nicht zum Einsatz kommen. Wie oben bereits erwähnt, nutzt DNSSEC sogenannte Key Signing Keys und Zone Signing Keys. Für Letztere kommt oft RSA mit 1.024-Bit-Schlüsseln zum Einsatz.

RSA mit 1.024 Bit gilt aus heutiger Sicht als nicht mehr sicher. Zwar ist es noch niemandem gelungen, öffentlich das Knacken eines 1.024-Bit-Schlüssels zu zeigen, doch es ist davon auszugehen, dass finanzstarke Angreifer dazu in der Lage wären. Begründet wird die Nutzung von solch kurzen Schlüsseln in DNSSEC damit, dass diese Schlüssel nur für kurze Zeiträume genutzt werden sollen und anschließend rotiert werden. Ob man diesem Argument folgen mag, sei dahingestellt, tatsächlich notwendig ist der Einsatz schwacher Kryptographie nicht.

DNSSEC unterstützt bereits Signaturen auf Basis elliptischer Kurven mit dem ECDSA-Verfahren. ECDSA verwendet deutlich kleinere Schlüssel und ist schneller als RSA. Zwar ist das Verfahren aus Sicherheitssicht nicht optimal, besser als RSA mit 1.024 Bit ist es jedoch allemal.

Große DNS-Antworten ermöglichen Reflection-Angriffe

Da DNSSEC-Antworten kryptographische Schlüssel und Signaturen enthalten, sind sie relativ groß. DNS ist ein auf UDP aufbauendes Protokoll, damit ergibt sich hier ein Problem: DNSSEC kann für sogenannte Reflection- oder Amplification-Angriffe missbraucht werden.

UDP ist ein verbindungsloses Protokoll, das heißt, dass ein Server keine Möglichkeit hat zu gewährleisten, dass Anfragen auch tatsächlich von der richtigen IP-Adresse kommen. Ein Angreifer kann das ausnutzen, indem er eine Anfrage mit gefälschter IP-Adresse schickt, die eine deutlich größere Antwort auslöst. Der Traffic landet dann bei der entsprechenden falschen IP-Adresse. Reflection-Angriffe sind im DNS-Protokoll grundsätzlich ein Problem, doch durch DNSSEC wird das Ganze deutlich schlimmer.

Das Reflection-Problem von DNSSEC ist nicht unlösbar. Auch hier würde der Einsatz von Signaturverfahren auf Basis elliptischer Kurven mit ECDSA helfen, um die DNS-Antworten klein zu halten. Weiterhin wäre es möglich, besonders große DNS-Antworten grundsätzlich nicht über UDP auszuliefern, sondern das sogenannte TC-Flag zu senden, welches den Client anweist, die Anfrage erneut über TCP zu stellen.

Völlig unabhängig von DNSSEC gibt es einige Mittel, um Reflection-Angriffe zu erschweren, dazu gehören etwa die Filterung von ungültigen UDP-Absenderadressen nach BCP38 und die Response-Rate-Limiting-Option von DNS-Servern. Diese Technologien sollten generell genutzt werden, da DNS-Server auch ohne DNSSEC in begrenztem Umfang für Reflection-Angriffe genutzt werden können.

Schwache Kryptographie und Reflection-Angriffe sind keine grundsätzlichen Probleme von DNSSEC, sie wären lösbar. Doch die Realität sieht anders aus: Viele DNSSEC-Server lassen sich extrem gut für Reflection-Angriffe nutzen. Und das DNSSEC-System ist voll von kryptographisch unsicheren kurzen RSA-Schlüsseln.

DNSSEC wird kaum von großen Internetkonzernen unterstützt

Bei den großen Webseiten im Netz ist das Interesse an DNSSEC gering. Man muss schon eine Weile suchen, um überhaupt eine relevante Webseite zu finden, deren Domain über DNSSEC abgesichert ist. Google, Facebook, Yahoo und viele andere scheinen kein Interesse an DNSSEC zu haben. Alex Stamos, bis vor kurzem Sicherheitschef bei Yahoo und jetzt bei Facebook, hat im vergangenen Jahr in einem Vortrag DNSSEC für tot erklärt. Der bei Google angestellte Chrome-Entwickler Ryan Sleevi hält DNSSEC aus vielen Gründen für nicht umsetzbar. Auch namhafte Kryptographie-Experten wie Dan Bernstein, Moxie Marlinspike oder Thomas Ptacek haben sich in der Vergangenheit gegen DNSSEC ausgesprochen.

Nicht verschwiegen werden soll, dass es ein paar vereinzelte andere Stimmen gibt. Cloudflare arbeitet an der Umsetzung von DNSSEC. Die laut Alexa-Statistik zurzeit beliebteste Webseite mit DNSSEC ist die von Paypal. Bei der Mutterfirma Ebay kommt aber ebenfalls kein DNSSEC zum Einsatz.

DNSSEC aus der Zeit gefallen

DNSSEC ist ein aus der Zeit gefallenes Relikt. Das funktionierende Deployment des Protokolls ist 20 Jahre später bei nahezu null. Statt weiterhin ein totes Pferd zu reiten, sollte man sich eingestehen, dass DNSSEC gescheitert ist. Die Alternative sind TLS-Verbindungen und eine bessere Absicherung des Zertifikatssystems. HTTPS mit HSTS, HPKP und hoffentlich bald Certificate Transparency tragen wirklich zu mehr Sicherheit im Netz bei.

Ein besser abgesichertes DNS-Protkoll könnte sich trotz allem mittelfristig als sinnvoll erweisen. Ein solches Protokoll müsste allerdings völlig anders als DNSSEC aussehen. Insbesondere wäre es aus Datenschutzgründen wünschenswert, DNS-Anfragen und Antworten zu verschlüsseln. Einen Entwurf, um DNS-Verbindungen mittels TLS zu verschlüsseln und abzusichern, gibt es bereits. Ob der Overhead von TLS hierfür sinnvoll ist oder ob ein anderer Weg wie beispielsweise das von Dan Bernstein entwickelte DNSCurve sinnvoller ist, wäre zu diskutieren.

IMHO ist der Kommentar von Golem.de. IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach)  (hab)


Verwandte Artikel:
DNS über TLS: Google bringt sichere DNS-Abfragen in Developer-Android   
(26.10.2017, https://glm.io/130827 )
BSI-Richtlinie: Der streng geheime Streit über die Routersicherheit   
(25.01.2018, https://glm.io/132363 )
Kollisionsangriff: Hashfunktion SHA-1 gebrochen   
(23.02.2017, https://glm.io/126355 )
Anton Zeilinger: Wissenschaftler kommunizieren quantenverschlüsselt   
(30.09.2017, https://glm.io/130370 )
Webseiten: Googles Domain-Registrierung für alle US-Kunden   
(14.01.2015, https://glm.io/111690 )

© 1997–2019 Golem.de, https://www.golem.de/