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]
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.
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:
Für die Zertifikatsverwendung sind die folgenden Werte möglich:
0: PKIX-TA (englischCA 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 (englischService 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 (englischTrust 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 (englischDomain-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]
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.
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.
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.
RFC6394 – Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE). Oktober 2011 (Konzept, englisch).
RFC6698 – The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. 2012 (Hauptdokument, englisch).
RFC7218 – Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE). April 2014 (Ergänzung, englisch).
RFC7671 – The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. Oktober 2015 (Ausprägung für TLS, englisch).
RFC7672 – SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). Oktober 2015 (Ausprägung für SMTP, englisch).
RFC7673 – Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records. Oktober 2015 (Ausprägung für TLSA, englisch).