mailcow Ciphers verstärken nicht merh aktuell

Hindin-The-G

Hallo zusammen,

ich teste von Zeit zu Zeit meinen Server über internet.nl. Dabei tauchen nun zwei Fehler auf:

Verdict:
At least one of your mail servers supports one or more insufficiently secure hash functions for key exchange.

Technical details:
Mail server (MX) Outdated hash function
mail.xxxxxx.yyyy. SHA1
Test explanation:
We check if your receiving mail servers (MX) support secure hash functions to create the digital signature during key exchange.

The receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

Note that this subtest is only relevant for TLS 1.2. The supported hash functions can be configured via a separate TLS setting (e.g. SignatureAlgorithms in OpenSSL) and are not part of the cipher suite configuration.

For more details on the status of SHA-1 and MD5, see RFC 9155. We do not test for MD5 because it is only supported by very outdated software.

See ‘Transport Layer Security (TLS), Security guidelines version 2025-05’ from NCSC-NL, paragraph 3.3.5.

Security level of hash functions for key exchange

Good: SHA-256, SHA-384, SHA-512
Phase out: SHA-224 (rarely used)
Insufficient: SHA-1, MD5

Sowie:

Verdict:
The public key of at least one of your mail server certificates is based on a signing algorithm with parameters that should be phased out as they are weaker, although you might still use them if absolutely needed. In a future update, they will likely become insufficient.

Technical details:
Mail server (MX) Outdated signature parameter
mail.xxxxxx.yyyy. R13: RSAPublicKey-2048
… phase out
Test explanation:
We check if the public key of your mail server certificate and every intermediate certificate is based on a secure signing algorithm with secure parameters.

The verification of certificates makes use of digital signatures. The public key of a certificate can be used to verify that a signature was created using the corresponding private key.

Signing algorithm: The signing algorithm is determined when generating the certificate. A certificate can only contain one signing algorithm. It is possible to configure multiple certificates on a server to support more than one algorithm. Only the signing algorithms ECDSA, RSA and EdDSA are considered sufficiently secure. EdDSA is actually rarely, if ever, used. All mentioned algorithms are vulnerable to the quantum threat. They offer sufficient protection for now. Quantum-safe alternatives are not yet part of the TLS standards.

Parameters: The security of ECDSA and EdDSA digital signatures depends on the chosen curve. The security of RSA is tied to the key length of the public key.

For details on the relevant certificate field name see paragraph “4.1.2.7. Subject Public Key Info” of RFC 5280.

See ‘Transport Layer Security (TLS), Security guidelines version 2025-05’ from NCSC-NL, paragraph 3.3.2

Security level of elliptic curves for ECDSA

Sufficient:

secp521r1 (rarely used)
secp384r1
secp256r1
x448
x25519
brainpoolP512r1 (rarely used)
brainpoolP384r1 (idem)
brainpoolP256r1 (idem)
Phase out:

secp224r1
Insufficient:

Other curves
Security level of length of RSA keys

Sufficient: At least 3072 bit
Phase out: 2048 – 3071 bit
Insufficient: Less than 2048 bit
Security level of Edwards curves for EdDSA (rarely used)

Sufficient:

Ed448
Ed25519
Insufficient:

Other curves

Dazu gab es die folgenden Support Beiträge welche nicht mehr aktuell sind:
https://docs.mailcow.email/de/manual-guides/Postfix/u_e-postfix-harden_ciphers/
https://docs.mailcow.email/de/manual-guides/Dovecot/u_e-dovecot-harden_ciphers/

Kann mir jemand sagen was ich wo ändern muss damit mein Server wieder als grün angezeigt wird?

Cisco30

Hindin-The-G
hi.
I’ve opened a request on Github to improve the Mailcow encryption suite, so you can get it again
mailcow/mailcow-dockerized7208

CK_beats

Puuuh. 🤔🤔🤔🤔🤷‍♂️🤷‍♂️🤷‍♂️
Lt. internet.nl kann ich mich der Frage nur anschließen.
Sieht bei unserem System auch nicht ganz optimal aus.

