DNS-based Authentication of Named Entities

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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]

Problemstellung[Bearbeiten | Quelltext bearbeiten]

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. Dadurch kann der Inhaber einer Domain die Reichweite von CAs beschränken.

TLSA Resource Record[Bearbeiten | Quelltext bearbeiten]

DANE definiert einen neuen DNS Resource Record namens „TLSA“. Dieser enthält ein Zertifikat im PKIX-Format, dessen Fingerprint oder öffentlichen Schlüssel.

Das folgende Beispiel zeigt die Verwendung von DANE für die Mail Transfer Agents einer E-Mail-Domain. 

example.com.               IN MX 0 mx1.example.net.
example.com.               IN MX 0 mx2.example.net.
_25._tcp.mx1.example.net.  IN TLSA 3 1 1 (
                              8A9A70596E869BED72C69D97A8895DFA
                              D86F300A343FECEFF19E89C27C896BC9 )
_25._tcp.mx2.example.net.  IN TLSA 3 1 1 (
                              C164B2C3F36D068D42A6138E446152F5
                              68615F28C69BD96A73E354CAC88ED00C )

Im Domainnamen des TLSA-Records werden die Portnummer und das verwendete Transportprotokoll kodiert. In dem Beispiel wird Port 25 (SMTP) über TCP verwendet. Im RDATA-Feld (rechts neben der Zeichenkette „TLSA“) gibt es vier Parameter:

  1. Zertifikatsverwendung (englisch certificate usage)
  2. Selektor (englisch selector)
  3. Zuordnungsart (englisch matching type)
  4. Zertifikatsdaten (englisch certificate association data)

Zertifikatsverwendung[Bearbeiten | Quelltext bearbeiten]

Für die Zertifikatsverwendung sind die folgenden Werte möglich:

  • 0: PKIX-TA (englisch CA constraint). Der Client wird aufgefordert, für die Validierung des Zertifikats einen definierten Trust Anchor zu benutzen, bei dem es sich um eine vertrauenswürdige PKIX-Zertifizierungsstelle handeln muss. Das Server-Zertifikat muss seine Vertrauenskette bis auf diesen „Trust Anchor“ zurückführen und die Zertifikatsprüfung bestehen.
  • 1: PKIX-EE (englisch Service certificate constraint). Der Client wird aufgefordert, dem im TLSA-Record referenzierten Server-Zertifikat zu vertrauen, das von einer vertrauenswürdigen PKIX-Zertifizierungsstelle ausgestellt sein muss. Das Zertifikat und die gesamte Vertrauenskette müssen die Prüfung auf Vertrauenswürdigkeit bestehen.
  • 2: DANE-TA (englisch Trust anchor assertion). Der Client wird aufgefordert, für die Validierung des Zertifikates einen definierten Trust Anchor zu benutzen. Im Unterschied zu PKIX-TA braucht es sich hierbei nicht um eine für den Client vertrauenswürdige PKIX-Zertifizierungsstelle handeln. Das Server-Zertifikat muss seine Vertrauenskette bis auf diesen „Trust Anchor“ zurückführen.
  • 3: DANE-EE (englisch Domain-issued certificate). Der Client wird aufgefordert, dem im TLSA-Record referenzierten Zertifikat zu vertrauen. Eine Prüfung der Vertrauenshierarchie wird nicht durchgeführt.

Bei PKIX-Werten (0 und 1) findet die DANE-Prüfung zusätzlich zu der auch sonst bei TLS üblichen Zertifikatsprüfung statt; die DANE-Prüfung dient also dazu, von öffentlichen Zertifizierungsstellen ausgegebene Zertifikate zu bestätigen. Bei DANE-Werten (2 und 3) hat der Domain-Inhaber die Möglichkeit, für seine TLS-gesicherten Dienste eigene, auch selbst signierte Zertifikate zu erstellen, ohne dass eine dem Client bekannte Zertifizierungsstelle einbezogen werden muss. Durch die Wahl zwischen „Trust Anchor“ (TA) und „End Entity“ (EE) kann der Domain-Inhaber selbst entscheiden, ob er die DANE-Sicherheit an einem CA- oder Server-Zertifikat verankert.[1][2]

Selektor[Bearbeiten | Quelltext bearbeiten]

