Dovecot TLS Perfect Forward Secrecy (PFS)

Abstract

Perfect Forward Secrecy (PFS) mit Dovecot ist schnell eingerichtet. Moderne IMAP/POP3-Clients nutzen dieses besondere Sicherheitsangebot auch. Allerdings existiert kein Weg, PFS für jede Verbindung zu erzwingen. Ältere IMAP/POP3-Clients können vom Aufbau verschlüsselter Verbindungen ausgeschlossen werden.

Perfect Forward Secrecy (PFS) mit Dovecot ist schnell eingerichtet. Moderne IMAP/POP3-Clients nutzen dieses besondere Sicherheitsangebot auch. Allerdings existiert kein Weg, PFS für jede Verbindung zu erzwingen. Ältere IMAP/POP3 Clients können vom Aufbau verschlüsselter Verbindungen ausgeschlossen werden.

Was geht?

Dovecot 2.1.x und neuer bieten Perfect Forward Secrecy mit den Standard-Chiffren (DHE) an, vorausgesetzt sie können dabei auf OpenSSL ab Version 0.9x. zurückgreifen. Damit können viele heute betriebene Installationen, wie z.B. Ubuntu Lucid, PFS nutzen. Neuere Dovecot-Versionen ab 2.2.x bieten, zusammen mit OpenSSL ab Version 1.x, zusätzlich die schnelleren ECDHE-Chiffren an.

Note

Die Unterschiede zwischen ECDHE und DHE liegen vor allem in der Performance. ECDHE-Chiffren greifen auf ECC (Elliptic Curve Cryptography) zurück. Diese gestatten kürzere Schlüssel bei gleicher Sicherheit. Diese einstmal von SUN entwickelten und patentierten Chiffren wurden erst kurz vor OpenSSL 1.0 an das Projekt übergeben.

Geht was?

Wenn im Dovecot-Log Verweise auf TLS-Sessions und die Chiffren DHE-RSA-AES256-SHA oder DHE-RSA-AES128-SHA zu finden sind, ist Perfect Forward Secrecy gewährleistet. Wer zusätzlich noch Chiffren findet, die den String ECDHE mit sich führen, verwendet Dovecot 2.2.x und Neuer.

Sind keine Verweise im Log zu finden, ist das nicht zwingend ein Indiz dafür, dass kein Client PFS in Anspruch nimmt. Der Grund kann schlichtweg sein, dass Dovecot die in einer TLS-Session verwendete Chiffre nicht mitloggt.

Chiffre ins LOG schreiben

In seiner Standardeinstellung loggt Dovecot die verwendete Chiffre nicht. Damit die Chiffre mitgeschrieben wird, muss das Makro %k in die Log-Konfigurationszeile in /etc/dovecot/conf.d/10-logging.conf aufgenommen werden:

login_log_format_elements = "user=<%u> method=%m rip=%r lip=%l mpid=%e %c %k"

Nach einem doveadm reload ist das erweiterte Log-Format aktiv. Die Chiffre ist am Ende der Zeile zu sehen:

Aug 15 18:23:00 mail02 dovecot: imap-login: Login: user=<username>, method=PLAIN, \
    rip=77.188.80.44, lip=10.0.0.1, mpid=24039, TLS, TLSv1 \
    with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

Wer den Parameter verbose_ssl in derselben Konfigurationsdatei aktiviert, kann im Detail verfolgen, wie Client und Server die Chiffre aushandeln. Es empfiehlt sich, dieses Loglevel nur zum Debuggen anzuschalten – sonst wird das Log sehr schnell sehr groß...

Eine Debug-Session mit Thunderbird sieht beispielsweise so aus:

Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv2/v3 read client hello A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read finished A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read finished A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully [1.2.3.4]
Aug 15 11:46:16 mail02 dovecot: imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [1.2.3.4]

Server konfiguriert – alles gut?

Das Spiel geht so: Der Server bietet Chiffren an. Der Client wählt eine – aus seiner Sicht – geeignete Chiffre aus. Diese Vorgehensweise ergibt Sinn, damit eine verschlüsselte Verbindung zustande kommen kann. Es bedeutet aber gleichzeitig, dass der Server keine direkte Kontrolle darüber hat, welche Chiffre zur Anwendung kommen wird.

Ein Postmaster kann indirekt auf die verwendeten Chiffren Einfluss nehmen, indem er den Server so konfiguriert, dass dieser nur diejenigen Chiffren anbietet, die der Postmaster "für würdig befindet". Dabei ist allerdings Vorsicht geboten! Je nach Produkt und – das macht es nicht einfacher – sogar Version unterstützen Clients unterschiedliche Chiffren.

