Dovecot TLS Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy (kurz: 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.

Bemerkung

Die Unterschiede von ECDHE zu 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, Perfect ist 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 schlichtweit 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 neue, 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 der selben 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 gross…

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, damit einen verschlüsselte Verbindung zustande kommen kann, Sinn. 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 je nach Version unterstützen Clients unterschiedliche Chiffren.

Jeder Client wird aus dem Chiffre-Angebot des Servers immer nur das Chiffre wählen, das es auch selbst beherrscht. Deshalb ist ein Postmaster gut beraten, wenn er den Server möglichst viele Chiffren anbieten läßt, damit auf jeden Fall was dabei ist. Die Standardeinstellungen für Chiffren in Dovecot, siehe /etc/dovecot/conf.d/10-ssl.conf, spiegeln das wieder:

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

Mike Kuketz, er hat einen wundervollen Artikel über Perfect Forward Secrecy mit Apple Mail geschrieben, 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 was wir dem Kunden versprochen hatten… ;)

Deshalb 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 als Nächstes eine Sammlung von Chiffren, in der für jeden Client was dabei sein sollte. Eine Logauswertung 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 , imap_id_send = * , 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).

Achtung:

Zur Verbesserung der Situation wurde in Version 2.2.x der Parameter ssl_prefer_server_ciphers eingefuehrt http://hg.dovecot.org/dovecot-2.2/rev/897484f45a87/ .


Kommentare

  1. Philip

    Philip (4 Jahre, 3 Monate) # Reply

    Danke für den sehr hilfreichen Artikel.

    Allerdings verwendet das neueste k9mail bei deiner Cipher-Liste: RC4-MD5 (128/128 bits)

    Mit dieser Liste

    ssl_cipher_list = TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!PSK:@STRENGTH

    wird AES128-SHA (128/128 bits) verwendet.

    Quelle: http://www.mail-archive.com/dovecot@dovecot.org/msg53729.html

    Wäre das nicht besser dann?

    Thunderbird nutzt auch dann weiterhin ECDHE-RSA-AES256-SHA (256/256 bits)

  2. Philip

    Philip (4 Jahre, 3 Monate) # Reply

    Ah, wie du ja bereits geschrieben hast, gibt es dann Probleme mit älteren Clients, wenn "ALL" nicht mit gelistet ist.

    Erst testen, dann kommentieren ;)

  3. Robert Schetterer

    Robert Schetterer (4 Jahre, 3 Monate) # Reply

    Wer noch mehr Infos braucht, z.B auch ueber Mail-Clients unter anderem auch auf Windows

    http://luxsci.com/blog/256-bit-aes-encryption-for-ssl-and-tls-maximal-security.html

  4. Stefan

    Stefan (3 Jahre, 10 Monate) # Reply

    Ich habe es mit dieser (oben genannten) Einstellung versucht

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

    leider benutzt mein Apple Mail 7.1 trotzdem die Verschlüsselung TLSv1 with cipher AES128-SHA (128/128 bits)

    mit diese Einstellung geht es dann, allerdings dann nicht (wie beschrieben) mit einem älteren Outlook

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

    hast du noch neuere Erkentnisse?

  5. Frank Bergmann

    Frank Bergmann (3 Jahre, 1 Monat) # Reply

    Falls jemand Dovecot < 1.1.3 im Einsatz hat (z.B. RHEL/Centos 5), so gibt es kein Logging mit '%k'.
    In diesem Fall kann man einen backported Patch anbringen.
    Mehr dazu steht unter http://www.tuxad.de/blog/archives/2014/10/13/cipher_logging_for_dovecot_on_rhel__centos_5/index.html .

Kommentare deaktiviert.