Courier-MTA: WeakDH-Attacke umgehen

Courier-MTA: WeakDH-Attacke umgehen

Beim Empfang mancher E-Mails meldet der Courier-MTA in der Datei /var/log/mail.info folgenden Fehler: 

courieresmtpd: STARTTLS failed: couriertls: accept:
error:1409442F:SSL routines:SSL3_READ_BYTES:
tlsv1 alert insufficient security

Dieser Fehler tritt auf, wenn SMTP mit Verschlüsselung aktiv ist, jedoch die Diffie-Hellman(DH)-Parameter zu "kurz" sind und daher eine sogenannte WeakDH-Attacke möglich wird. Erkennt der versendende Mailserver, dass eine WeakDH-Attacke möglich ist, kann er die verschlüsselte Übertragung ablehnen.

Bezüglich Debian 8 mit Courier werden derzeit (Juni 2015) standardmäßig 768 bit für die DH-Parameter bei Verwendung von OpenSSL verwendet.

Manche Mailprovider (z. B. googlemail) akzeptieren 768 bit klaglos, anderen Mailprovidern (z. B. web.de) sind 768 bit jedoch zu unsicher für eine verschlüsselte Übetragung. Konsequenterweise müssten diese Anbieter die Übertragung der kompletten E-Mail eigentlich ablehnen (der empfangende Mailserver hat an dieser Stelle bereits signalisiert, dass er eine verschlüsselte Übertragung unterstützt). Statt einer unsicheren verschlüsselten Übertragung überträgt web.de die Daten jedoch vermutlich unverschlüsselt. Zumindest lässt sich bei mir feststellen, dass Mails trotz des genannten Fehlers ankommen. Es gibt jedoch auch anderslautende Erfahrungen, nach denen Mails auf manchen Servern nicht ankommen (mit anderen MTA's bzw. Distributionen).

Das zugrunde liegende Problem sind jedoch nicht nur E-Mails die verloren gehen: Das Diffie Hellman Verfahren dient dem sicheren Austausch eines Geheimnisses über einen Informationskanal, ohne dass Dritte dieses Geheimnis erfahren können, selbst wenn sie auf diesem Informationskanal mithören können. Dieses Geheimis zwischen zwei Kommunikationspartnern kann bei jeder Verbindung neu ausgehandelt werden, sodass bei jeder Verbindung frisches Schlüsselmaterial zum Einsatz kommt, welches vor der Verwendung nirgends gespeichert war und nach der Verbindung verworfen wird. Mit dem Verlust dieses Schlüssels kann auch ein Dritter, der ggf. die verschlüsselte Verbindung mitgeschnitten hat, diesen Schlüssel nicht mehr von einem der Kommunikationspartner entwenden. Entsprechend lässt sich die Verbindung auch nicht mehr auf diese Weise entschlüsseln, selbst wenn anderes Schlüsselmaterial wie private Schlüssel für die TLS-Verbindung entwendet wurden. Entsprechend spricht man hier von Perfect Forward Secrecy (PFS).

Das Problem ist nun aber: Selbst wenn der Geheimnisaustausch vertrauenswürdig ist, sollte das Geheimnis trotzdem eine gewisse Länge haben um nicht erraten oder eingegrenzt werden zu können. 768 bit gelten hierbei zwischenzeitlich als gebrochen, und selbst 1024 bit scheinen nicht mehr zukunftssicher. Empfohlen werden daher mindestens 2048 bit.

Zurück zum ursprünglichen Problem werden nun also Mailserver blockiert, mit denen keine sichere Kommunikation möglich ist, wie das beispielsweise bei 768 bit der Fall wäre.

Diffie-Hellman-Parameter bei einem Courier-Mailserver auf 2048 oder 4096 bit anheben

Wenn man das Programm mkdhparams ausführt, wird eine Datei /etc/courier/dhparams.pem erzeugt, welche DH-Parameter der Länge 768 bit enthält. Da 768 bit manchem Mailprovider zu kurz und damit zu unsicher sind, sollte man sie auf mindestens 1024 bit anheben, um überhaupt E-Mails austauschen zu können. Aus Sicherheitsgründen sollte man mindestens 2048 bit wählen, und auch weil die 1024 bit Mindestanforderung mancher Mailprovider vermutlich bald angehoben werden wird. Empfehlung: Man kann (wie der apache-Webserver) die DH-Parameter so lang wählen wie das Zertifikat lang ist (also z. B. 4096 bit DH-Parameter für ein 4096 bit Zertifikat).

Bisherige Datei löschen: 

rm /etc/courier/dhparams.pem

/etc/courier/dhparams.pem mit korrekten Permissions erzeugen (hier noch 768 bit!): 

mkdhparams

Überschreiben mit 2048 bit 

openssl dhparam -out /etc/courier/dhparams.pem 2048

Überschreiben mit 4096 bit 

openssl dhparam -out /etc/courier/dhparams.pem 4096

service courier-mta-ssl restart

Danach eine Mail von web.de auf den eigenen Mailserver schicken und mit 

tail -f /var/log/mail.info

und kontrollieren, ob der Fehler nicht mehr erscheint.

Zukünftig muss man aufpassen, dass mkdhparams nicht ausgeführt bzw. keine neue dhparams.pem erzeugt wird: So lange kein Patch zur Verfügung steht, würde mkdhparams die dhparams.pem wieder mit 768 bit erzeugen. Alternativ kann man die Umgebungsvariable BITS, wie in man mkdhparams beschrieben, setzen.

Test auf Verwendung von Diffie-Hellman

Ein Testlauf mit openssl, eingeschränkt auf Diffie-Hellman-Ciphern, 

openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -cipher 'DH' -connect mail.example.com:25 | grep Cipher

liefert z. B. die Ausgabe: 

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384

Wobei DHE bedeutet, dass Diffie-Hellman zur Anwendung kommt. Beginnt die Cipher mit DHE (oder ECDHE), dann steht Perfect Forward Secrecy (PFS) zur Verfügung. Die Ausgabe kann abweichen, je nachdem welche Cipher Client und Server aushandeln.

Neben dem (E)SMTP-Port 25 kann man auch den Port 587 testen. Dieser ist für den SMTP-Versand von authentifizierten Benutzern gedacht.

Sofern der Mailserver den Port 465 unterstützt, kann man auch diesen testen. Im Gegensatz zu Port 25 sollte der Mailserver auf Port 465 nur verschlüsselte Verbindungen zulassen (SMTPS).

Weiter kann man pop3s auf Port 995 und imaps auf Port 993 testen: 

openssl s_client -CApath /etc/ssl/certs/ -cipher 'DH' -connect mail.example.com:995
openssl s_client -CApath /etc/ssl/certs/ -cipher 'DH' -connect mail.example.com:993

Das Verwenden einer DHE-Cipher ermöglicht den WeakDH-Angriff erst, wobei die Verwendung von Diffie Hellman ansonsten durchaus erwünscht ist, wie oben beschrieben. Allerdings müssen eben sichere DH-Parameter verwendet werden. Daher müssen die soeben genannten Ports 25, 587, 465, 995 und 993 nun im Folgenden noch auf sichere DH-Parameter überprüft werden.

Test der Diffie-Hellman-Parameter

Zur Sicherheit sollte man zusätzlich testen, ob die DH-Parameter tatsächlich die gewünschte Länge haben. Mit openssl als Client kann man den Nachrichtenaustausch zwischen Mailserver und Client näher betrachten: Die Option -msg führt dazu, dass openssl einen sogenannten ServerKeyExchange ausgibt. 

openssl s_client -CApath /etc/ssl/certs/ -msg -starttls smtp -connect mail.example.com:25

Die Ausgabe enthält Angaben zur Länge der verwendeten DH-Parameter: 

<<< TLS 1.2 Handshake [length 060f],
ServerKeyExchange 0c 00 06 0b aa aa aa aa aa aa aa aa aa aa aa aa

Mit 0c für den Nachrichtentyp ServerKeyExchange und darauf folgend 00060b für die Länge in Byte, wobei hexadezimal 0x00060b = 1547 Byte im Dezimalsystem ergibt. Man kann auch einfach von der angezeigten Length die ersten 4 Byte abziehen, also 0x060f - 0x4 = 0x060b = 1547.

Hier einige Test-Ausgaben:

Standardeinstellung für Debian 8 (jessie) ist, Stand Januar 2016, die Verwendung von mkdhparams mit 768 bit Länge. Mit 768 bit Schlüssellänge ergeben sich 0x0002cb = 715 Byte: 

mkdhparams 

512 semi-random bytes loaded
Generating DH parameters, 768 bit long safe prime, generator 2
<<< TLS 1.2 Handshake [length 02cf],
ServerKeyExchange 0c 00 02 cb aa aa aa aa aa aa aa aa aa aa aa aa

openssl dhparam -out /etc/courier/dhparams.pem 768

Generating DH parameters, 768 bit long safe prime, generator 2
<<< TLS 1.2 Handshake [length 02cf],
ServerKeyExchange 0c 00 02 cb aa aa aa aa aa aa aa aa aa aa aa aa

Mit 1024 bit Schlüssellänge ergeben sich 0x00030b = 779 Byte: 

openssl dhparam -out /etc/courier/dhparams.pem 1024

<<< TLS 1.2 Handshake [length 030f],
ServerKeyExchange 0c 00 03 0b aa aa aa aa aa aa aa aa aa aa aa aa

Mit 2048 bit Schlüssellänge ergeben sich 0x00040b = 1035 Byte: 

openssl dhparam -out /etc/courier/dhparams.pem 2048

<<< TLS 1.2 Handshake [length 040f],
ServerKeyExchange 0c 00 04 0b aa aa aa aa aa aa aa aa aa aa aa aa

Mit 4096 bit Schlüssellänge ergeben sich 0x00060b = 1547 Byte: 

openssl dhparam -out /etc/courier/dhparams.pem 4096

<<< TLS 1.2 Handshake [length 060f],
ServerKeyExchange 0c 00 06 0b aa aa aa aa aa aa aa aa aa aa aa aa

TLS Ciphers konfigurieren

Für Debian 8 können Ciphers mit folgenden Einstellungen verwendet werden: 

TLS_CIPHER_LIST="ECDH:DH:HIGH:SSLv3:+SSLv3:!CAMELLIA:!MEDIUM:!LOW:!EXP:!NULL:!aNULL@STRENGTH"
TLS_MIN_DH_BITS=1024

Hierbei sei angemerkt, dass dabei die Ciphers von SSLv3 aktiviert werden, jedoch nicht das unsichere SSLv3 Protokoll. Dieser Schritt ist nötig, um ältere Clients (Mail Clients und fremde Mail Server) weiterhin zu unterstützen.

Diese sollten in entsprechenden Dateien hinterlegt werden, z. B.:

  • /etc/courier/esmtpd für Port 25 (SMTP mit STARTTLS)
  • /etc/courier/esmtpd-ssl für Port 465 (SMTP over TLS)
  • /etc/courier/imapd-ssl für Port 993 (IMAP over TLS)
  • /etc/courier/pop3d-ssl für Port 995 (POP3 over TLS)
  • Die TLS-Einstellungen für Port 587 (Mail Submission SMTP mit STARTTLS) werden von /etc/courier/esmtpd übernommen

Testen lässt sich die Konfiguration dann mit https://www.htbridge.com/ssl, wobei der zu testende Port wie folgt angegeben werden kann: mail.example.com:25. Hierbei sei angemerkt, dass HtBridge sowohl native TLS-Verbindungen, als auch STARTTLS Verbindungen testen kann. Bezüglich der Bedienung sei angemerkt, dass man unbedingt den Refresh-Button auf der Seite anklicken sollte, wenn man ein aktuelles Erebnis sehen möchte.

Die Konfiguration für Client Sitzungen (wenn Courier Verbindungen zu anderen Mailservern aufbaut) lassen sich in /etc/courier/courierd vornehmen: 

TLS_MIN_DH_BITS=1024

Sollte der fremde Mailserver DH-Parameter verwenden, die kürzer als 1024 bit sind, so wird sich Courier MTA nicht mit diesem Mailserver verbinden.

Ausblick

Für Debian ist bereits ein Patch unterwegs, welches standardmäßig 2048 bit bei der Verwendung von mkdhparams vorsieht. Sobald dieses Patch über Updates ausgerollt wird, kann man die eigenen Anpassungen ggf. wieder herausnehmen.