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.