Roundcube, Exim und TLS

[daemotron]

Ich versuche, Roundcube zur Zusammenarbeit mit Exim zu überreden und dabei TLS zu sprechen. Das momentane Setup umfasst drei Jails: eines mit Exim und Dovecot, eines mit Roundcube (Nginx + PHP 5.6 via FastCGI) und eines mit PostgreSQL.

Was funktioniert:

• Exim spricht mit Dovecot (Auth-Socket)
• Exim, Dovecot und Roundcube sprechen mit PostgreSQL
• Roundcube spricht mit Dovecot und nutzt dazu STARTTLS
• Ein Mail Client (Claws Mail) auf meinem Rechner spricht mit Dovecot und Exim, jeweils mit STARTTLS
• Exim spricht mit anderen MTAs und nutzt dabei ebenfalls STARTTLS (sowohl bei ein- als auch bei ausgehenden Verbindungen)

Was nicht funktioniert:
Roundcube spricht kein STARTTLS mit Exim; das ganze endet immer in einem wirren Fehler. Hier das Debug Log von Exim:

Code: Select all

57113 SMTP>> 220 mail.my-universe.com ESMTP Exim 4.85 Sun, 27 Sep 2015 09:03:28 +0200
57113 Process 57113 is ready for new message
57113 smtp_setup_msg entered
57113 SMTP<< EHLO webmail.my-universe.com
57113 sender_fullhost = webmail.my-universe.com [192.168.0.3]
57113 sender_rcvhost = webmail.my-universe.com ([192.168.0.3])
57113 set_process_info: 57113 handling incoming connection from webmail.my-universe.com [192.168.0.3]
57113 host in pipelining_advertise_hosts? yes (matched "*")
57113 host in auth_advertise_hosts? yes (matched "*")
57113 host in tls_advertise_hosts? yes (matched "*")
57113 SMTP>> 250-mail.my-universe.com Hello webmail.my-universe.com [192.168.0.3]
57113 250-SIZE 52428800
57113 250-8BITMIME
57113 250-PIPELINING
57113 250-STARTTLS
57113 250 HELP
57113 SMTP<< STARTTLS
57113 openssl option, adding from 1000000: 1000000 (no_sslv2)
57113 openssl option, adding from 1000000: 2000000 (no_sslv3)
57113 openssl option, adding from 3000000: 4000000 (no_tlsv1)
57113 openssl option, adding from 7000000: 20000 (no_compression)
57113 setting SSL CTX options: 0x7020000
57113 Diffie-Hellman initialized from /usr/local/etc/ssl/exim/dhparam.pem with 2232-bit prime
57113 tls_certificate file /usr/local/etc/ssl/exim/cert.pem
57113 tls_privatekey file /usr/local/etc/ssl/exim/key.pem
57113 Initialized TLS
57113 required ciphers: EECDH+AES256:EECDH+AES128:EDH+AES256:EDH+AES128:!SSLv3:!SSLv2:!CAMELLIA:!RC4:!3DES:!IDEA:!SEED:!PSK:!SRP:!DSS:!eNULL:!aNULL
57113 host in tls_verify_hosts? no (option unset)
57113 host in tls_try_verify_hosts? no (option unset)
57113 SMTP>> 220 TLS go ahead
57113 Calling SSL_accept
57113 SSL info: before/accept initialization
57113 SSL info: before/accept initialization
57113 SSL info: SSLv2/v3 read client hello A
57113 LOG: MAIN
57113   TLS error on connection from webmail.my-universe.com [192.168.0.3] (SSL_accept): error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
57113 LOG: MAIN
57113   TLS client disconnected cleanly (rejected our certificate?)
57113 TLS failed to start
57113 SMTP<< 
57113 SMTP>> 554 Security failure
57113 LOG: smtp_connection MAIN
57113   SMTP connection from webmail.my-universe.com [192.168.0.3] closed by EOF
57113 search_tidyup called
57113 close PGSQL connection: 192.168.0.2/mail/exim
56678 child 57113 ended: status=0x0
56678   normal exit, 0
56678 0 SMTP accept processes now running
56678 Listening...

Von Roundcube habe ich mir ebenfalls mal ein Debug Log für die SMTP Session aufschreiben lassen:

Code: Select all