Jedoch große Testsysteme wie z. B. mxtoolbox.com kommen zu einem gegenteiligen Ergebnis.
Ich habe zwar keine Verbesserung unseres Mailservers erreicht, dafür weiß ich jetzt, was ein Bimi-Logo ist 😂😂😂

CK_beats

Cisco30
Vielen Dank für das erstellen des GitHub Issues!
Ich bin gespannt, ob angepasst wird.

Hindin-The-G

Guten Morgen, ich konnte zumindest den ersten Fehler beheben. Ich bin wie folgt vorgegangen:
Datei anpassen oder erstellen:

/opt/mailcow-dockerized/data/conf/postfix/openssl.cnf

das muss rein:
openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] MinProtocol = TLSv1.2 CipherString = DEFAULT@SECLEVEL=2 #DAS IST DER FIX: SignatureAlgorithms = RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384

Dann In docker-compose.override.yml folgendes ergänzen:
services: postfix-mailcow: volumes: - ./data/conf/postfix/openssl.cnf:/etc/ssl/openssl.cnf:ro

Dann alles neu starten und danach war be mir das erste Finding gelöst.
Allerdings kann nun mein Ceph Cluster keine E-Mails mehr an Mailcow abliefern, es kommt dann folgender Fehler:

Also erhöhte Sicherheit nimmt sich dann wieder die Balance mit Produktivität.

CK_beats

Die Einstellungen sollten standardmäßig “intermediate” sein.
Servercow sollte in jedem Fall die neusten Cipher-Suites anbieten, sowie sämtliche veralteten und überholten Cipher als gesperrt abweisen.

Was zeigt es eigentlich bei https://www.ssllabs.com/ssltest/ bei Euch an?
Kann ich selbst nicht gegentesten, da hier Port 443 getestet wird und bei uns ein Reverse-Proxy antwortet.

Ganzjahresgriller

Bei mir wird A+ angezeigt, was auch immer das bedeuten mag

CK_beats

Ganzjahresgriller
Das Bedeutet “sehr gut”.
Also verwendet Ngix entweder bessere Cipher-Suites als per TLS over SMTP angeboten wird. Oder die Bewertungsmethode von internet.nl ist zu hart.

Es bringt ja (noch) nichts alleinig die modernsten Cipher anzubieten, wenn 80% der großen Mailserver noch nicht umgestellt wurden. Somit endet die Nachrichtenzustellbarkeit sehr schnell. 😅😅

mlcwuser

Bei mir auch. Aber die testen ja nur den Web Server, wo ja wiederum andere Cyphers konfiguriert sein können als für Postfix und Dovecot.

Hier trotzdem noch das Rating und die Ciphers aus dem Test von SSL Labs:

CK_beats

mlcwuser
So wird es vermutlich auch sein. Dass Ngix auf einen neuen Stand gebracht wurde, das “alte” SMTP Protokoll aber vernachlässigt.

Ganzjahresgriller

Irgendwas scheint internet.nl geändert zu haben bei mir schlägt bei den Tests der Netfilter zu und blockt deren IP. Im Log steht: 62.204.66.10 matched rule id 4 (warning: non-SMTP command from internet.nl[62.204.66.10]: GET _ HTTP_1.1)
Das hat aber schon mal sehr gut funktioniert.

esackbauer

Bitte bedenkt dass nicht alle Mail server im Internet die neuesten und besten Ciphers unterstützen. Es kann dazu führen, dass ihr nicht von bestimmten Mailservern mehr Mails empfangen oder ihnen senden könnt.
SMTP ist per se ein relativ unsicheres Protokoll, wer eine richtige Verschlüsselung verwenden will sollte PGP oder S/MIME für Ende-zu-Ende Verschlüsselung verwenden.

Becker884

@esackbauer also du sagst internet.nl übertreibt und man braucht die älteren Ciphers in Mailcow für einen reibungslosen Betrieb?
ich fände es fatal, wenn ich wichtige emails einfach nicht mehr bekommen würde, aufgrund von verbotenen älteren Ciphers.

Nichtsdestotrotz: Was ist mit dem KI Vorschlag:
data/conf/postfix/extra.cf anzupassen:

