1. Mail Transfer Agent
Täglich versendet und empfängt mein E-Mail-Server hunderte von E-Mails – meist über einen TLS-verschlüsselten Kanal. Vor ein paar Jahren war das noch anders. Damals unterhielten sich E-Mail-Server untereinander noch größtenteils im Klartext, also unverschlüsselt, was der E-Mail weitläufig den Ruf einer »Postkarte« einbrachte.
Das hat sich heute glücklicherweise geändert. Beim Versenden und Empfangen von E-Mails beobachte ich heute fast ausschließlich eine TLS-verschlüsselte Kommunikation unter den E-Mail-Servern. Klartext-Verbindungen stellen eine Ausnahme dar und sind meist auf veraltete Systeme zurückzuführen, die entweder nicht geupdatet werden können oder bei denen die jeweiligen Betreiber die letzten Jahre im Tiefschlaf verbracht haben.
Kurz: Eine TLS-verschlüsselte Kommunikation zwischen E-Mail-Servern sollte heute zum Standard gehören. Doch eine saubere, abwärtskompatible aber dennoch moderne TLS-Konfiguration eines E-Mail-Servers auf Basis von Postfix ist nicht unbedingt trivial. Im vorliegenden Beitrag möchte ich auf wichtige Verschlüsselungsoptionen von Postfix eingehen und den Parallelbetrieb auf Basis von ECDSA– / RSA-Zertifikaten vorstellen.
2. Vorwissen
Postfix ist ein sogenannter Mail Transfer Agent (MTA), also ein Serverdienst, der E-Mails entgegennimmt und versendet. Verfügbar ist Postfix für nahezu alle Unix- und Linux-Derivate. Neben Postfix gibt es weitere MTAs wie bspw. Exim oder sendmail, die allerdings nicht an die Verbreitung von Postfix heranreichen.
Unter Debian GNU/Linux liegt die Konfigurationsdatei von Postfix unter:
/etc/postfix.main.cf
Bei Postfix lässt sich fast alles über diese zentrale Konfigurationsdatei anpassen. Eine umfassende Dokumentation der möglichen Parameter findet ihr unter man 5 postconf. Im vorliegenden Beitrag beschränke ich mich auf Parameter, mit denen sich der ein- und ausgehende (verschlüsselte) Datenverkehr mit anderen E-Mail-Servern beeinflussen lässt.
2.1 smtp / smtpd
Die im vorliegenden Beitrag vorgestellten Parameter ähneln fast alle einem Muster:
- smtp_XY: Parameter, denen im Namen ein »smtp« vorangeht, gelten für den Versand von E-Mails. Also alle E-Mails die der MTA versendet (Outgoing).
- smtpd_XY: Diese Parameter betreffen den Empfang (Incoming) von E-Mails.
Aus der Sicht von Postfix wird also zwischen ein- (Incoming) und ausgehenden (Outgoing) Verbindungen unterschieden. Das bedeutet für uns: Man kann die Parameter für den ein- und ausgehenden TLS-Verbindungsaufbau (bis zu einem gewissen Grad) getrennt voneinander konfigurieren.
2.2. (Postfix-)Umgebung
Die vorgestellte Beispielkonfiguration basiert auf folgender Umgebung und Programmversionen bzw. Bibliotheken:
- Betriebssystem: Debian GNU/Linux (Stretch – Stable)
- Postfix: 3.1.6 (Befehl: postconf mail_version)
- OpenSSL: OpenSSL 1.1.0f (25. Mai 2017) (Befehl: openssl version)
Insbesondere abweichende OpenSSL-Bibliotheken können die angebotenen bzw. akzeptieren TLS-Cipher-Suiten grundlegend beeinflussen. Darauf werde ich später nochmal im Detail eingehen.
3. Vorarbeiten
3.1 RSA- und ECDSA-Schlüsselpärchen
Ihr solltet bereits ein RSA– und ECDSA-Schlüsselpärchen erzeugt haben, welches von einer CA beglaubigt wurde. Für diesen Zweck nutze ich das acme.sh Shell-Skript, um mir anschließend via Let’s Encrypt ein »gültiges« Zertifikat zu generieren. Ich reiße das im Folgenden kurz an.
Beantragen eines Let’s Encrypt Zertifikats auf Basis von RSA:
./acme.sh --issue -d mail.kuketz.de --keylength 4096 --standalone
Mit dem Befehl lässt sich ein RSA-Zertifikat für die Domain »mail.kuketz.de« mit einer Schlüssellänge von 4096 Bit beantragen. Da auf dem E-Mail-Server (natürlich) kein Webserver zum Einsatz kommt, kann das acme.sh Skript einen Standalone-Webserver (socat) für den Zweck der Ausstellung nutzen.
Beantragen eines Let’s Encrypt Zertifikats auf Basis von ECDSA:
./acme.sh --issue -d mail.kuketz.de --keylength ec-384 --standalone
Der Befehl erzeugt ein ECDSA-Zertifikat auf Basis von P-384 (secp384r1) elliptischen Kurven mit einer Schlüssellänge von 384 Bit (vergleichbar mit einer RSA-Schlüssellänge von 7680 Bit).
Nachdem Let’s Encrypt beide Zertifikate ausgestellt bzw. beglaubigt hat, kopiere ich die öffentlichen (Fullchain-)Zertifikate nach:
/etc/ssl/certs/mail.kuketz.de.cer /etc/ssl/certs/mail.kuketz.de_ecc.cer
und die privaten Schlüssel unter:
/etc/ssl/private/mail.kuketz.de.key /etc/ssl/private/mail.kuketz.de_ecc.key
Im Anschluss werden die Berechtigungen gesetzt:
chmod 600 /etc/ssl/certs/mail.kuketz.de.cer chmod 600 /etc/ssl/private/mail.kuketz.de.key chmod 600 /etc/ssl/certs/mail.kuketz.de_ecc.cer chmod 600 /etc/ssl/private/mail.kuketz.de_ecc.key
Fertig.
3.2 (E)DH-Key mit 4096 Bit
Postfix nutzt Forward Secrecy bereits ohne weitere Konfiguration. Allerdings werden für den Schlüsselaustausch via Forward Secrecy geeigneten Cipher-Suiten (EDH) bereits vorberechnete DH-Schlüssel mit 2048-Bit und 512-Bit verwendet. Da der 512-Bit DH-Schlüssel bei uns niemals verwendet wird – wir nutzen keine altmodischen EXPORT-Chipher – berechnen wir nur den DH-Schlüssel mit 4096-Bit neu:
openssl dhparam -out /etc/postfix/dh_4096.pem -2 4096
Über den Parameter »smtpd_tls_dh1024_param_file« binden wir den DH-Schlüssel später in die Konfiguration ein und ersetzen damit den Standard DH-Schlüssel mit 2048 Bit.
Hinweis
Forward Secrecy bezeichnet ein kryptographisches Protokoll zum Schlüsselaustausch, das sicherstellt, dass eine früher aufgezeichnete Kommunikation später nicht rekonstruiert werden kann – auch denn nicht, wenn der damals verwendete (private) Schlüssel mittlerweile kompromittiert oder geknackt ist.4. TLS-Konfiguration Postfix
Damit zwei E-Mail-Server untereinander eine verschlüsselte Verbindung via TLS aufbauen können sind ein paar grundlegende Voraussetzungen zu erfüllen:
- Der versendende E-Mail-Server muss TLS anbieten bzw. unterstützen
- Der empfangende E-Mail-Server muss TLS anbieten bzw. unterstützen
- Sowohl Sender, als auch Empfänger müssen sich auf ein gemeinsames Verschlüsselungsprotokoll (Cipher-Suite) einigen
Mittlerweile bieten die meisten E-Mail-Server TLS an. In seltenen Fällen können zwei E-Mail-Server dennoch keine TLS-verschlüsselte Verbindung aufbauen, weil sie sich nicht auf ein Verschlüsselungsprotokoll einigen können. Das kommt insbesondere dann vor, wenn einer der beiden E-Mail-Server bspw. nur veraltete Cipher-Suiten wie SSLv3 anbietet, das seit Juni 2015 offiziell vom IETF (RFC 7568) als »nicht benutzbar« erklärt wurde. Daher kann bspw. folgender Fall eintreten:
- E-Mail-Server A akzeptiert lediglich TLS 1.0, TLS 1.1 und TLS 1.2 Cipher-Suiten.
- E-Mail-Server B akzeptiert lediglich SSLv3.
- Damit sind beide E-Mail-Server grundsätzlich in der Lage eine verschlüsselte Verbindung aufzubauen, können sich allerdings auf kein gemeinsames Verschlüsselungsprotokoll einigen.
- Ergebnis: Sollte einer oder beide E-Mail-Server zwingend auf eine verschlüsselte Verbindung bestehen, wird die E-Mail nicht zwischen den beiden E-Mail-Servern ausgetauscht und verworfen. In der Praxis ist dies allerdings kaum der Fall und die Verbindung zwischen den beiden E-Mail-Servern erfolgt dann mit hoher Wahrscheinlichkeit unverschlüsselt, da E-Mail-Server meist (sozusagen als Fallback) auch »zähneknirschend« unverschlüsselte Verbindungen akzeptieren.
Folgen wir also der Empfehlung des RFC 7525 so gilt:
- Implementations MUST NOT negotiate SSL version 2.
- Implementations MUST NOT negotiate SSL version 3.
- Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]; the only exception is when no higher version is available in the negotiation. (Anmerkung: Wer den PCI Data Security Standard erfüllen muss, der sollte ab dem 30. Juni 2018 kein TLS 1.0 mehr anbieten)
- Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346];the only exception is when no higher version is available in the negotiation.
- Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS.
Ideal wäre also, wenn sich E-Mail-Server bei der Aushandlung einer TLS-Verbindung auf TLS 1.2 kompatible Cipher-Suiten einigen könnten. TLS 1.1 und TLS 1.0 sollten nur dann benutzt werden, wenn TLS 1.2 nicht verfügbar ist.
Halten wir also fest: In der E-Mail-Welt sollten E-Mail-Server aktuell TLS 1.2 verwenden, TLS 1.1 und TLS 1.0 allerdings noch anbieten, falls die Gegenstelle noch kein TLS 1.2 unterstützt. Als Notlösung – wenn sich beide E-Mail-Server auf kein gemeinsames Verschlüsselungsprotokoll einigen können – sollte ein E-Mail-Server allerdings auch noch den unverschlüsselten Empfang / Versand anbieten. Das ist zwar unschön, aber in Einzelfällen leider noch nicht zu vermeiden.
Hinweis
Ein Grundwissen für die Postfix-Administration wird vorausgesetzt. Ihr solltet wissen was ihr tut und die nachfolgenden Vorschläge nicht einfach 1:1 übernehmen, sondern an eure Umgebung / Bedürfnisse anpassen.4.1 Allgemeine TLS-Einstellungen
/etc/postfix/main.cf
# Path CAfile smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt # TLS RSA public / private keys smtpd_tls_cert_file = /etc/ssl/certs/mail.kuketz.de.cer smtpd_tls_key_file = /etc/ssl/private/mail.kuketz.de.key # TLS ECDSA public / private keys smtpd_tls_eccert_file = /etc/ssl/certs/mail.kuketz.de_ecc.cer smtpd_tls_eckey_file = /etc/ssl/private/mail.kuketz.de_ecc.key # TLS supported cipherlist tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH # Prefer the servers order of ciphers over clients tls_preempt_cipherlist = yes # EDH-Parameter smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem # Server security grade for ephemeral elliptic-curve Diffie-Hellman (EECDH) key exchange smtpd_tls_eecdh_grade = ultra # No SSL compression tls_ssl_options = NO_COMPRESSION
Eine kurze Erklärung zu den Parametern:
- smtp_tls_CAfile: Gibt den Ort einer Datei an, in der sich eine Referenz aller CAs befindet. Wenn der Parameter nicht korrekt gesetzt wird, dann werden beim Senden von E-Mails die Nachricht »Untrusted TLS connection established« protokolliert. Mit der korrekten Einstellung von smtp_tls_CAfile und vorausgesetzt, dass das Zertifikat des Empfänger-Servers durch eine CA ausgestellt wurde, der in »ca-certificates.crt« enthalten ist, ändert sich der Logging-Eintrag zu »Trusted TLS connection established«.
- smtpd_tls_[cert|key]_file: Angabe des Pfads zum RSA-Zertifikat und dem dazu passenden privaten Schlüssel.
- smtpd_tls_[eecert|eckey]_file: Angabe des Pfads zum ECDSA-Zertifikat und dem dazu passenden privaten Schlüssel.
- tls_[low|medium|high]_cipherlist: Der Parameter definiert, welche Cipher-Suiten der Server unterstützt. In der Postfix man 5 postconf finden wir den Hinweis: »You are strongly encouraged to not change this setting.« Meiner Ansicht nach sollte dort stehen: »You SHOULD consider to change this setting, otherwhise anonymous aNULL ciphers are supported«. Unter Ziffer 5.1 werde ich das nochmal ausführlich aufgreifen.
- tls_preempt_cipherlist: Die Reihenfolge der vom E-Mail-Server angebotenen Cipher-Suiten wird gegenüber dem Client (Sender E-Mail-Server) bevorzugt.
- smtdp_tls_dh1024_param_file: Bei der Verwendung von Diffie-Hellmann (EDH) kompatiblen Cipher-Suiten (für Forward Secrecy) verweisen wir auf unseren generierten DH-Key mit 4096 Bit.
- smtpd_tls_eecdh_grade: Bei der Verwendung von EECDH-kompatiblen Cipher-Suiten (für Forward Secrecy) verwenden wir eine P-384 (secp384r1) elliptische Kurve mit einer Größe von 384 Bit.
- tls_ssl_options: Aus Sicherheitsgründen (BREACH, CRIME) wird die SSL-Kompression deaktiviert.
4.2 Verschlüsselung beim Versenden
/etc/postfix/main.cf
# TLS protocols accepted by Postfix (Outgoing) smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 # TLS supported ciphers (Outgoing) smtp_tls_ciphers = high smtp_tls_mandatory_ciphers = high # Uses TLS if this is supported by the receiving SMTP server smtp_tls_security_level = may # Enable additional Postfix SMTP server logging of TLS activity smtp_tls_loglevel = 1
Eine kurze Erklärung zu den Parametern:
- smtp_tls_protocols: Liste der TLS-Protokolle, die Postfix bei ausgehenden (Outgoing), opportunistischen TLS-Verbindungen (bspw. smtp_tls_security_level = may) ausschließt bzw. einbezieht. SSLv2 und auch SSLv3 werden ausgeschlossen. TLS 1.0, TLS 1.1 und TLS 1.2 Cipher-Suiten werden hingegen unterstützt. Diese müssen nicht explizit angegeben werden.
- smtp_tls_mandatory_protocols: Liste der TLS-Protokolle, die Postfix bei ausgehenden (Outgoing), obligatorischen TLS-Verbindungen (bspw. smtp_tls_security_level =encrypt) ausschließt bzw. einbezieht. SSLv2 und auch SSLv3 werden ausgeschlossen. TLS 1.0, TLS 1.1 und TLS 1.2 Cipher-Suiten werden hingegen unterstützt. Diese müssen nicht explizit angegeben werden.
- smtp_tls_ciphers: Minimale Cipher-Suiten, die Postfix bei ausgehenden, opportunistischen TLS-Verbindungen verwenden wird. Wir referenzieren auf den zuvor definierten Parameter »tls_high_cipherlist«.
- smtp_tls_mandatory_ciphers: Minimale Cipher-Suiten, die Postfix bei ausgehenden, obligatorischen TLS-Verbindungen verwenden wird. Wir referenzieren auf den zuvor definierten Parameter »tls_high_cipherlist«.
- smtp_tls_loglevel: Das Log-Level gibt an, wie ausführlich der TLS-Handshake bzw. die ausgehende TLS-Verbindung protokolliert werden sollen. Ein Log-Level größer 0 hilft bei der Fehlersuche.
Beispiel smtp_tls_loglevel = 1:
Feb 27 12:31:16 mail postfix/smtp[19312]: Trusted TLS connection established to mx03.posteo.de[185.67.36.63]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
4.3 Verschlüsselung beim Empfangen
/etc/postfix/main.cf
# TLS protocols accepted by Postfix (Incoming) smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 # TLS supported ciphers (Incoming) smtpd_tls_ciphers = high smtpd_tls_mandatory_ciphers = high # Uses TLS if this is supported by the sending SMTP server, otherwise use plaintext smtpd_tls_security_level = may # Enable additional Postfix SMTP server logging of TLS activity smtpd_tls_loglevel = 1
Eine kurze Erklärung zu den Parametern:
- smtpd_tls_protocols: Liste der TLS-Protokolle, die Postfix bei eingehenden (Incoming), opportunistischen TLS-Verbindungen (bspw. smtpd_tls_security_level = may) ausschließt bzw. einbezieht. SSLv2 und auch SSLv3 werden ausgeschlossen. TLS 1.0, TLS 1.1 und TLS 1.2 Cipher-Suiten werden hingegen unterstützt. Diese müssen nicht explizit angegeben werden.
- smtpd_tls_mandatory_protocols: Liste der TLS-Protokolle, die Postfix bei eingehenden (Incoming), obligatorischen TLS-Verbindungen (bspw. smtpd_tls_security_level =encrypt) ausschließt bzw. einbezieht. SSLv2 und auch SSLv3 werden ausgeschlossen. TLS 1.0, TLS 1.1 und TLS 1.2 Cipher-Suiten werden hingegen unterstützt. Diese müssen nicht explizit angegeben werden.
- smtpd_tls_ciphers: Minimale Cipher-Suiten, die Postfix bei eingehenden, opportunistischen TLS-Verbindungen verwenden wird. Wir referenzieren auf den zuvor definierten Parameter »tls_high_cipherlist«.
- smtpd_tls_mandatory_ciphers: Minimale Cipher-Suiten, die Postfix bei eingehenden, obligatorischen TLS-Verbindungen verwenden wird. Wir referenzieren auf den zuvor definierten Parameter »tls_high_cipherlist«.
- smtpd_tls_loglevel: Das Log-Level gibt an, wie ausführlich der TLS-Handshake bzw. die eingehende TLS-Verbindung protokolliert werden sollen. Ein Log-Level größer 0 hilft bei der Fehlersuche.
4.4 Parallelbetrieb ECDSA- / RSA-Keys
Seit der Version 2.6 unterstützt Postfix ECDSA-Zertifikate. Dem ein oder anderen ist es vermutlich schon aufgefallen, denn sowohl RSA- als auch ECDSA-Zertifikate sind bereits in der Konfiguration vermerkt:
/etc/postfix/main.cf
# TLS RSA public / private keys smtpd_tls_cert_file = /etc/ssl/certs/mail.kuketz.de.cer smtpd_tls_key_file = /etc/ssl/private/mail.kuketz.de.key # TLS ECDSA public / private keys smtpd_tls_eccert_file = /etc/ssl/certs/mail.kuketz.de_ecc.cer smtpd_tls_eckey_file = /etc/ssl/private/mail.kuketz.de_ecc.key
Beide Zertifikate können gleichzeitig konfiguriert werden. In diesem Fall bestimmt die mit dem anderen E-Mail-Server ausgehandelte Cipher-Suite, welches Zertifikat verwendet wird.
Falls ein andere E-Mail-Server ebenfalls ECDSA-Zertifikate unterstützt sieht ein erfolgreicher TLS-Handshake in der Log-Datei folgendermaßen aus:
Feb 23 16:09:26 mail postfix/smtpd[14326]: Anonymous TLS connection established from mail.volkswohnung.com[109.109.203.162]: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
5. Postfix: Angebotene Cipher-Suites testen
Wer kennt das Problem nicht? Innerhalb von nginx oder Apache hat man neue Cipher-Suites auf die Empfehlung eines Guides hin konfiguriert. Diese Cipher-Suites gilt es nun zu verifizieren. Dafür eignen sich diverse Online-Services wie bspw.:
Für E-Mail-Server werden hingegen weit weniger Online-Services zum Testen der konfigurierten SMTP-Cipher-Suiten angeboten:
- CryptCheck [Domainname + SMTP auswählen]
- High-Tech Bridge [Domainname + Portangabe: bspw.: mail.kuketz.de:25]
Voraussetzung für einen aussagekräftigen Test der vom E-Mail-Server angebotenen Cipher-Suiten ist eine vollständige Überprüfung. Persönlich favorisiere ich daher das Shell-Skript testssl.sh. Der große Vorteil von diesem Skript: Es integriert in seinen Test sowohl veraltete bzw. alte OpenSSL-Bibliotheken, sowie brandneue OpenSSL-Bibliotheken mit Entwicklerstatus. Ihr könnt also die gesamte Bandbreite an verfügbaren OpenSSL-Cipher-Suiten abdecken, ohne auf unterschiedliche OpenSSL-Bibliotheken linken zu müssen.
Weiterhin ist testssl.sh in der Lage die angebotenen TLS-Cipher-Suiten in favorisierter Reihenfolge auszugeben. Auch das ist für mich ein wichtiges Kriterium, das später in der Bewertung herangezogen werden kann.
5.1 testssl.sh: Standard-Konfiguration von Postfix
In der Standard-Konfiguration unterstützt Postfix keine TLS-verschlüsselte Kommunikation und versendet bzw. empfängt E-Mails über einen unverschlüsselten Kanal. Erst das Setzen von
smtp_tls_security_level = may
bzw.
smtpd_tls_security_level = may
weist Postfix an, nach Möglichkeit via TLS zu kommunizieren. Weiterhin wird Postfix 3.1.6 mit folgendem Wert für den Parameter »tls_high_cipherlist« ausgeliefert:
postconf -d | grep tls_high_cipherlist aNULL:-aNULL:HIGH:@STRENGTH
Starten wir einen Testlauf auf diese Standard-Konfiguration mit testssl.sh:
./testssl.sh -E -t=smtp mail.kuketz.de:25
Das Ergebnis: Postfix bietet sogenannte »Anonymous NULL Ciphers (no authentication)« für den Aufbau einer TLS-verschlüsselten Verbindung an. Dazu zählt bspw. die Cipher-Suite »ADH-AES256-GCM-SHA384«. Das OpenSSL-Wiki sagt zu diesen aNULL Ciphers:
The cipher suites offering no authentication. This is currently the anonymous DH algorithms and anonymous ECDH algorithms. These cipher suites are vulnerable to a „man in the middle“ attack and so their use is normally discouraged.
Was sagt das Postfix Handbuch dazu?
By default anonymous ciphers are enabled. They are automatically disabled when remote SMTP client certificates are requested. If clients are expected to always verify the Postfix SMTP server certificate you may want to disable anonymous ciphers by setting „smtpd_tls_mandatory_exclude_ciphers = aNULL“ or „smtpd_tls_exclude_ciphers = aNULL“, as appropriate. One can’t force a remote SMTP client to check the server certificate, so excluding anonymous ciphers is generally unnecessary.
Wir haben also folgende zwei Optionen, um aNULL-Cipher auszuschließen:
- Wir exkludieren die aNULL-Cipher über den dazu gehörigen Postfix »smtp[d]_tls_[mandatory]_exclude_ciphers« Befehl
- oder zum Zweck der besseren Übersichtlichkeit können wir die aNULL-Cipher auch direkt im Parameter »tls_high_cipherlist« ausschließen.
5.2 testssl.sh: Vorgeschlagene Konfiguration
Wiederholen wir den Test mit testssl.sh, wenn wir den Parameter entsprechend meinem Vorschlag angepasst haben:
# TLS supported cipherlist tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
Wir schließen explizit aus – OpenSSL Referenz:
- aNULL: the cipher suites offering no authentication. (Damit schließen wir ebenfalls anonyme Cipher-Suiten aus)
- eNULL: the „NULL“ ciphers that is those offering no encryption
- CAMELLIA: Weitläufig wenig bis keine Unterstützung bzw. Angebot.
Folgende TLS-Cipher-Suiten bietet Postfix (in favorisierter Reihenfolge) anschließend an:
Cipher order TLSv1: ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA AES128-SHA TLSv1.1: ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA AES128-SHA TLSv1.2: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-CCM8 ECDHE-ECDSA-AES256-CCM DHE-RSA-AES256-CCM8 DHE-RSA-AES256-CCM ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES256-SHA256 ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA AES256-GCM-SHA384 AES256-CCM8 AES256-CCM AES256-SHA256 AES256-SHA ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-CCM8 ECDHE-ECDSA-AES128-CCM DHE-RSA-AES128-CCM8 DHE-RSA-AES128-CCM ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA
Das Ergebnis ist vergleichbar mit der TLS-Cipher-Suite Konfiguration von mailbox.org – bei unserem Setup werden allerdings noch die ECDHE_ECDSA- (Ephemeral ECDH with ECDSA signatures) und ChaCha20-Poly1305-Cipher (eine Stream-Cipher) ergänzt.
Hinweis
Je nach verwendeter OpenSSL-Bibliothek bzw. Binary kann das Ergebnis abweichen, wenn ihr den Parameter »tls_high_cipherlist« wie vorgeschlagen setzt. Es könnte also sein, dass ihr noch weitere Ausschlüsse (bspw. irgendwann !TLS1.0) vornehmen müsst. Verifiziert eure angebotenen Cipher-Suiten daher regelmäßig – insbesondere dann, wenn ein OpenSSL-Update ansteht oder die Standards angepasst werden und bspw. TLS 1.0 deaktiviert werden sollte.Du kannst den Blog aktiv unterstützen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
5.3 Streitpunkt Cipher-Suiten
Bei den vom E-Mail-Server angebotenen Cipher-Suiten steckt man regelmäßig in einem Dilemma: Strebt man eine größtmögliche Abwärtskompatibilität an oder sollten unsichere Cipher-Suiten die bspw. mit RC4 und MD5 arbeiten nicht doch besser deaktiviert werden?
Die Frage bezüglich RC4 und MD5 stellt sich bei einer halbwegs aktuellen Version von OpenSSL (1.1.0f ) nicht mehr:
openssl ciphers
Sowohl RC4 als auch MD5-Cipher Suiten wurden vollständig entfernt. Konsequent und richtig ist es daher, als unsicher geltende Cipher-Suiten von einer Konfiguration auszuschließen, auch wenn die Abwärtskompatibilität womöglich darunter leidet – im schlimmsten Fall wird eine E-Mail dann unverschlüsselt übermittelt. Aber seien wir ehrlich: Irgendwann muss man sich von veralteten Standards einfach verabschieden – Abwärtskompatibilität hin oder her.
6. Fazit
Es ist geschafft: Wir haben nun eine saubere, abwärtskompatible aber dennoch moderne TLS-Konfiguration für Postfix erstellt. Die »neuen« ECDSA-Zertifikate werden bisher nur von wenigen E-Mail-Servern unterstützt – allerdings sollte sich das demnächst ändern. Dieses insbesondere deshalb, weil Postfix den Parallelbetrieb von ECDSA- und RSA-Zertifikaten unterstützt.
Für eine Postfix TLS-Konfiguration gibt es noch weitere, sinnvolle Parameter, mit denen ihr euch auseinandersetzen könnt. Zusätzlich zu den oben genannten habe ich bspw. den Parameter »smtpd_tls_received_header« auf »yes« gestellt. Informationen über das Protokoll und die verwendeten Cipher-Suiten werden beim Empfang von E-Mails dann direkt in den Message-Header geschrieben. Ihr könnt dann direkt über den E-Mail-Client herausfinden, ob eine E-Mail verschlüsselt zugestellt wurde.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
3 Ergänzungen zu “Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten”
Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Hallo Mike,
danke für den tollen Artikel. Persönlich nutze ich ja Mailcow als Lösung, da werde ich das direkt mal ein bisschen abgleichen.
Zudem noch als Hinweis, die beiden CryptCheck Links verweisen bei mir auf mail-tester.de. Gewollt?
Gruß Felix
Danke Felix. Korrigiert.
Hallo,
was spricht eigentlich dagegen die neue Standard Cipherliste von Dovecot zu verwenden?
Dies würde auch ausschließlich PFS anbieten. Oder hast du die obige Kombination aus Kompatibilitätsgründen zu anderen Servern gewählt?
Christian