Abo
  • Services:
Anzeige
DNSSEC ist aus heutiger Sicht total veraltet und bringt wenig Vorteile.
DNSSEC ist aus heutiger Sicht total veraltet und bringt wenig Vorteile. (Bild: Oxfordian Kissuth/Wikimedia Commons/CC by-sa 3.0D)

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.

Anzeige

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.

 Protokoll: DNSSEC ist gescheitertSchwache Krypto und Reflection-Angriffe 

eye home zur Startseite
Bitschnipser 02. Jul 2015

Leg doch mal Zahlen vor. Relevante Punkte: 1) Technischer Mehraufwand im Vergleich zur...

bremse 30. Jun 2015

Weckruf? Indem man Dinge für tot erklärt, trägt man nicht gerade zur Verbreitung bei...

P1r4nh4 30. Jun 2015

Also ich glaube Otto-Normalsurferwird das vermutlich kaum machen. Aber ich habe mir...

M.P. 30. Jun 2015

Hmm, ähnlich wurde wahrscheinlich Noah beim Bau der Arche auch angesprochen ;-) oder...

Wechselgänger 30. Jun 2015

Schön, daß du meinen nächsten Satz nicht mit zitiert hast. Der geht genau darauf ein...



Anzeige

Stellenmarkt
  1. Harvey Nash GmbH, Frankfurt am Main oder Berlin
  2. Robert Bosch GmbH, Leonberg
  3. Bundes-Gesellschaft für Endlagerung mbH (BGE), Salzgitter, später Peine
  4. Dr. August Oetker KG, Bielefeld


Anzeige
Spiele-Angebote
  1. 5,99€
  2. 49,79€
  3. 59,99€ mit Vorbesteller-Preisgarantie

Folgen Sie uns
       


  1. Alphabet

    Google Gewinn geht wegen EU-Strafe zurück

  2. Microsoft

    Nächste Hololens nutzt Deep-Learning-Kerne

  3. Schwerin

    Livestream-Mitschnitt des Stadtrats kostet 250.000 Euro

  4. Linux-Distributionen

    Mehr als 90 Prozent der Debian-Pakete reproduzierbar

  5. Porsche Design

    Huaweis Porsche-Smartwatch kostet 800 Euro

  6. Smartphone

    Neues Huawei Y6 für 150 Euro bei Aldi erhältlich

  7. Nahverkehr

    18 jähriger E-Ticket-Hacker in Ungarn festgenommen

  8. Bundesinnenministerium

    Neues Online-Bürgerportal kostet 500 Millionen Euro

  9. Linux-Kernel

    Android O filtert Apps großzügig mit Seccomp

  10. Computermuseum Stuttgart

    Als Computer noch ganze Räume füllten



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
IETF Webpackage: Wie das Offline-Internet auf SD-Karte kommen könnte
IETF Webpackage
Wie das Offline-Internet auf SD-Karte kommen könnte
  1. IETF Netzwerker wollen Quic-Pakete tracken
  2. IETF DNS wird sicher, aber erst später
  3. IETF Wie TLS abgehört werden könnte

Gaming-Monitor Viewsonic XG 2530 im Test: 240 Hertz, an die man sich gewöhnen kann
Gaming-Monitor Viewsonic XG 2530 im Test
240 Hertz, an die man sich gewöhnen kann
  1. LG 43UD79-B LG bringt Monitor mit 42,5-Zoll-Panel für vier Signalquellen
  2. SW271 Benq bringt HDR-Display mit 10-Bit-Panel
  3. Gaming-Bildschirme Freesync-Displays von Iiyama und Viewsonic

Moto Z2 Play im Test: Bessere Kamera entschädigt nicht für kürzere Akkulaufzeit
Moto Z2 Play im Test
Bessere Kamera entschädigt nicht für kürzere Akkulaufzeit
  1. Modulares Smartphone Moto Z2 Play kostet mit Lautsprecher-Mod 520 Euro
  2. Lenovo Hochleistungs-Akku-Mod für Moto Z
  3. Moto Z Schiebetastatur-Mod hat Finanzierungsziel erreicht

  1. Re: Soll das ein Witz sein?!

    Libertybell | 23:02

  2. Re: Ist das nicht toll wenn man eine neue...

    washuu_de | 23:01

  3. Re: Hauptsache...

    ArcherV | 23:00

  4. Re: T-Systems macht's. Wetten?

    thinksimple | 22:58

  5. Re: Eine Beleidigung für echte Fotografen

    ArcherV | 22:57


  1. 22:48

  2. 16:37

  3. 16:20

  4. 15:50

  5. 15:35

  6. 14:30

  7. 14:00

  8. 13:29


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel