Schwache Ciphers entfernen

Thor

Hi!

Mailcow nutzt, wie man mittels nmap feststellen kann, auch schwache Ciphers.

Die möchte ich gern entfernen.

Der Server dient im Übrigen nur als Mailserver. Die Webseite befindet sich auf einem anderen Server.

Kann mir jemand sagen, unter welchem Pfad man die Ciphers-Suites konfiguriert?

Gruß

Thor

pkernstock

Um welche Ciphers geht es konkret? Kommunikation von Clients<>Server, oder Server<>Server?

Thor

pkernstock Das sind jene, die als WEAK gekennzeichnet sind:

[TLS_DHE_RSA_WITH_AES_128_CBC_SHA] => Weak
[TLS_DHE_RSA_WITH_AES_128_CBC_SHA256] => Weak
[TLS_DHE_RSA_WITH_AES_256_CBC_SHA] => Weak
[TLS_DHE_RSA_WITH_AES_256_CBC_SHA256] => Weak
[TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA] => Weak
[TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
[TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA] => Weak
[TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256] => Weak
[TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] => Weak
[TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] => Weak
[TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA] => Weak
[TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384] => Weak
[TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
[TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384] => Weak
[TLS_RSA_WITH_AES_128_CBC_SHA] => Weak
[TLS_RSA_WITH_AES_128_CBC_SHA256] => Weak
[TLS_RSA_WITH_AES_128_CCM] => Weak
[TLS_RSA_WITH_AES_128_CCM_8] => Weak
[TLS_RSA_WITH_AES_128_GCM_SHA256] => Weak
[TLS_RSA_WITH_AES_256_CBC_SHA] => Weak
[TLS_RSA_WITH_AES_256_CBC_SHA256] => Weak
[TLS_RSA_WITH_AES_256_CCM] => Weak
[TLS_RSA_WITH_AES_256_CCM_8] => Weak
[TLS_RSA_WITH_AES_256_GCM_SHA384] => Weak
[TLS_RSA_WITH_ARIA_128_GCM_SHA256] => Weak
[TLS_RSA_WITH_ARIA_256_GCM_SHA384] => Weak
[TLS_RSA_WITH_CAMELLIA_128_CBC_SHA] => Weak
[TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
[TLS_RSA_WITH_CAMELLIA_256_CBC_SHA] => Weak
[TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256] => Weak

esackbauer

Thor
Für welche Kommunikation? Client - Mailcow, oder für andere (internet) mailserver <–> mallcow

Thor

esackbauer

Es geht um eine Analyse-Software, die online Server auf ihre Protokolle und Cipher-Suites hin untersucht.

Dort gibt man die Domain wie beispielsweise: meine-seite.de an und startet den Prozess.

Das Script liest aus dem DNS den/die Mailserver aus. Zum Beispiel: mail.meine-seite.de. Auf diesem Weg wird geprüft, welche Protokolle (TLSv1.3, etc…) und welche Ciphers verwandt werden. Aus diesem Prozess stammt die Auflistung, die ich oben gezeigt habe.

Also irgendwo in der Konfiguration müssen diese Ciphers gesetzt sein. Und dort möchte ich die als schwach gekennzeichneten entfernen.

esackbauer

Ok, die untersucht also die Kommunikation die andere Mailserver betrifft.
Darf ich fragen warum du die schwachen entfernen willst? Es wird danach unter Umständen mancher andere Mailserver keine Mails mehr zu deinem Mailcow zustellen können oder du nicht mehr zu einem anderen senden können.
Es gibt nämlich keine Verpflichtung bestimmte Cipher Suites zu verwenden.

Thor

esackbauer Ja, in der Tat ist das so. Man verzichtet darauf, dass jemand mit einem alten Iphone 4 oder so noch Mails zustellen kann. Aber man sichert damit auch sein System ab. Irgendwann gehören nämlich die schwachen Ciphers zu den gebrochenen. Ich habe einige Mailserver geprüft, die tatsächlich nur sichere und empfohlene Ciphers verwenden. Und die von Unternehmen, die sicherlich keine Kunden aussperren möchten. Es gibt ein Für und Wider. Ich möchte sie aber gern deaktivieren.

Ich habe das auch auf dem Webserver so gemacht. Allerdings nutze ich da den Apache und konnte das darauf ziemlich einfach umsetzen.

esackbauer

Thor Aber man sichert damit auch sein System ab.

SMTP ist als ganzes unsicher und wird nie sicher sein. Das muss man mal akzeptieren. Dafür trägt es zuviel Altlasten herum.

Man kann nämlich einen Fallback auf unverschlüsselte Kommunikation erzwingen. Klar, man kann schwache und unverschlüsselte Mails ablehnen, dann muss man sich aber nicht wundern wenn dann wie hier letztens jemand geschrieben hat er bestimmte Nachrichten von seiner Bank nicht mehr erhalten kann.
Ich empfehle daher die Verschlüsselung für bestimmte Absender.Domains (von denen man sicher weiss dass sie TLS 1.3 unterstützn wie outlook.com, gmail.com etc) in Mailcow bei den TLS-Richtlinien auf TLS 1.3 Version zu konfigurieren, damit schliesst man automatisch die schwachen Ciphers aus. Aber dann muss man prüfen ob die Kommunikation einwandfrei funktioniert.

https ist etwas anderes als SMTP. https Verbindungen sind von vorneherein TLS Verbindungen (SMTP fängt immer unverschlüsselt an), und besser standardisiert. Da macht es Sinn.

Thor

esackbauer Das Problem ist, dass der Web- und der Mailserver als Vorzeigemodelle dienen. Deshalb dürfen wegen der Glaubwürdigkeit weder schwache noch gebrochene Schlüssel vorhanden sein.

Kannst du mir trotz deiner Bedenken sagen, in welcher Konfigurationsdatei nebst Pfad man die schwachen Ciphers deaktiviert?

Was ich komisch finden, ist, dass man unter Mailcow-Dockerized einige conf-Files findet, in denen sich Pfade befinden, die gar nicht existent sind.

So gibt es beispielsweise bei mir unter /etc/ssl/ gar keinen Unterordner mit dem Namen “mail”.

Bin ich gespannt, wo sich die Konfig befindet.

esackbauer

https://www.postfix.org/TLS_README.html#server_cipher
Leg eine extra.cf an und schreib dort die entsprechenden parameter rein, das ist der einzige Weg der verhindert dass ein Mailcow updates deine Config überschreibt:
https://docs.mailcow.email/manual-guides/Postfix/u_e-postfix-extra_cf/

Thor

esackbauer Danke!

Unter dem Pfad existiert die Datei (extra.cf) bereits mit dem Inhalt “myhostname = mail.meine-seite.de”

Ich habe nun etwas experimentiert. Wenn ich alle schwachen Ciphers entferne, kommen interessanter Weise auch jede Menge unsichere (insecure) hinzu:

smtpd_tls_exclude_ciphers = TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA256:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_128_CCM:TLS_RSA_WITH_AES_128_CCM_8:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_AES_256_CCM:TLS_RSA_WITH_AES_256_CCM_8:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_ARIA_128_GCM_SHA256:TLS_RSA_WITH_ARIA_256_GCM_SHA384:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256

Für den zweiten Test habe ich: “smtpd_tls_mandatory_ciphers” hinzugefügt aber trotzdem wieder schwache Ciphers darunter.

Für einen Tipp wäre ich nochmal dankbar. Ansonsten hast du mir schon einen guten Ansatz geliefert.

Gruß Thor

Meine extra.cf

TLS-Protokolle: Erlaube nur TLSv1.2 und TLSv1.3

smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

Cipher-Suiten: Verwende nur starke Cipher-Suiten

smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high

Ausschluss unsicherer Cipher-Suiten

smtpd_tls_exclude_ciphers = aNULL, MD5

Verschlüsselte TLS-Verbindungen erzwingen

smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_exclude_ciphers = aNULL, MD5

Cipher-Suiten Liste für hohe Sicherheit

tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:TLS_AES_256_GCM_SHA384:ECDHE-RSA-CHACHA20-POLY1305:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLS_AES_128_GCM_SHA256

Protokollierungslevel für TLS

smtpd_tls_loglevel = 1

TLS-Session-Cache für bessere Leistung

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

Verhindere TLS-Downgrade-Angriffe

tls_preempt_cipherlist = yes

Erzwinge TLS-Authentifizierung für SMTP-Clients

smtpd_tls_auth_only = yes

Verwende ECDHE für Elliptische Kurven, um Sicherheit zu verbessern

smtpd_tls_eecdh_grade = strong

###

Trotz dessen sind noch schwache Ciphers dabei:

        [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384] => Secure
        [TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256] => Secure
        [TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] => Secure
        [TLS_AKE_WITH_AES_256_GCM_SHA384] => Secure
        [TLS_AKE_WITH_CHACHA20_POLY1305_SHA256] => Secure
        [TLS_AKE_WITH_AES_128_GCM_SHA256] => Secure
        [TLS_DHE_RSA_WITH_AES_256_GCM_SHA384] => Secure
        [TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256] => Secure
        [TLS_DHE_RSA_WITH_AES_256_CCM] => Secure
        [TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384] => Secure
        [TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384] => Secure
        [TLS_DHE_RSA_WITH_AES_128_GCM_SHA256] => Secure
        [TLS_DHE_RSA_WITH_AES_128_CCM] => Secure
        [TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256] => Secure
        [TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256] => Secure
        [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384] => Weak
        [TLS_DHE_RSA_WITH_AES_256_CBC_SHA256] => Weak
        [TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384] => Weak
        [TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256] => Weak
        [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] => Weak
        [TLS_DHE_RSA_WITH_AES_128_CBC_SHA256] => Weak
        [TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
        [TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
        [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA] => Weak
        [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] => Weak
        [TLS_RSA_WITH_AES_256_GCM_SHA384] => Weak
        [TLS_RSA_WITH_AES_256_CCM] => Weak
        [TLS_RSA_WITH_ARIA_256_GCM_SHA384] => Weak
        [TLS_RSA_WITH_AES_128_GCM_SHA256] => Weak
        [TLS_RSA_WITH_AES_128_CCM] => Weak
        [TLS_RSA_WITH_ARIA_128_GCM_SHA256] => Weak
        [TLS_RSA_WITH_AES_256_CBC_SHA256] => Weak
        [TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256] => Weak
        [TLS_RSA_WITH_AES_128_CBC_SHA256] => Weak
        [TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak

Thor

Ich habe versucht, die extra.cf zu konfigurieren. Testhalber sollte es so sein, dass sie lediglich TLSv1.3 und die entsprechenden Cipher-Suites zulässt.

Nach unzähligen Versuchen mit nahezu identischen mangelhaften Ergebnissen habe ich zuletzt das versucht:

`myhostname = mail.meine-seite.de

Erlauben nur TLSv1.3

smtpd_tls_protocols = TLSv1.3

Zwingend erforderliche Cipher-Suiten

smtpd_tls_mandatory_ciphers = high

Cipher-Liste für TLSv1.3, nur sichere Cipher-Suiten erlauben

tls_high_cipherlist = TLS_AES_128_GCM_SHA256`

Ich betone nochmal, es handelt sich nur um einen Test!

Ziel ist, nur TLSv1.3 und diese eine Cipher zu zulassen. Im produktiven Einsatz möchte ich TLSv1.3 und TLSv1.2 nebst sicherer Ciphers verwenden.

Trotz dieser Vorgaben in der extra.cf spuckt die Analyse auch schwache Ciphers aus.

        [TLS_DHE_RSA_WITH_AES_128_CBC_SHA256] => Weak
        [TLS_DHE_RSA_WITH_AES_128_CCM] => Secure
        [TLS_DHE_RSA_WITH_AES_128_GCM_SHA256] => Secure
        [TLS_DHE_RSA_WITH_AES_256_CBC_SHA256] => Weak
        [TLS_DHE_RSA_WITH_AES_256_CCM] => Secure
        [TLS_DHE_RSA_WITH_AES_256_GCM_SHA384] => Secure
        [TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256] => Secure
        [TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384] => Secure
        [TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
        [TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256] => Weak
        [TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256] => Secure
        [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] => Weak
        [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] => Weak
        [TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] => Secure
        [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA] => Weak
        [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384] => Weak
        [TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384] => Secure
        [TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256] => Secure
        [TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384] => Secure
        [TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
        [TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384] => Weak
        [TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256] => Secure
        [TLS_RSA_WITH_AES_128_CBC_SHA256] => Weak
        [TLS_RSA_WITH_AES_128_CCM] => Weak
        [TLS_RSA_WITH_AES_128_GCM_SHA256] => Weak
        [TLS_RSA_WITH_AES_256_CBC_SHA256] => Weak
        [TLS_RSA_WITH_AES_256_CCM] => Weak
        [TLS_RSA_WITH_AES_256_GCM_SHA384] => Weak
        [TLS_RSA_WITH_ARIA_128_GCM_SHA256] => Weak
        [TLS_RSA_WITH_ARIA_256_GCM_SHA384] => Weak
        [TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256] => Weak
        [TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256] => Weak
        [TLS_AKE_WITH_AES_256_GCM_SHA384] => Secure
        [TLS_AKE_WITH_CHACHA20_POLY1305_SHA256] => Secure
        [TLS_AKE_WITH_AES_128_GCM_SHA256] => Secure

Dass die erste Cipher tatsächlich schwach ist, sieht man hier:

https://ciphersuite.info/cs/TLS_DHE_RSA_WITH_AES_128_CBC_SHA256/

Ich hatte zwecks Tests auch verschiedene andere Konfigurationen in der extra.cf probiert. Unter den Ergebnissen waren stets schwache Ciphers aufgetaucht. Das erschließt sich mir überhaupt nicht.

Und selbstverständlich habe ich nach jeder Änderung den Docker-Container neu gestartet, womit auch die Änderungen von Postfix übernommen worden sind.

Meine Frage an euch ist nun, gibt es eine Konfiguration für extra.cf, in der man entweder tatsächlich nur die sicheren Ciphers bekommt oder alternativ die Möglichkeit besitzt, explizit Ciphers zu deaktivieren?

Gruß Thor

DocFraggle

Thor So, ich habe das gerade mal mit meiner Testcow getestet. Wenn ich also Deine 3 Zeilen Config mit in die extra.cf vom Postfix Container packe:

smtpd_tls_protocols = TLSv1.3
smtpd_tls_mandatory_ciphers = high
tls_high_cipherlist = TLS_AES_128_GCM_SHA256

bekomme ich nach Neustart nur noch diese 3 Cipher angezeigt:

# nmap -sV --script ssl-enum-ciphers -p 25 mail.domain.tld

Starting Nmap 7.93 ( https://nmap.org ) at 2024-10-21 14:19 CEST
Nmap scan report for mail.domain.tld (XXXXXXXXX)
Host is up (0.0088s latency).
rDNS record for REDACTED

PORT     STATE SERVICE VERSION
25/tcp open  smtp    Postfix smtpd
| ssl-enum-ciphers: 
|   TLSv1.3: 
|     ciphers: 
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A

Warum 3 sagst Du, wenn doch nur einer definiert ist? Das ist eine Eigenart von TLS 1.3, die drei Ciphers sind immer aktiviert und tls_high_cipherlist hat keinerlei Auswirkungen.
Allerdings sehe ich mit dieser Config nicht die von Dir genannten Weak Cipher, die es mit TLS 1.3 afaik auch gar nicht gibt:

OpenSSL has implemented support for five TLSv1.3 ciphersuites as follows:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites

Thor

Ich finde, dass sich Postfix bezüglich der Konfiguration seltsam verhält. Entferne ich einzelne schwache Ciphers, tauchen die in der Konfiguration nicht mehr auf, werden dann aber durch andere schwache ersetzt.

Hat man schließlich alle schwachen notiert, wird das ignoriert.

Diese Ausschließung habe ich in die extra.cf geschrieben:

smtpd_tls_exclude_ciphers = ECDHE-RSA-RC4-SHA, RC4, aNULL, DES-CBC3-SHA, ECDHE-RSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES256-SHA, ECDHE-RSA-AES128-SHA, AES256-SHA256, AES128-SHA256, DHE-RSA-AES128-SHA, DHE-RSA-AES256-SHA, AES128-SHA, AES256-SHA, CAMELLIA128-SHA, CAMELLIA256-SHA, DHE-RSA-AES256-SHA256, DHE-RSA-CAMELLIA256-SHA, AES256-GCM-SHA384, AES256-CCM8, AES256-CCM, ARIA256-GCM-SHA384, DHE-RSA-AES128-SHA256, DHE-RSA-CAMELLIA128-SHA, AES128-GCM-SHA256, AES128-CCM8, AES128-CCM, ARIA128-GCM-SHA256, ECDHE-RSA-AES256-SHA384, DHE-RSA-AES256-SHA256, ECDHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA256, ECDHE-RSA-AES256-SHA, ECDHE-RSA-AES128-SHA, AES256-GCM-SHA384, AES256-CCM, ARIA256-GCM-SHA384, AES128-GCM-SHA256, AES128-CCM, ARIA128-GCM-SHA256, AES256-SHA256, AES128-SHA256, DHE-RSA-AES128-SHA256, DHE-RSA-AES256-SHA256, ECDHE-RSA-AES128-SHA, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES256-SHA, ECDHE-RSA-AES256-SHA384, AES128-SHA256, AES128-CCM, AES128-GCM-SHA256, AES256-SHA256, AES256-CCM, AES256-GCM-SHA384, ARIA128-GCM-SHA256, ARIA256-GCM-SHA384

Hat noch jemand eine Idee, wie man es schafft, alle schwachen Ciphers aus Postfix zu verbannen?

DerLinkman

Jemand hat im GH folgenden PR gestellt:

mailcow/mailcow-dockerized5923

Den werden wir aber vermutlich nicht adaptieren. Weil wie @esackbauer bereits richtig gesagt hat, mailcow auch immer noch mails von älteren Systemen zumindest empfangen soll.

Da nicht jeder Mailserver auf dem neusten Sicherheitsstand ist.

Thor

DerLinkman Hi! Es gibt dann aber ein Problem mit den TOMs, den technischen und organisatorischen Maßnahmen zum Schutz personenbezogener Daten. Jeder Unternehmer ist verpflichtet, präventive Maßnahmen zu ergreifen. Ich erstelle für Unternehmen Datenschutzanalysen und kann bestätigen, dass viele große Unternehmen ausschließlich auf sichere Ciphers setzen. Auch die wären damit konfrontiert, dass die eine oder andere Kundenmail nicht durchkommt. NIS2 regelt, dass Geschäftsführer mit Haus und Hof in der Haftung stehen, wenn es fahrlässig zur Kompromittierung kommt. Wenigstens sollte es so sein, dass der Admin die Möglichkeit besitzt, schwache Ciphers selbst entfernen zu können. Und genau das scheint nicht zu funktionieren. So, ist Mailcow leider weder datenschutzkonform noch tatsächlich sicher. Ich bitte die Macher deshalb, sich dieses Problems anzunehmen. Ich bitte, die Problematik nicht runterzuspielen.

DerLinkman

Ja das hab ich dann auch bedacht…

Ich denke es wäre dann sinnvoll die älteren bei bedarf und unter Anleitung in den Docs reaktivier bar zu machen.

Wie genau, muss ich noch überlegen.

esackbauer

Es kommt immer auch auf die Risikoeinstufung an. Die WWK Versicherung akzeptiert z.b. unverschlüsselte Mails. Sie weisen darauf hin dass personenbezogene Daten per SMIME Verschlüsselung getauscht werden sollten.
Ich kann mir nicht vorstellen, dass die “Haus und Hof” aufs Spiel setzen:
https://partnervertrieb.wwk.at/service-produkte/service-tools/dsgvo/e-mails-verschluesselung/

Thor

esackbauer Unsere Datenschutzsoftware deckt viele grobe Mängel auf. Nahezu alle Ubternehmen ob Große oder Klein sind betroffen. Auch der TüV, Banken, zahllose Anwälte und Kommunen. Sogar die Topanwälte für Datenschutz, die womöglich jeder von euch kennt, zählen dazu. Eine falsche Risikoabwägung schützt nicht vor NIS2 und der DSGVO. Die betroffenen verlassen sich auf die Expertise ihrer Datenschutzexperten. Das sind jene, die an drei Wochenenden ihren Schein gemacht haben. Glaubt mir, ich befasse mich seit 2017 mit dieser Materie. Unser Datenschutz Unternehmen hat eine eigene Software entwickelt, die solche Mängel protokolliert.

esackbauer

Warum werden dann solche Mängel nicht en gros von Abmahnanwälten ausgenutzt? Das Internet lässt sich ja super easy danach scannen.
Wie kann die Software überhaupt unterscheiden was für ein Unternehmen relevant ist und was nicht?
Wie sieht die Rechtsprechung dazu aus? Also welches Unternehmen hat wegen unsicherer Ciphers schon einmal Strafe zahlen müssen?

Thor

esackbauer Ich persönlich habe nichts gegen schwache Ciphers, um das mal kurz zu betonen. Aber unser Unternehmen erstellt nun mal diese Analysen. Da geht es um unsere Glaubwürdigkeit und unsere Vorbildfunktion. Noch wurde womöglich niemand für schwache Ciphers angezeigt. Aber wer will sich auf die Willkür der Justiz verlassen? Und NIS2 nimmt Geschäftsführer und Webmaster direkt durchschlagend in die Haftung. Ich kenne ein paar große Unternehmen, die Opfer trotz Warnung geworden sind. Aber das betraf jetzt nicht direkt die Ciphers, wohlaber Mängel der Mailserver Konfiguration. Alle, die sich hier konstruktiv beteiligt haben, spendiere ich gern eine Tiefenanalyse. Und damit kann jeder für sich selbst entscheiden, wir er das Problem aller übrigen Mängel kompensiert. Wenn ich unsere Tiefenanalyse den Verantwortlichen präsentiere, sind die oftmals fassungslos. Vor allem jene, die nach einer Attacke alles wieder aufgebaut haben und im guten Glauben waren, jetzt besser aufgestellt zu sein. Da nahezu alle von signifikanten Mängeln betroffen sind, liegt es auf der Hand, dass da das Bewusstsein fehlt. Wir haben bereits mehr als 40K an Analysen erstellt und tatsächlich noch kein einziges Unternehmen darunter gehabt, das frei von Mängeln ist. Das stellt aber keinen Freibrief dar, zumal die Palette der Mängel groß ist. Aber in letzter Zeit stelle ich fest, dass nun doch einige Hoster und große Unternehmen auf sichere Ciphers setzen.

[unknown] Wenn du eine Lösung finden kannst, wäre das wirklich toll. Unterstütze das gern mit diversen Analysen. Der Vorschlag war, unter Postfix die extra.cf zu konfigurieren. Aber das war mir nicht gelungen. Trotz scheinbar korrekter Parameter bleiben schwache Ciphers erhalten. Auch das explizite ausklammern hatte bei mir nicht funktioniert. Wer das schafft, leistet einen großen Dienst für die Community.

esackbauer

Thor Aber unser Unternehmen erstellt nun mal diese Analysen. Da geht es um unsere Glaubwürdigkeit und unsere Vorbildfunktion.

Am Ende des Tages geht es um Geld. Sowohl Eures als das eurer Kunden 😉
Wie gesagt, ich verstehe nicht warum eine große Versicherung wie eine WWK die diesbezüglich sicher nicht schlecht beraten wird, das auch noch öffentlich auf ihre Homepage stellt.
Wenn es aber noch keinen Präzedenzfall gibt, nach 7 Jahren, und noch kein Abmahnanwalt auf der Matte stand, dann scheint (zumindest für die WWK) das Problem keines zu sein.

Thor Aber das betraf jetzt nicht direkt die Ciphers, wohl aber Mängel der Mailserver Konfiguration.

Ich denke das wäre sehr interessant für alle hier, wenn du das etwas näher erläutern könntest.