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.