Jeder Client wird aus dem Chiffre-Angebot des Servers immer nur die Chiffre wählen, die er auch selbst beherrscht. Darum ist ein Postmaster gut beraten, den Server möglichst viele Chiffren anbieten zu lassen, damit auf jeden Fall etwas dabei ist. Die Standardeinstellungen für Chiffren in Dovecot spiegeln das wider (siehe /etc/dovecot/conf.d/10-ssl.conf):

ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

Mike Kuketz hat einen wundervollen Artikel über Perfect Forward Secrecy mit Apple Mail geschrieben und schlägt für Apple Mail folgende Dovecot-Chiffre-Konfiguration vor:

ssl_cipher_list = DHE-RSA-AES256-SHA:DHE-RSA-AES128 SHA:!aNULL: \
        !eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!DSS:!SSLv2:!RC4

Wer, wie ich, auf dem Produktivsystem (noch) kein Openssl 1.x und Dovecot 2.2.x installiert hat, das ECDHE anbietet, kann zumindest erreichen, dass Apple Mail die Chiffren DHE-RSA-AES256-SHA und DHE-RSA-AES128 nutzen wird. Wird ECDHE geboten, bevorzugt Apple Mail es in allen Fällen.

Damit ist leider nicht allen Clients geholfen. Kurz nachdem ich die Cipher-Liste für Apple Mail optimiert hatte, erhielt ich einen Anruf eines Kunden, der nun nicht mehr mit Outlook 2003 auf Win7 über POP3S eine Verbindung zum Server aufbauen kann. Das ist zwar besonders sicher, aber sicher nicht das, was wir dem Kunden versprochen hatten... ;)

Darum experimentiere ich im Moment mit folgender ssl_cipher_list-Einstellung:

ssl_cipher_list = DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ALL:!LOW:!SSLv2:!EXP:!aNULL

Mein Plan ist, Chiffren für Perfect Forward Secrecy – DHE-RSA-AES256-SHA gefolgt von DHE-RSA-AES128-SHA – zuerst anzubieten. Findet ein Client daran keinen Gefallen, bietet der Server anschließend eine Sammlung von Chiffren, in der für jeden Client etwas dabei sein sollte. Eine Log-Auswertung in den nächsten Tagen wird zeigen, wie erfolgreich diese Strategie ist.

Status Quo ECDHE für IMAP-Clients

Hier ein paar Zugriffe diverser Clients aus meinen Logs:

Aug 15 12:55:09 mail01 dovecot: imap-login: Login: user=<user@user.de>, method=PLAIN, rip=1.2.3.4, lip=5.6.7.8, mpid=10207, TLS, TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
name=Mac OS X Mail, version=6.5 (1508), os=Mac OS X, os-version=10.8.4 (12E55), vendor=Apple Inc mit TLSv1 cipher AES128-SHA (128/128 bits)
vendor=Microsoft, os=Windows Mobile, os-version=7.10 mit TLS, SSLv3 with cipher RC4-SHA (128/128 bits)
name=com.android.email, os=android, os-version=4.0.3; IML74K, vendor=MEDION, x-android-device-model=MD_LIFETAB_P9516, x-android-mobile-net-operator=E-Plus mit TLSv1 with cipher RC4-MD5 (128/128 bits)
ID sent: name=iPad Mail, version=10B329, os=iOS, os-version=6.1.3  mit TLSv1 with cipher AES128-SHA (128/128 bits)
name=iPhone Mail, version=10B329, os=iOS, os-version=6.1.3 (10B329) mit TLSv1 with cipher AES128-SHA (128/128 bits)

Wer die Werte für z.B name=, os= usw. im Log sehen will, muss in 20-imap.conf die Werte imap_id_send = * und imap_id_log = * setzen.

Ein aktuelles Thunderbird nutzt von sich aus DHE-RSA-AES256-SHA (sofern es ihm angeboten wird). Dasselbe gilt für ein aktuelles K9 Mail auf Android – dies wäre derzeit meine Empfehlung. Outlook 2013 auf Win7 wählte TLSv1 with cipher AES128-SHA (128/128 bits).

Note

Zur Verbesserung der Situation wurde in Version 2.2.x der Parameter ssl_prefer_server_ciphers eingeführt.

Robert Schetterer, 15. August 2013