Der Parameter Selektor nimmt die folgenden Werte an:

  • 0: Full certificate. Der TLSA-Eintrag bezieht sich auf das vollständige Zertifikat.
  • 1: SubjectPublicKeyInfo. Der TLSA-Eintrag bezieht sich auf den öffentlichen Schlüssel eines Zertifikats. Durch diese Einstellung kann ein ablaufendes Zertifikat erneuert werden, ohne dass der zugehörige TLSA-Eintrag geändert werden muss, sofern das bisherige Schlüsselpaar weiterverwendet wird.

Zertifikatszuordnung[Bearbeiten | Quelltext bearbeiten]

Der Parameter Zuordnungsart steuert, welche Art von Zertifikatsdaten im nachfolgenden Parameter verwendet werden.

  • 0: Full. Der Client vergleicht eine vollständige Eins-zu-Eins-Kopie des Zertifikats bzw. öffentlichen Schlüssels. Mit dieser Einstellung kann die DNS-Antwort sehr lang werden, sodass sie vermutlich fragmentiert werden muss.
  • 1: SHA-256. Der Client vergleicht einen SHA-256-Hashwert des Zertifikats bzw. öffentlichen Schlüssels.
  • 2: SHA-512. Der Client vergleicht einen SHA-512-Hashwert des Zertifikats bzw. öffentlichen Schlüssels.

Zertifikatsdaten[Bearbeiten | Quelltext bearbeiten]

Die Zertifikatsdaten werden in Konfigurationsdateien und DNS-Tools als hexadezimale Zeichenfolge ein- und ausgegeben. Bei Hashwerten (1 und 2) ist das die ohnehin übliche Darstellung. Bei einer vollständigen Kopie (0) ist das eine im Umgang mit Zertifikaten eher ungebräuchliche Darstellung.

Implementierungen[Bearbeiten | Quelltext bearbeiten]

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

Normen und Standards[Bearbeiten | Quelltext bearbeiten]

  • RFC 6394 – Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE). Oktober 2011 (Konzept, englisch).
  • RFC 6698 – The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. 2012 (Hauptdokument, englisch).
  • RFC 7218 – Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE). April 2014 (Ergänzung, englisch).
  • RFC 7671 – The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. Oktober 2015 (Ausprägung für TLS, englisch).
  • RFC 7672 – SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). Oktober 2015 (Ausprägung für SMTP, englisch).
  • RFC 7673 – Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records. Oktober 2015 (Ausprägung für TLSA, englisch).

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. ↑ a b RFC 6698 – The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. 2012 (englisch).
  2. ↑ RFC 7671 – The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. 2015 (englisch).
  3. ↑ End of Support. dnssec-validator.cz, 2018
  4. ↑ [irssi] Revision 5218. In: Svn.irssi.org. Archiviert vom Original (nicht mehr online verfügbar) am 16. April 2014; abgerufen am 16. April 2014.
  5. ↑ Posteo unterstützt DANE/TLSA. posteo.de, abgerufen am 15. Mai 2014.
  6. ↑ 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.
  7. ↑ Secure Hosting mit DANE/TLSA. dotplex.de, abgerufen am 21. Juni 2014.
  8. ↑ mail.de unterstützt DANE/TLSA - Kein Beitritt in Verbund "E-Mail made in Germany". mail.de, abgerufen am 22. Juni 2014.
  9. ↑ DANE Everywhere?! Let’s Make the Internet a Private Place Again. tutanota.com, abgerufen am 18. Februar 2016.
  10. ↑ Encryption for All Emails: Tutanota Uses DANE on Top of SSL and PFS for Maximum Security. Abgerufen am 4. März 2019 (englisch).
  11. ↑ Mehr Verschlüsselungssicherheit für E-Mails: WEB.DE und GMX starten DANE. Abgerufen am 21. Februar 2023.
  12. ↑ Sendmail DANE
  13. ↑ DANE TLS authentication., Postfix Documentation
  14. ↑ github.com, seit Version 4.85 EXPERIMENTAL_DANE
  15. ↑ DANE. Abgerufen am 17. Dezember 2015.
  16. ↑ Verifying a certificate using DANE (DNSSEC). Gnu.org, abgerufen am 15. Mai 2014.
  17. ↑ Richard Levitte: DANE CHANGES. 7. Januar 2016, abgerufen am 11. Januar 2021.
  18. ↑ 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=244048896“