Schwache Algorithmen SSL

[Gerald Galster]

>>>>> Der Test meckert nun alle "anonymous ciphers" an.
>>>>> 
>>>>> Wie ist Eure Meinung bezüglich deren Verwendung? Die Postfix Doku meint:
>>>>> 
>>>>> "There is generally no need to take these measures. Anonymous ciphers save bandwidth and TLS session cache space, if certificates are ignored, there is little point in requesting them."
>>>>> 
>>>>> eigentlich logisch. Checkt man mit dem Tool ein großes Klinikum sieht man, dass dort "anonymous ciphers" deaktiviert sind.
>>>>> 
>>>> Das Wichtigste bei Mailservern ist nach wie vor, dass E-Mails ankommen. Deswegen sind die meisten Server mit security_level=may (oder dane) konfiguriert, d.h. sie verwenden TLS wenn möglich, auch mit selbstsignierten oder abgelaufenen Zertifikaten. Das bietet zwar weniger Schutz, ist aber immer noch besser als im Klartext zu senden. Unterstüzt die Gegenseite kein TLS würde das ohnehin passieren oder die Mail käme nicht an. In sofern ist es kein Sicherheitsvorteil wenn anonymous ciphers abgeschalten sind. Weiterhin muss ein Mailserver für eingehende Mails mit verschiedenen Clients zurechtkommen. Möchte man TLS erzwingen und verifizieren, konfiguriert man das besser clientseitig (z.B verify oder dane-only für bestimmte Zieldomains).
>>>> Viele Grüße
>>>> Gerald
>>> Ich bin davon ausgegangen, dass es bei der Anfrage von Frank um TLS ausschließlich im Kontext von Client Authentifizierung, also Submission(s) - Port 587 oder 465, geht und _nicht_ um Kommunikation über SMTP Port 25.
>> Du meinst wegen smtpd_sasl_type/dovecot? Stimmt, da könntest Du Recht haben. Ich bin aufgrund des Links zu https://de.ssl-tools.net/mailservers/ nicht vom Client-Kontext ausgegangen, da man sasl eigentlich nicht mehr auf Port 25 konfiguriert und der Dienst vermutlich nicht 587/465 abfragt. Bei Submission sieht es natürlich anders aus, da sollte man auf starke Verschlüsselung setzen, damit das Passwort für die SMTP-Authentifizierung sicher bleibt.
> 
> Dann wäre es ideal, auf Port 25 Auth zu deaktivieren, dort TLS in allen gängigen, auch nicht so starken Ciphers anzubieten, im worst case fallback auf plain. MUAs über submission Port 587 und Auth Zwang, starke Ciphers, kein plain.

Aus meiner Sicht ist das momentan die beste Lösung.


> Prüfe ich per telnet auf Port 25, bekomme ich
> 
> 250-PIPELINING
> 250-SIZE 15000000
> 250-ETRN
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN

Wenn smtpd_tls_auth_only = yes konfiguriert ist, wird 250-AUTH erst ausgegeben wenn die SSL-Verbindung besteht:

openssl s_client -connect mailserver.de:587 -starttls smtp

EHLO localhost
250-mailserver.de
250-PIPELINING
250-SIZE 44040192
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 CHUNKING
QUIT
DONE


> angezeigt. in master.cf gibt es auch für smtp (Port 25) nur den Standard-Eintrag:
> smtp      inet  n       -       n       -       -       smtpd
> 
> Für submission und smtps:
> 
> submission inet n       -       n       -       -       smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
>   -o milter_macro_daemon_name=ORIGINATING

Hier könntest Du mit -o smtpd_tls_ciphers eine abweichende Konfiguration zur main.cf angeben.


> smtps     inet  n       -       n       -       -       smtpd
>   -o syslog_name=postfix/smtps
>   -o smtpd_tls_wrappermode=yes
>   -o smtpd_sasl_auth_enable=yes
>   -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
>   -o milter_macro_daemon_name=ORIGINATING
> 
> Demnach müsste die Konfiguration so passen. Bezüglich smtps (Port 465) habe ich mal in das Log gesehen. Auffällig ist, das lokale MUAs, in diesem Fall Thunderbird über 587 einliefert, K-9 MUAs (Android) über smtps (Port 465).

> Bezüglich smtps gab es ja in den letzten Jahren Einiges hin und her. Aber so wie ich es lese, wäre es wohl ok, Mail über Port 465 und 587 anzunehmen.

Man konnte bei STARTTLS wohl via Pipelining Kommandos unterschieben und Daten aus der Pre-SSL-Phase in die verschlüselte Verbindung einbringen. Wenn ich mich recht erinnere ist das Problem aber behoben.
(Pipelining = mehrere Kommandos nacheinander schicken, ohne die Antwort vom Server abzuwarten)

Die Situation ist historisch gewachsen. Zuerst hatte man open Relays, dann kamen die Spammer und es wurde SMTP-Auth auf Port 25 eingeführt, dann hat man auf 587 verlagert um eigene Benutzer besser vom Verkehr zwischen Mailservern zu trennen und ggf. Port 25 in Firewalls sperren zu können. Passwörter werden aus Datenschutzgründen mittlerweile eher gehasht/gesalzen am Server abgelegt, dadurch fallen Challenge-Response-Verfahren raus und das Passwort muss im Klartext übertragen werden. Deswegen begann man mit STARTTLS abzusichern und von da ist es dann nur noch ein kleiner Weg zu 465, der wie https von Beginn an verschlüsselte Verbindungen aufbaut.

Bei neuen Mailaccounts tendiere ich zu 465 (993/995), sehe aber keine Notwendigkeit bestehende von 587 (110/143 mit STARTTLS) umzustellen.

Viele Grüße
Gerald
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20211220/a582ffb9/attachment-0001.htm>