# Nur sichere Protokolle
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Ciphers einschränken (deaktiviert CBC, SHA1 und schwache Algorithmen)
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aDSS, kECDHe, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES-CBC3-SHA, CBC, SHA
smtpd_tls_ciphers = high

und
data/conf/dovecot/extra.conf

ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
ssl_prefer_server_ciphers = yes
ssl_min_protocol = TLSv1.2

Holzweg oder könnte ich so mal zum testen 100% erzwingen?

esackbauer

internet.nl sagt was best practice wäre, in einer idealen Welt…
Aber gerade im Bereich SMTP ist die Welt nicht ideal.

Wie sagt man so schön auf englisch: “You can put lipstick on a pig, it’s still a pig.”

Ich glaube es ist das Deutsche in uns, dass 100% korrektheit einfordert 😉

Ich denke die mailcow devs haben diesbezüglich schon ihre Hausaufgaben gemacht. Ich verwende seit Jahr und Tag die Ciphers so wie sie mit mailcow kommen. Gelegentlich werden sie ja angepasst.
Herumgefummel mit den Ciphers und dann mit Ausnahmen hantieren wenn was nicht klappt, das ist nicht meines.

Becker884

Ich hatte die offizielle Doku von 2024 zur Härtung gar nicht auf dem Schirm:
https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-harden_ciphers/
und
https://docs.mailcow.email/manual-guides/Dovecot/u_e-dovecot-harden_ciphers/

Wenn man die einpflegt, wird nur noch der SHA1 bemängelt.
Das hat der Kollege hier gefixt:
mailcow/mailcow-dockerized7208

Habe es so umgesetzt auf beiden Kühen 😎
Danke an rezzorix 🔝

CK_beats

Becker884
Vielen Dank für die Zusammenfassung und Link-Sammlung!
Hast Du Deine Servercows im Produktivbetrieb im Einatz?
Irgendwelche Veränderungen gemerkt bzgl. Empfang?

Becker884

Ja, allerdings kommen dort nicht so viele E-Mails rein, bisher ist mir nichts negatives aufgefallen.

KI sagt:

Wenn du diese “insufficient” Ciphers abschaltest, kann es in seltenen Fällen passieren, dass sehr alte Mailserver (die z.B. noch auf Windows Server 2008 oder uralten Linux-Distributionen laufen) keine TLS-Verbindung mehr zu dir aufbauen können. Diese würden E-Mails dann entweder im Klartext (falls erlaubt) oder gar nicht mehr zustellen.

Für den “Hausgebrauch” und moderne Kommunikation ist das Abschalten aber absolut empfehlenswert, um die 100% (und echte Sicherheit) zu erreichen.

Opportunistic TLS (STARTTLS) zwischen MTAs fällt zwar auf Plaintext zurück, wenn TLS scheitert – aber das ist kein Argument dafür, schwache Cipher anzubieten
Große Provider (Google, Microsoft, Posteo etc.) unterstützen alle modernen Cipher problemlos
Das BSI und NCSC empfehlen auch für SMTP moderne Cipher-Profile

Das Argument gilt höchstens für sehr alte Legacy-Systeme, die kaum noch im Umlauf sind.

CK_beats

Becker884
Danke für die Info!
Ich habe die Cipher Suites bei uns im Produktivbetrieb auch verändert. Bin gespannt, was passiert. Bzw. ob es Probleme gibt.
Außerdem ist mir aufgefallen, dass unser externer ITler damals bei der Installation von Mailcow die Zertifikat-Chain komplett hinterlegt hatte. Aber das R13 Zwischenzertifikat ist natürlich mittlerweile abgelaufen.

Anscheinend cached internet.nl alte Einstellungen und prüft sie nicht neu. Ich habe trotz Neustart aller Container keine Veränderung in der Bewertung. 🤔🤔🤔🤔

