Kategorie: Netzwerke & Protokolle (Seite 2 von 5)

TLS 1.3 ist im Mailbetrieb der Normalfall. Sobald Postfix und Dovecot gegen ein aktuelles OpenSSL gelinkt sind, wird es ohne Zutun verwendet. Die Konfigurationsarbeit dreht sich nicht mehr darum, TLS 1.3 zu aktivieren, sondern darum, die alten Protokollversionen sauber abzuschalten und für den verbleibenden TLS-1.2-Fallback eine kontrollierte Cipher-Policy zu definieren.

Voraussetzungen

Auf jedem aktuellen Linux oder BSD ist OpenSSL 3.x längst Default. OpenSSL 1.1.1 ist seit September 2023 End-of-Life und sollte nicht mehr im Einsatz sein. Postfix und Dovecot übernehmen den TLS-Stack vollständig aus der Library, eine eigene Aktivierung von TLS 1.3 entfällt. Welche Version tatsächlich verwendet wird, lässt sich auf dem Server eindeutig prüfen:

postconf -a | grep -i tls
dovecot --version
ldd $(which dovecot) | grep ssl
openssl version

Erscheint OpenSSL 3.x, ist alles an Bord was man braucht. Auch ältere 1.1.1-Builds beherrschen TLS 1.3, sind heute aber kein Argument mehr.

Postfix

Postfix verwendet TLS 1.3 automatisch, sobald die Gegenstelle es anbietet. Wichtig ist die Mindestversion. TLS 1.0 und TLS 1.1 sind kryptografisch tot und gehören aus der Aushandlung ausgeschlossen. Für Submission auf 587 und 465 ist heute realistisch sogar TLS 1.3 only sinnvoll, weil dort nur Mail-Clients hochkommen die eine moderne Library mitbringen. Für SMTP-Relay auf Port 25 zwischen Mailservern bleibt TLS 1.2 als Fallback notwendig, weil die Internet-Realität dort heterogener ist.

Eine solide Basis-Konfiguration für Postfix sieht so aus:

smtpd_tls_protocols = >=TLSv1.2
smtp_tls_protocols  = >=TLSv1.2

smtpd_tls_security_level = may
smtp_tls_security_level  = may

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/DOMAIN/privkey.pem

Die Cipher-Optionen in Postfix wirken ausschließlich auf TLS 1.2 und älter. TLS 1.3 hat eine fest definierte Liste von AEAD-Cipher-Suites und ignoriert die Postfix-Optionen vollständig. Trotzdem ist es sinnvoll, für den Fallback eine saubere Policy zu setzen:

tls_preempt_cipherlist = yes

smtpd_tls_ciphers = high
smtp_tls_ciphers  = high

smtpd_tls_mandatory_ciphers = high
smtp_tls_mandatory_ciphers  = high

Damit greifen ausschließlich AEAD-Cipher mit Forward Secrecy. Welche das konkret sind, regelt OpenSSL über seine Defaults der jeweiligen Distribution. Für die Submission-Ports darf man strenger sein und auf encrypt oder secure hochziehen, während Port 25 mit may opportunistisch bleibt.

Session-Caching reduziert Handshake-Overhead und sollte aktiv sein:

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database  = btree:${data_directory}/smtp_scache

Dovecot

Dovecot nutzt TLS 1.3 ebenfalls automatisch, sofern OpenSSL es liefert. Konfiguriert wird die minimale Protokollversion, alles darunter wird hart abgeschaltet:

ssl = required
ssl_min_protocol = TLSv1.2

Wer nur noch moderne Clients erwartet, kann das auf TLSv1.3 heben. Eigene Praxiserfahrung: für IMAPS auf 993 und Submission auf 587/465 ist das auf einem privat betriebenen Server problemlos machbar. Auf öffentlichen Hostern mit unbekannter Client-Basis lieber bei TLS 1.2 als Untergrenze bleiben.

Die Cipher-Liste betrifft auch in Dovecot nur TLS 1.2 und älter. Eine restriktive Liste verhindert unsaubere Fallbacks bei alten Clients:

ssl_cipher_list = \
ECDHE-ECDSA-CHACHA20-POLY1305:\
ECDHE-RSA-CHACHA20-POLY1305:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES256-GCM-SHA384

ssl_prefer_server_ciphers = yes

Zertifikate werden wie gewohnt eingebunden:

ssl_cert = </etc/letsencrypt/live/DOMAIN/fullchain.pem
ssl_key  = </etc/letsencrypt/live/DOMAIN/privkey.pem

TLS 1.3 und Cipher-Suites

TLS 1.3 unterscheidet sich grundlegend von älteren Versionen. Die Cipher-Suites sind in RFC 8446 fest definiert und bestehen ausschließlich aus AEAD-Verfahren mit integrierter Authentifizierung und Forward Secrecy. Der Mailbetrieb sieht in der Praxis vor allem drei Suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 und TLS_AES_128_GCM_SHA256.

Postfix und Dovecot bieten keine Möglichkeit, diese Cipher direkt anzusteuern. Die Auswahl erfolgt während des Handshakes durch OpenSSL. Das ist kein Mangel, sondern Absicht und reduziert Fehlkonfigurationen erheblich.

Wer trotzdem versucht, TLS-1.3-Cipher über Applikationsoptionen zu beeinflussen, konfiguriert in Wahrheit nur TLS 1.2.

