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 1. Dezember 2018 um 18:57 Uhr durch BRFBlake (Diskussion | Beiträge) (Link aktualisiert; Addon wird nicht mehr entwickelt). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Eine gesichtete Version dieser Seite, die am 1. Dezember 2018 freigegeben wurde, basiert auf dieser Version.

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 dazu 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 Browser-Herstellern 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 ö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:

Normen und Standards

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@1@2Vorlage:Toter Link/www.internetsociety.org (Seite nicht mehr abrufbar, festgestellt im April 2018. Suche in Webarchiven)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis.
  3. ↑ [irssi] Revision 5218. In: Svn.irssi.org. Archiviert vom Original am 16. April 2014; abgerufen am 16. April 2014.
  4. ↑ Posteo unterstützt DANE/TLSA. posteo.de, abgerufen am 15. Mai 2014.
  5. ↑ DANE und DNSsec für sicheren E-Mail-Versand bei mailbox.org. mailbox.org, archiviert vom Original (nicht mehr online verfügbar) am 21. August 2014; abgerufen am 29. Mai 2014.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/mailbox.org
  6. ↑ Secure Hosting mit DANE/TLSA. dotplex.de, abgerufen am 21. Juni 2014.
  7. ↑ mail.de unterstützt DANE/TLSA - Kein Beitritt in Verbund "E-Mail made in Germany". mail.de, abgerufen am 22. Juni 2014.
  8. ↑ DANE Everywhere?! Let’s Make the Internet a Private Place Again. tutanota.com, abgerufen am 18. Februar 2016.
  9. ↑ DANE TLS authentication., Postfix Documentation
  10. ↑ github.com, seit Version 4.85 EXPERIMENTAL_DANE
  11. ↑ Verifying a certificate using DANE (DNSSEC). Gnu.org, abgerufen am 15. Mai 2014.
  12. ↑ Bug #77327 for Net-DNS: DANE TLSA support. rt.cpan.org, abgerufen am 15. Mai 2014.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=DNS-based_Authentication_of_Named_Entities&oldid=183302135“