LS_RSA_WITH_CAMELLIA_256_CBC_SHA256	insufficient
...	TLS_RSA_WITH_CAMELLIA_256_CBC_SHA	insufficient
...	TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256	insufficient
...	TLS_RSA_WITH_CAMELLIA_128_CBC_SHA	insufficient
...	TLS_RSA_WITH_ARIA_256_GCM_SHA384	insufficient
...	TLS_RSA_WITH_ARIA_128_GCM_SHA256	insufficient
...	TLS_RSA_WITH_AES_256_GCM_SHA384	insufficient
...	TLS_RSA_WITH_AES_256_CCM_8	insufficient
...	TLS_RSA_WITH_AES_256_CCM	insufficient
...	TLS_RSA_WITH_AES_256_CBC_SHA256	insufficient
...	TLS_RSA_WITH_AES_256_CBC_SHA	insufficient
...	TLS_RSA_WITH_AES_128_GCM_SHA256	insufficient
...	TLS_RSA_WITH_AES_128_CCM_8	insufficient
...	TLS_RSA_WITH_AES_128_CCM	insufficient
...	TLS_RSA_WITH_AES_128_CBC_SHA256	insufficient
...	TLS_RSA_WITH_AES_128_CBC_SHA	insufficient
...	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	insufficient
...	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_AES_256_CCM_8	insufficient
...	TLS_DHE_RSA_WITH_AES_256_CBC_SHA	insufficient
...	TLS_DHE_RSA_WITH_AES_128_CCM_8	insufficient
...	TLS_DHE_RSA_WITH_AES_128_CBC_SHA	insufficient
...	TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384	phase out
...	TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256	phase out
...	TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384	phase out
...	TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256	phase out
...	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	phase out
...	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256	phase out
...	TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384	phase out
...	TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256	phase out
...	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	phase out
...	TLS_DHE_RSA_WITH_AES_256_CCM	phase out
...	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256	phase out
...	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	phase out
...	TLS_DHE_RSA_WITH_AES_128_CCM	phase out
...	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256	phase out

… sowie

remote.kn-koehler.de.	R13: RSAPublicKey-2048
...	phase out

Becker884

Ich habe mit internet.nl auch mehrmals rumgespielt und die Einstellungen wurde sofort richtig erkannt, kein Cache!

Was sagt denn?
docker exec $(docker ps -qf name=postfix-mailcow) postconf -h tls_high_cipherlist ?

/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 209: overriding earlier entry: smtp_tls_protocols=>=TLSv1.2 /usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 213: overriding earlier entry: smtpd_tls_protocols=>=TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

und
docker exec $(docker ps -qf name=dovecot) doveconf -n | grep ssl

CK_beats

Becker884
Vielen Dank für Deine Unterstützung!

Bei mir kommt eine völlig andere Ausgabe:

root@kn-mc01:/opt/mailcow-dockerized# docker exec $(docker ps -qf name=postfix-mailcow) postconf -h tls_high_cipherlist
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 203: overriding earlier entry: message_size_limit=104857600
aNULL:-aNULL:HIGH:@STRENGTH

Dovecot scheint zu passen:

root@kn-mc01:/opt/mailcow-dockerized# docker exec $(docker ps -qf name=dovecot) doveconf -n | grep ssl
    ssl = yes
    ssl = yes
ssl_cert = </etc/ssl/mail/cert.pem
ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:!eNULL:!3DES:!MD5:!PSK:!DSS:!RC4:!SEED:!IDEA:+HIGH:+MEDIUM
ssl_dh = # hidden, use -P to show it
ssl_key = # hidden, use -P to show it
ssl_options = no_compression no_ticket
ssl_prefer_server_ciphers = yes

Tante Edit:
Ich hätte natürlich das komplette Workaround machen sollen. Bitte um Entschuldigung.
Ausgabe nun:

root@kn-mc01:/opt/mailcow-dockerized/data/conf/clamav# docker exec $(docker ps -qf name=postfix-mailcow) postconf -h tls_high_cipherlist
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 203: overriding earlier entry: message_size_limit=104857600
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 214: overriding earlier entry: smtp_tls_protocols=>=TLSv1.2
/usr/sbin/postconf: warning: /opt/postfix/conf/main.cf, line 218: overriding earlier entry: smtpd_tls_protocols=>=TLSv1.2
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256