Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten

1. Mail Transfer Agent Postfix

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:

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.

Mitmachen ➡

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.

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

3 Ergänzungen zu “Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten”

  1. Comment Avatar Felix sagt:

    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

  2. Comment Avatar Christian sagt:

    Hallo,

    was spricht eigentlich dagegen die neue Standard Cipherliste von Dovecot zu verwenden?

    ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH

    Dies würde auch ausschließlich PFS anbieten. Oder hast du die obige Kombination aus Kompatibilitätsgründen zu anderen Servern gewählt?

    Christian

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle 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-Forum

Abschließ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.