Mein Jabber Server hat gerade neue Zertifikate bekommen. Die alten waren ausgelaufen…. Ich spare mit die Fingerprints, prüft bitte per TLSA.
So long…
Fragen? Einfach melden.
Schlagwort: TLSA (Seite 2 von 2)
Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.
Zertifikat holen
Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:
openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 \ -servername smtp.kernel-error.de 2>/dev/null | \ openssl x509 -outform PEM > /tmp/server.crt
Das Zertifikat liegt jetzt in /tmp/server.crt.
Hash berechnen
Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:
| Usage | 0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung) |
| Selector | 0 = ganzes Zertifikat, 1 = nur Public Key (SPKI) |
| Matching Type | 0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512 |
Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:
dig _25._tcp.smtp.kernel-error.de TLSA +short
Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):
# Selector 0 (Full Certificate), SHA-256 openssl x509 -in /tmp/server.crt -outform DER | openssl sha256 # Ausgabe: SHA2-256(stdin)= 94c8e1bd...
Bei Selector 1 (nur SPKI, Public Key) und SHA-256:
# Selector 1 (SPKI), SHA-256 openssl x509 -in /tmp/server.crt -noout -pubkey | \ openssl pkey -pubin -outform DER | openssl sha256
Den berechneten Hash mit dem Wert aus dem TLSA-Record vergleichen. Stimmen sie überein, ist der Record korrekt.
Schnelltest mit posttls-finger
Wer nicht alles von Hand machen will: posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf in einem Schritt:
posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.
Wer DANE für den eigenen Mailserver einrichten will, findet die Anleitung unter Postfix mit DANE und DNSSEC absichern. Die Grundlagen zu DANE und TLSA-Records erklärt der Beitrag DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern. Fragen? Einfach melden.
Meine Domains sind schon lange per DNSSEC gesichert. Für den Webserver hatte ich auch schnell TLSA-Records veröffentlicht, damit die TLS-Verbindung per DANE abgesichert ist. Seit Postfix 2.11 beherrscht auch der MTA die Prüfung von TLSA-Records — damit lässt sich ausgehende E-Mail-Verschlüsselung kryptographisch verifizieren, ohne sich auf das CA-System verlassen zu müssen.
Postfix konfigurieren
Zwei Zeilen in der main.cf reichen, damit Postfix beim Versand TLSA-Records prüft:
postconf -e "smtp_dns_support_level = dnssec" postconf -e "smtp_tls_security_level = dane"
smtp_dns_support_level = dnssec weist den SMTP-Client an, DNSSEC-validierte DNS-Antworten zu verlangen. smtp_tls_security_level = dane aktiviert die TLSA-Prüfung — Postfix sucht automatisch nach TLSA-Records für den Zielserver. Gibt es keinen TLSA-Record oder kein DNSSEC, fällt Postfix auf opportunistisches TLS zurück. Die Kommunikation mit Servern ohne DANE leidet also nicht. Details stehen in der Postfix DANE-Dokumentation.
TLSA-Record erstellen
Der TLSA-Record enthält einen Hash des TLS-Zertifikats (oder des Public Keys), den der Empfänger-Mailserver im DNS veröffentlicht. So erzeugt man den SHA-256-Hash des Public Keys aus dem Zertifikat:
openssl x509 -in postfix.pem -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256
Den Hash trägt man als TLSA-Record in die DNS-Zone ein — für Port 25 (SMTP) und optional Port 465 (Implicit TLS):
_25._tcp.smtp.kernel-error.de. 3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1 _465._tcp.smtp.kernel-error.de. 3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
Die Felder 3 1 1 bedeuten: DANE-EE (End Entity, kein CA-Vertrauen nötig), SPKI (nur Public Key, nicht das ganze Zertifikat), SHA-256. Der TTL von 3600 Sekunden ist bewusst kurz — bei einem Zertifikatswechsel soll der alte Record schnell ablaufen. Mehr zum Aufbau von TLSA-Records steht in RFC 7672.
Testen
Mit posttls-finger (Teil von Postfix) lässt sich prüfen, ob die DANE-Verifikation funktioniert:
posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
Die entscheidende Zeile in der Ausgabe:
Verified TLS connection established to smtp.kernel-error.de[...]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Verified statt Untrusted — der TLSA-Record stimmt mit dem Zertifikat überein, die Verbindung ist DANE-verifiziert. Im Postfix-Log sieht man denselben Unterschied:
smtp[3779]: Verified TLS connection established to mx02.example.de[...]:25 smtp[3779]: Untrusted TLS connection established to smtp2.example.de[...]:25
Verified = DANE-geprüft und in Ordnung. Untrusted = TLS aktiv, aber kein gültiger TLSA-Record vorhanden — die Verschlüsselung funktioniert trotzdem, nur ohne kryptographische Verifikation des Zertifikats.
Warum DANE besser ist als das CA-System
DANE verankert das Vertrauen im DNS statt bei Certificate Authorities. Der Domaininhaber veröffentlicht den Hash seines Zertifikats selbst — DNSSEC schützt den Record vor Manipulation. Keine CA kann ein falsches Zertifikat für die Domain ausstellen und damit die Verbindung aufbrechen. Das Ganze kostet nichts außer einem DNS-Record und funktioniert für jeden, der DNSSEC betreibt.
Zum Vergleich: Das damalige „E-Mail made in Germany“ (EmiG) setzte auf eine TÜV-Zertifizierung, die sich nur große Provider leisten konnten. Sicherheit nur für Unternehmen mit Budget — das ist das Gegenteil von dem, was ich unterstütze.
Update August 2014: Ich habe Mailgraph um DANE-Graphen erweitert, um den Anteil verifizierter Verbindungen zu visualisieren.
Siehe auch: TLSA/DANE-Records prüfen, TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL, Postfix und DANE: „Server certificate not verified" debuggen, Postfix: Eingehende E-Mails ohne TLS ablehnen
Fragen? Einfach melden.
Meine Domain ist per DNSSEC gesichert, der Webserver bietet TLS an. Mit DANE (DNS-based Authentication of Named Entities) lässt sich beides verbinden: Die Checksumme des TLS-Zertifikats wird als TLSA-Record im DNS veröffentlicht — DNSSEC schützt diesen Record vor Manipulation.
Warum DANE?
Das klassische CA-System hat ein grundsätzliches Problem: Jede der hunderten Certificate Authorities kann ein Zertifikat für jede Domain ausstellen. Wird eine CA kompromittiert oder handelt fahrlässig, können gefälschte Zertifikate im Umlauf sein — der Browser merkt nichts. DANE löst das, indem der Domaininhaber selbst festlegt, welches Zertifikat gültig ist. Der Hash steht im DNS, DNSSEC garantiert die Integrität. Keine CA kann das unterlaufen.
Unterstützt ein Client DANE, prüft er beim TLS-Handshake, ob der TLSA-Record zum angebotenen Zertifikat passt. Das funktioniert auch mit selbstsignierten Zertifikaten — solange der Hash stimmt und DNSSEC aktiv ist, wird dem Zertifikat vertraut. Die Spezifikation steht in RFC 6698.
TLSA-Record erstellen
Der TLSA-Record enthält einen Hash des Public Keys (SPKI) aus dem Zertifikat. Mit OpenSSL erzeugt:
openssl x509 -in server.pem -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256
Den Hash trägt man als TLSA-Record in die DNS-Zone ein. Für den Webserver (Port 443):
_443._tcp.www.kernel-error.de. 3600 IN TLSA 3 1 1 a321...f7
Die drei Zahlen 3 1 1 bedeuten:
- 3 — DANE-EE (End Entity): Das Zertifikat wird direkt geprüft, kein CA-Vertrauen nötig
- 1 — SPKI (Subject Public Key Info): Nur der Public Key wird gehasht, nicht das ganze Zertifikat. Vorteil: Bei Erneuerung mit demselben Key bleibt der TLSA-Record gültig
- 1 — SHA-256 als Hash-Algorithmus
Der TTL von 3600 Sekunden ist bewusst kurz gewählt — bei einem Zertifikatswechsel mit neuem Key soll der alte Record schnell ablaufen.
Prüfen
Mit dig lässt sich der TLSA-Record abfragen:
dig TLSA _443._tcp.www.kernel-error.de +short 3 1 1 a321...f7
Ob der Record auch zum tatsächlich ausgelieferten Zertifikat passt, prüft man mit OpenSSL — Hash vom Server-Zertifikat erzeugen und mit dem DNS-Record vergleichen:
echo | openssl s_client -connect www.kernel-error.de:443 2>/dev/null \ | openssl x509 -noout -pubkey \ | openssl pkey -pubin -outform DER \ | openssl dgst -sha256
Stimmen die Hashes überein, ist alles korrekt. Komfortabler geht es mit posttls-finger (Teil von Postfix) — das Tool prüft TLSA-Record und Zertifikat in einem Schritt.
DANE für E-Mail
DANE funktioniert nicht nur für Webserver. Für E-Mail ist es sogar wichtiger — SMTP hat kein Vertrauensmodell wie Browser, opportunistisches TLS kann trivial per Downgrade-Angriff ausgehebelt werden. Mit DANE und TLSA-Records auf Port 25 wird die Verschlüsselung kryptographisch verifizierbar. Wie man das mit Postfix einrichtet, steht im Beitrag Postfix mit DANE und DNSSEC absichern. Zur Visualisierung des DANE-Anteils im Mailverkehr habe ich damals Mailgraph um DANE-Graphen erweitert.
Siehe auch: DNSSEC einrichten
Fragen? Einfach melden.