Zum Inhalt springen

DNS-based Authentication of Named Entities

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 11. Februar 2015 um 00:55 Uhr durch Trustable (Diskussion | Beiträge) (stil). Sie kann sich erheblich von der aktuellen Version unterscheiden.

DNS-based Authentication of Named Entities (DANE) ist ein Netzwerkprotokoll, das dazu dient, den Datenverkehr abzusichern. Das Protokoll erweitert die verbreitete Transportwegverschlüsselung SSL/TLS in der Weise, dass die verwendeten Zertifikate nicht unbemerkt ausgewechselt werden können und erhöht so die Sicherheit beim verschlüsselten Transport von E-Mails und beim Zugriff auf Webseiten.

Dazu werden X.509-Zertifikate mit DNS-Einträgen verknüpft und per DNS-Security Extensions (DNSSEC) gesichert. DANE kann außerdem von Domaininhabern genutzt werden, eigene Zertifikate auszustellen, ohne auf eine bestehende Zertifizierungsstelle (Certificate Authority - CA) zurückgreifen zu müssen.[1]

Grundkonzept

Wenn beispielsweise ein Nutzer mit seinem Browser als Client eine gesicherte TLS-Verbindung mit einer Webseite, etwa „https://www.example.com/“, aufbauen will, möchte er sicherstellen, dass der antwortende Server auch legitimiert ist, die gewünschte Webseite auszuliefern. Dazu prüft der Client zunächst, ob die genannte Domain in dem vom Server angebotenen Zertifikat eingetragen ist.

Anschließend gilt es noch sicherzustellen, dass das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt und beglaubigt wurde. Welche CAs als vertrauenswürdig eingestuft werden, entscheidet in den meisten Fällen nicht der Benutzer. Vielmehr greift der Browser automatisch auf eine Liste vertrauenswürdiger CAs zurück, die ihrerseits wiederum als Trust Anchors (Vertrauensursprung) für die Zertifikatshierarchie des Client-Zertifikats dienen.

Zahlreiche schwerwiegende Zwischenfälle mit von Browserherstellern zunächst als vertrauenswürdig eingestuften CAs ließen jedoch Zweifel an der Sicherheit dieses Vorgehens aufkommen. Es gibt u. a. keinerlei Einschränkung, welche CAs Zertifikate für bestimmte Domains beglaubigen dürfen.

An dieser Stelle setzt DANE an: Clients können damit bei DNS-Servern nachfragen, welche Zertifikate sie als vertrauenswürdig einstufen können. Dazu wird ein neuer DNS Resource Record „TLSA“ definiert. Dieser enthält ein Zertifikat im PKIX-Format, dessen Fingerprint oder dessen öffentlichen Schlüssel. Bei diesem sind drei Arten von Antworten möglich:

  1. Service Certificate Constraints: Der Client wird aufgefordert, nur ein definiertes Zertifikat zu akzeptieren. Das Zertifikat selbst muss die Prüfung auf Vertrauenswürdigkeit bestehen.
  2. Domain-Issued Certificate: Der Client wird aufgefordert, dem im TLSA-Record referenzierten Zertifikat zu vertrauen. Eine Prüfung der Vertrauenshierarchie wird nicht durchgeführt.
  3. Trust Anchor Assertion: Der Client wird aufgefordert, für die Validierung des Zertifikates einen definierten Trust Anchor zu benutzen. Das Zertifikat muss seine Vertrauenskette bis auf diesen Trust Anchor zurückführen und die Zertifikatsprüfung bestehen.

„Service Certificate Constraint“-Einträge dienen also dazu, durch öffentliche Roots ausgegebene Zertifikate zu bestätigen. „Domain-Issued Certificates“ geben dem Domaininhaber die Möglichkeit, für seine TLS-gesicherten Dienste eigene, auch selbst signierte Zertifikate auszugeben, ohne dass eine dem Client bekannte CA einbezogen werden muss. „Trust Anchor Assertion“ dient schließlich dazu, bei selbst betriebenen (privaten) Zertifizierungsstellen den betreffenden Trust Anchor bekanntzumachen.

Allen drei Antworten ist gemeinsam, dass sie die Reichweite von Trust Anchors beschränken. Während in den beiden ersten Fällen ganz bestimmte Vertrauensursprünge ausgeschlossen werden, wird im dritten Fall explizit ein Vertrauensursprung definiert.[2]

Implementierungen

Unter anderem folgende Anwendungen bzw. Dienste unterstützen DANE:

Einzelnachweise

  1. RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
  2. http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec
  3. [Internetquelle: archiv-url ungültig [irssi] Revision 5218.] In: Svn.irssi.org. Archiviert vom Original am 16. April 2014; abgerufen am 16. April 2014.
  4. posteo.de: Posteo unterstützt DANE/TLSA. Abgerufen am 15. Mai 2014.
  5. mailbox.org: DANE und DNSsec für sicheren E-Mail-Versand bei mailbox.org. Abgerufen am 29. Mai 2014.
  6. dotplex.de: Secure Hosting mit DANE/TLSA. Abgerufen am 21. Juni 2014.
  7. mail.de: mail.de unterstützt DANE/TLSA - Kein Beitritt in Verbund "E-Mail made in Germany". Abgerufen am 22. Juni 2014.
  8. tutanota.de: DANE Everywhere?! Let’s Make the Internet a Private Place Again. Abgerufen am 13. Januar 2015.
  9. DANE TLS authentication., Postfix Documentation
  10. Gnu.org: Verifying a certificate using DANE (DNSSEC). Abgerufen am 15. Mai 2014.
  11. rt.cpan.org: Bug #77327 for Net-DNS: DANE TLSA support. Abgerufen am 15. Mai 2014.