DANE und TLSA DNS-Records erklärt

DANE ist eine noch selten eingesetzte Technik, die Domainnamen mit einem oder mehreren TLS-/SSL-Zertifikaten verknüpft. Durch das DNS wird dem Client diktiert, welche Sicherheitszertifikate für eine Domain gültig sein sollen. Hintergrund ist, dass jede große, anerkannte CA der Welt (und davon gibt es hunderte) theoretisch für jede Domain gültige TLS-Zertifikate ausgeben kann. Dass das viel Spielraum für Manipulation und Missbrauch bietet, liegt auf der Hand. Indem man im DNS Informationen dazu ablegt, welche einzelnen Zertifikate oder Zertifizierungsstellen (CAs) für die Domain genutzt werden dürfen, kann man die Sicherheit signifikant verbessern. DANE muss zwingend mit DNSSEC kombiniert werden.

DANE nutzt einen neuen Record-Typen namens “TLSA”. Ein TLSA-Record sieht beispielsweise so aus:

_443._tcp.thomas-leister.de.    3600    IN    TLSA    3 1 1    1306c288896771534a5b60744a535e1025f79b0b64e1bbc89278ba4d413cb9f1

_443: Gibt den Port an, für den die Zertifikatseinschränkung gelten soll. In diesem Beispiel Port 443 für SSL. Um den Record für alle Ports gültig zu machen, kann * (Wildcard) genutzt werden.
_tcp: Gibt das Layer-4 (Transport-) Protokoll an, welches genutzt wird. Meistens _tcp, kann aber auch _udp und _sctp sein.
thomas-leister.de.: Domain oder Subdomain, für die der Eintrag gelten soll. Auf den Punkt am Ende achten!
3600: TTL (Time to live) - Gültigkeitsdauer bis zum Refresh in Sekunden
3 1 1: Parameter: TLSA Certificate Usage, TLSA-Selector, TLSA Matching Type. (wie unten erklärt)
1306c2…: Hashwert aus dem eigenen Public Cert oder dem Public Cert der CA (je nach “Certificate Usage”).

DANE kann man in verschiedenen Betriebsmodi 0-3 einsetzen (“TLSA Certificate Usages”):

“TLSA Certificate Usages” (Erster Parameter)

0: CA Constraints: Das Zertifikat muss von der angegebenen CA stammen. Der Hash wird aus dem Public Certificate der CA generiert. x509 Trust chain muss gültig sein.
1: Certificate Constraints: Nur das angegebene Zertifikat darf mit der Domain eingesetzt werden. Der Hash wird aus diesem Zertifikat generiert. x509 Trust chain muss gültig sein.
2: Trust anchor assertion: Das Zertifikat muss von der angegebenen CA stammen. Hash aus Public Cert der CA. Keine Trust chain-Überprüfung.
3: Domain-Issued certificates: Nur das angegebene Zertifikat darf mit der Domain eingesetzt werden. Hash aus dem eigenen Public Cert. Keine Trust chain-Überprüfung.

Ihr habt also immer die Wahl zwischen CA überprüfen vs. Zertifikat überprüfen und zwischen Trust chain-Überprüfung vs. keiner Trust chain-Überprüfung. Trust chain-Überprüfung heißt: Die Gültigkeit des TLS-Zertifikats an sich wird überprüft. Mit DANE können auch nicht offiziell anerkannte, selbst signierte Zertifikate eingesetzt werden. Dazu wird die Trust chain-Überprüfung abgeschaltet.

“TLSA-Selectors” (Zweiter Parameter)

0: Gesamtes Zertifikat wird gehashed: Der Record muss mit jeder Zertifikatserneuerung aktualisiert werden.
1: Nur die “SubjectPublicKeyInfo” wird gehashed: Vorteil: Wenn immer derselbe Private Key für die Generierung von Zertifikaten genutzt wird, muss der TLSA-Record nicht mit jedem Zertifikatswechsel erneuert werden.

“TLSA Matching Types” (Dritter Parameter)

0: Kein Hash: Zertifikatsdaten werden direkt verglichen.
1: SHA-256
2: SHA-512

Für die meisten Einsatzszenarien ist eine Parameterfolge von 3 0 1 empfehlenswert.

Wie bereits erwähnt, ist DANE noch selten eingesetzt. Vor allem zur Absicherung des Mailtransports zwischen Mailservern wird es aber mehr und mehr eingesetzt, beispielsweise von Mailbox.org und Posteo.de. Aber auch einzelne Websites bieten DANE an, sodass der Nutzer mithilfe eines Browser-Plugins feststellen kann, ob die korrekten Sicherheitszertifikate verwendet werden. Auf native Unterstützung in Webbrowsern müssen wir wohl noch einige Zeit warten.

Update: Hier gibt es übrigens einen praktischen TLSA-Record-Generator: https://de.ssl-tools.net/tlsa-generator