Der vollständige Mail-Crypto-Stack

TLS 1.3 alleine schützt eine SMTP-Verbindung nur dann zuverlässig, wenn die Gegenstelle die Verschlüsselung auch wirklich erwartet. Bei opportunistischem TLS auf Port 25 entscheidet jeder Server selbst, ob er sich auf eine unverschlüsselte Verbindung einlässt. Damit das nicht passiert, gibt es zwei Mechanismen die heute zum Standard gehören:

• DANE nutzt DNSSEC und einen TLSA-Record, um den erwarteten Zertifikat-Fingerprint im DNS zu hinterlegen. Postfix kann das nativ verifizieren, sobald smtp_dns_support_level = dnssec und smtp_tls_security_level = dane gesetzt sind. Voraussetzung ist eine funktionierende DNSSEC-Validierung im lokalen Resolver.
• MTA-STS publiziert die TLS-Erwartung über HTTPS und einen DNS-TXT-Record. Während DANE auf DNSSEC angewiesen ist, kommt MTA-STS ohne aus und wird daher von Anbietern wie Google, Microsoft und Apple breit unterstützt.
• TLS-RPT liefert die Reports zurück, wenn ein Empfangsserver die TLS-Erwartung gerissen hat. Ohne TLS-RPT merkt man Konfigurationsdrift nur durch Zufall, mit TLS-RPT als JSON-Bericht ins Postfach.

In der Praxis lohnt sich keiner der drei Mechanismen alleine. DANE, MTA-STS und TLS-RPT bilden zusammen die durchgängige Kette aus Erwartung, Verifikation und Auditing. Wer nur einen davon hat, verliert eine Etappe.

Logging, Monitoring und Adoption messen

Ohne TLS-Logging fliegt man blind. Postfix bringt das frei Haus mit:

smtpd_tls_loglevel = 1
smtp_tls_loglevel  = 1

Damit landet pro Verbindung eine Zeile im Log mit Protokoll, Cipher und Schlüsselaustausch. Aus diesen Zeilen lässt sich auch die TLS-Adoption auswerten, also wer mit welcher Version und welchem Cipher kommt. Das gleiche Vorgehen habe ich für die Webseite mit dem Beitrag Post-Quantum TLS auf Nginx: 15 Tage $ssl_curve ausgewertet dokumentiert. Für SMTP funktioniert das analog, der einzige Unterschied ist die Logquelle.

Bei Dovecot reicht ein verbose_ssl = yes in der relevanten Service-Sektion, wenn man im Detail wissen will, was der TLS-Handshake gerade tut. Im Normalbetrieb genügt der Default.

Verifikation

Ob TLS 1.3 wirklich genutzt wird, lässt sich von außen sauber prüfen.

SMTP mit STARTTLS:

openssl s_client -starttls smtp -connect mail.example.com:25 -tls1_3

Submission und IMAPS direkt:

openssl s_client -starttls smtp -connect mail.example.com:587 -tls1_3
openssl s_client -connect mail.example.com:465 -tls1_3
openssl s_client -connect mail.example.com:993 -tls1_3

Wird der Handshake mit einem AEAD-Cipher aufgebaut, ist TLS 1.3 aktiv. Fällt die Verbindung auf TLS 1.2 zurück, greift die konfigurierte Cipher-Liste.

Für eine zweite Meinung lohnt sich ein Blick auf Hardenize oder internet.nl. Beide testen den Mail-Stack inklusive DANE, MTA-STS, TLS-RPT und Cipher-Set in einem Rutsch.

Wohin geht die Reise

TLS 1.2 wird in den nächsten Jahren auch im Mail-Bereich aussterben. Auf der Web-Seite ist das praktisch schon passiert, im SMTP-Relay zwischen Mailservern dauert es länger, weil dort die langsameren Migrationszyklen großer Provider den Takt vorgeben. Wer heute neu konfiguriert, sollte TLS 1.0 und 1.1 hart raushalten und TLS 1.2 als reine Fallback-Etappe behandeln.

Die nächste Stufe ist Post-Quantum-Kryptografie. X25519MLKEM768 ist bei mir auf dem Mail-Server seit Anfang 2026 produktiv und ich habe das Setup im Beitrag Post-Quantum TLS für E-Mail dokumentiert. Auf der Webseite habe ich die Adoption über 15 Tage gemessen und die Ergebnisse in 15 Tage $ssl_curve ausgewertet aufgeschrieben. Für den Mail-Stack steht eine analoge Auswertung noch aus, das Setup dafür ist aber identisch.

Fazit

TLS 1.3 erfordert in Postfix und Dovecot keine Sonderbehandlung. Was zählt, ist eine moderne OpenSSL-Version, eine klare Mindest-TLS-Policy, eine saubere Cipher-Liste für den TLS-1.2-Fallback und das Zusammenspiel aus DANE, MTA-STS und TLS-RPT für die Transport-Verschlüsselung im Internet.

Kein Feature-Flag.
Keine Magie.
Nur korrekte Defaults, bewusst begrenzt.

Siehe auch: Post-Quantum TLS für E-Mail mit X25519MLKEM768, MTA-STS einrichten, DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern und Rspamd: Automatisches Spam/Ham-Lernen mit Dovecot und IMAPSieve.

Fragen? Einfach melden.