[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 220 mail.my-universe.com ESMTP Exim 4.85 Sun, 27 Sep 2015 11:08:23 +0200
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Send: EHLO webmail.my-universe.com
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 250-mail.my-universe.com Hello webmail.my-universe.com [192.168.0.3]
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 250-SIZE 52428800
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 250-8BITMIME
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 250-PIPELINING
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 250-STARTTLS
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 250 HELP
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Send: STARTTLS
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Recv: 220 TLS go ahead
[27-Sep-2015 11:08:23 +0200]: <lqkh96ai> Send: RSET
[27-Sep-2015 11:09:23 +0200]: <lqkh96ai> Send: QUIT
[27-Sep-2015 11:09:23 +0200]: <lqkh96ai> Recv: 554 Security failure

Im Error Log von Roundcube steht dann noch ganz vielsagend:

Code: Select all

[27-Sep-2015 11:08:23 Europe/Berlin] ERROR: STARTTLS failed ()
[27-Sep-2015 11:09:23 +0200]: <lqkh96ai> SMTP Error: Authentication failure: STARTTLS failed (Code: ) in /local/usr-local/www/roundcube/program/lib/Roundcube/rcube.php on line 1713 (POST /?_task=mail&_unlock=loading1443344886076&_lang=en&_framed=1?_task=mail&_action=send)

Konfiguration:
Die Konfiguration für TLS sieht in Exim so aus:

Code: Select all

openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_compression
tls_advertise_hosts = *
tls_dh_max_bits = 2236
tls_require_ciphers = ${if =={$received_port}{25}{\
        HIGH:!SSLv3:!SSLv2:!CAMELLIA:!RC4:!3DES:!IDEA:!SEED:!PSK:!SRP:!DSS:!eNULL:!aNULL\
    }{\
        EECDH+AES256:EECDH+AES128:EDH+AES256:EDH+AES128:!SSLv3:!SSLv2:!CAMELLIA:!RC4:!3DES:!IDEA:!SEED:!PSK:!SRP:!DSS:!eNULL:!aNULL\
}}
tls_certificate = /usr/local/etc/ssl/exim/cert.pem
tls_privatekey = /usr/local/etc/ssl/exim/key.pem
tls_dhparam = /usr/local/etc/ssl/exim/dhparam.pem
tls_on_connect_ports = 465

Getestet habe ich aber auch ohne jede Einschränkung (also mit TLSv1 und SSLv3 aktiviert, Ciphers auf Default) - Ergebnis ist dasselbe.

Zum Vergleich einmal die Konfiguration von Dovecot (nur der Part TLS betreffend):

Code: Select all

ssl_cert = </usr/local/etc/ssl/dovecot/cert.pem
ssl_cipher_list = EECDH+AES256 EECDH+AES128 EDH+AES256 EDH+AES128 !CAMELLIA !RC4 !3DES !IDEA !SEED !PSK !SRP !DSS !eNULL !aNULL !LOW !EXP
ssl_dh_parameters_length = 4096
ssl_key = </usr/local/etc/ssl/dovecot/key.pem
ssl_prefer_server_ciphers = yes
ssl_protocols = !SSLv2 !SSLv3

Hier die Konfiguration von Roundcube:

Code: Select all

$config['default_host'] = 'tls://imap.my-universe.com';
$config['imap_conn_options'] = array(
    'ssl'         => array(
        'verify_peer'  => true,
        'verify_depth' => 3,
        'cafile'       => '/usr/local/etc/ssl/ca-bundle.pem',
    ),
    'tls'         => array(
        'verify_peer'  => true,
        'verify_depth' => 3,
        'cafile'       => '/usr/local/etc/ssl/ca-bundle.pem',
    ),
);

$config['smtp_server'] = 'tls://smtp.my-universe.com';
$config['smtp_port'] = 587;
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
$config['smtp_helo_host'] = 'webmail.my-universe.com';
$config['smtp_timeout'] = 0;
$config['smtp_conn_options'] = array(
    'ssl'         => array(
        'verify_peer'  => true,
        'verify_depth' => 3,
        'cafile'       => '/usr/local/etc/ssl/ca-bundle.pem',
        'ciphers' => 'EECDH+AES256:EECDH+AES128:EDH+AES256:EDH+AES128:!SSLv3:!SSLv2:!CAMELLIA:!RC4:!3DES:!IDEA:!SEED:!PSK:!SRP:!DSS:!eNULL:!aNULL',
    ),
    'tls'         => array(
        'verify_peer'  => true,
        'verify_depth' => 3,
        'cafile'       => '/usr/local/etc/ssl/ca-bundle.pem',
        'ciphers' => 'EECDH+AES256:EECDH+AES128:EDH+AES256:EDH+AES128:!SSLv3:!SSLv2:!CAMELLIA:!RC4:!3DES:!IDEA:!SEED:!PSK:!SRP:!DSS:!eNULL:!aNULL',
    ),
);

Die Zertifikate für Exim und Dovecot sind mit demselben CA Zertifikat signiert; spaßeshalber habe ich aber auch schon mit abgeschalteter Verifizierung versucht - immer mit demselben Ergebnis und demselben Fehlercode im Exim Debug Log. Was mich besonders irritiert: Prinzipiell kann mein Exim-Setup ja TLS (mit Claws Mail als Client jedenfalls), und prinzipiell kann ja auch mein Roundcube-Setup TLS (mit Dovecot als Server). Was zum Kuckuck macht mir TLS zwischen Roundcube und Exim kaputt? Oder hat jemand eine Idee, wie ich das noch besser debuggen kann?

[Joe User]

Wenn ich den Code in zwei Minuten überfliegen richtig verstanden habe:
RoundCube nutzt PEAR::Net_SMTP und verweist in https://github.com/roundcube/roundcubem ... /Roundcube auf die aktuelle Version von https://github.com/pear/Net_SMTP und dort versteckt sich unter https://github.com/pear/Net_SMTP/#the-n ... et-package vermutlich die Lösung des Problems.

[daemotron]

Das Array $config['smtp_conn_options'] aus meiner o. g. Konfiguration wird dem Net_SMTP Konstruktor als socket_options Parameter übergeben - so weit bin ich auch schon durch den Quellcode. Ich habe auch versucht, verify_peer (bzw. verify_peername) abzuschalten. Mit Dovecot funktioniert das auch wie vorhergesehen, nur eben mit Exim nicht.

Ich bin mittlerweile bei folgenden Hypothesen angelangt, von denen wahrscheinlich mindestens eine zutrifft:

1. Mein Zertifikat ist irgendwie kaputt und Claws Mail verhält sich toleranter als Net_Socket (unwahrscheinlich, openssl s_client verhält sich "normal" und liefert eine TLSv1.2 Session ohne Gemotze, dass etwas nicht stimmt)
2. Exim hat einen Bug (recht unwahrscheinlich, da Claws Mail und openssl s_client funktionieren)
3. PHP Pear's Net_Socket Paket hat an irgendeiner Stelle einen Bug (ebenfalls unwahrscheinlich, da Net_IMAP funktioniert)
4. Net_SMTP hat einen Bug, oder Roundcube implementiert Net_SMTP irgendwo falsch
5. Meine Konfiguration schlägt nicht durch, weil entweder ein Plugin dazwischenfunkt oder Roundcube einen Bug hat

Mir fällt jetzt nur noch ein, selbst ein primitives Skript auf Basis von Net_SMTP zu schreiben, das einen Connect mit dem Server durchführt und etwas mehr Debug-Output liefert. Falls das nichts bringt, muss ich wohl https://github.com/roundcube/roundcubem ... e_smtp.php bearbeiten, damit es mir mal verrät, mit welchen Parametern der Connect tatsächlich versucht wird. Vielleicht findet sich ja so die Lösung...

[jan10001]

Die Zeile kommt mir bekannt vor:
"error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol"

Aktiviere mal in deiner SSL Conf. die Kompression, wenn ich mich recht entsinne wird "compressed SSL traffic" erwartet.

[daemotron]

Aktiviere mal in deiner SSL Conf. die Kompression, wenn ich mich recht entsinne wird "compressed SSL traffic" erwartet.

Danke, werde ich mal versuchen. Dabei habe ich auf beiden Seiten Kompression aus Sicherheitsgründen ausgeschaltet...

[rudelgurke]

Falls dass mit der Kompression nichts bringt, den gleichen Fehler habe ich bei OpenLDAP Clients (NSS / PAM) wenn die CA unbekannt ist.
OpenSSL meint zwar alles ist in Ordnung, LDAP ignoriert aber trotzdem die CA - gebe ich die CA dann manuell mit passt alles.

[timeless2]

Hast du die ganze Certificate-Chain in die Zertifikat-Datei gepackt? Hier gibt es einen Online-Test für die SSL-Einstellungen des Mailservers: https://ssl-tools.net/mailservers/