Sie sind hier

Exim4 and TLS with GMX/

Due to the unveiling of the NSA surveillance by Edward Snowden, some German mail providers decided last week to use TLS when sending mails out. For example GMX and Usually there shouldn't be a problem with that, but it seems as if the Debian package of Exim4 (exim4-daemon-heavy) doesn't support any TLS ciphers that those providers will accept. The Debian package uses GnuTLS for TLS and there is Bug #446036 that asks for compilation against OpenSSL instead.

Anyway,  maybe it's something in my config as I don't use the Debian config but my own /etc/exim4/exim4.conf. Here are the TLS related parts: 

tls_advertise_hosts = *
tls_certificate = /etc/exim4/ssl.crt/webmail-ssl.crt
tls_privatekey = /etc/exim4/ssl.key/webmail-server.key

That's my basic setup. After discovering that GMX and cannot send mails anymore, I added some more, following the Exim docs (it's commented out, because I don't use GnuTLS anymore):

#tls_dhparam = /etc/exim4/gnutls-params-2236
#tls_require_ciphers = ${if =={$received_port}{25}\
# {SECURE128}}

But still I got this kind of errors:

2013-08-14 22:49:27 TLS error on connection from [] (gnutls_handshake): Could not negotiate a supported cipher suite.

As this didn't help either, I recompiled exim4-daemon-heavy against OpenSSL and et voila, it worked again. So, the question is if there's any way to get it working with GnuTLS ? Does the default Debian config work and if so, why? And if not, can a decision be made to use OpenSSL instead of GnuTLS? Reading the bug report it seems as if there are exemptions for linking against OpenSSL , so GPL wouldn't be violated.

UPDATE 16.08.2013:
I reinstalled the GnuTLS version of exim4-daemon-heavy to test the recommendation in the comments with explicit tls_require_chiphers settings, but with no luck: 

#tls_require_ciphers = SECURE256
#tls_require_ciphers = SECURE128
#tls_require_ciphers = NORMAL

These all resulted in the usual "(gnutls_handshake): Could not negotiate a supported cipher suite." error when trying one by one cipher setting.

UPDATE 2 16.08.2013:
There was a different report about recent GnuTLS problem on the debian-user-german mailing list. It's not the same cause, but might be related.



What does the certificate chain look like? If it's not correctly ordered, gnutls will refuse to accept it, while OpenSSL is more lenient.

In fact, gnutls has the correct behaviour here.


I have a self-signed cert. So, there's basically no chain that other sites may accept. seem to accept TLSv1.2 with at least AES256-SHA256, AES256-SHA, DES-CBC3-SHA, AES128-GCM-SHA256, CAMELLIA128-SHA and, if you have generated DH parameters, ECDH modes too.

That seems like plenty of ciphers, so maybe GnuTLS's problem is to do with the TLS version rather than the cipher.

Or maybe an issue related to this:

p.s. on this comment form, E-mail doesn't have a '*' indicating it is a required field, but fails to post with an ambiguous error message. CAPTCHA is also confusing/meaningless if seen without JavaScript enabled.

You could try various options in exim4.conf:
tls_require_ciphers = SECURE256
tls_require_ciphers = SECURE128
tls_require_ciphers = NORMAL looks okay to me on Wheezy from gnutls-cli (with, same as exim4) :

$ gnutls-cli --crlf --starttls --insecure -d 3 -p 25
220 (mxgmx010) Nemesis ESMTP Service ready
EHLO myhost.mydomain Hello ...
250-SIZE 157286400
220 OK

- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-128-CBC
- Compression: NULL

Ok, have now reverted to Debians GnuTLS using version of Exim4 and set tls_require_ciphers = SECURE256. We'll see if this works for GMX... I'll keep you updated here...

I'm using the same setup. exim4-daemon-heavy with my own config file.
The TLS part is the same as your basic config and there are no problems with connections from gmx:

2013-08-15 12:11:41 1V9uWr-0000Hc-NK <= [hidden].de [] P=esmtps X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128

Since this is something new at GMX, maybe they already fixed whatever the problem was (perhaps a too-restrictive cipher list). Anyway it seems really good that they have done this; might as well use crypto where possible.

Just had a look in my older log files. I'm not getting much mails from gmx, but TLS from gmx worked already a week ago:

2013-08-07 19:16:34 1V77Le-0005x5-Ix <= [hidden].de [] P=esmtps X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128

I notice DHE was used there, so you must have parameters generated and configured. I seem to remember this is done automatically as part of Debian's packaging and default configuration.

Maybe Ingo's Exim configuration doesn't know where to find those, but still advertises DHE to the server (like, but with server/client roles reversed). GMX's servers may choose DHE in preference to other ciphers, and then gnutls realises it doesn't know what DHE parameters to use?

I don't think the bug would affect Wheezy Exim users using Debian's own configuration (or this gnutls26 flaw would would have been much more noticeable).

Rebuilding against OpenSSL doesn't seem like a bad idea anyway. Actually I'm tempted to do the same.

Yeah, I don't think either that users of Debian standard config are affected. OTOH I don't know that it works, too. ;)

Rebuilding against OpenSSL would be my favorite as it solves other problems as well, like running out of entropy.

Same problem with Exim 4.81 on FreeBSD. The problem appaered after installing a new (larger) certificate, so this might be related. What is interesting is, that the problem only happens with STARTTLS but not SSMTP.

I solved the problem by compiling exim with openssl instead. Funny thing is, that even the gnutls-cli test client fails for STARTTLS and suceeds for SSMTP.

On FreeBSD:

cd /usr/ports/mail/exim-mysql/

I realized that I couldn't receive mail from (Could not negotiate a supported cipher suite).
I spent a lot of time to get it working, but without success. The only thing that worked was disabling TLS1.2 and using other certificates. However, those certificates are signed by CACert with SHA512, which fails in Exim due to a bug in gnutls:

So my solution (debian wheezy) was to disable TLS entirely for hotmail, using a host-dependent advertisement of STARTTLS:
MAIN_TLS_ADVERTISE_HOSTS = ${if match {$sender_host_name}{.*hotmail.*}{localhost}{*} }

Probably I could also issue SHA512-signed certificates and disable TLS1.2


Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer