Dies ist die archivierte Version des Blogs vom 05.01.2017. Aktuelle Beiträge findest du unter thomas-leister.de
 

DANE ist ein noch rar gesätes Protokoll, das 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. Normalerweise wird DANE in Kombination mit DNSSEC (Internetstandard zur Absicherung von DNS-Zonen) eingesetzt. Prinzipiell ist DNSSEC für die Nutzung von DANE nicht zwingend erforderlich. Es stellt sich jedoch die Frage, ob es sinnvoll ist, DANE Informationen in einer nicht manipulationssicheren Zonendatei unter zu bringen … besser ist es, DANE mit aktiviertem DNSSEC zu nutzen.

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


Post published on 7. Januar 2016 | Last updated on 8. Januar 2016
Tags:           

Diesen Blog unterstützen

Wenn Dir der Beitrag gefallen hat, freue ich mich über einen kleinen Obolus :-) Bitcoin QR Code

PayPal-Seite: https://www.paypal.me/ThomasLeister
Meine Bitcoin-Adresse: 15z8 QkNi dHsx q9WW d8nx W9XU hsdf Qe5B 4s

Siehe auch: Unterstützung

Informationen zum Autor

Thomas Leister

Geb. 1995, Kurzhaar-Metaller, Geek und Blogger. Nutzt seit Anfang 2013 ausschließlich Linux auf Desktop und Servern. Student der Automobilinformatik an der Hochschule für angewandte Wissenschaften in Landshut.

One thought on “DANE und TLSA DNS Records erklärt

  • Danke danach habe ich schon lange gesucht. Muste erst mal ein Hoster finden der es gescheit unterstützt. Bin jetzt bei OVH und dort funtioniert DANE Perfekt DNSSEC braucht noch einen Tag, da ich die Domain Transferiert habe.
    Gute Erklärung der einzelne Parameter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.