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 Web.de. 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 Web.de 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}\
# {NORMAL:%COMPAT}\
# {SECURE128}}
But still I got this kind of errors:
2013-08-14 22:49:27 TLS error on connection from mout.gmx.net [212.227.17.21] (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.
openssl certificate chain bug
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.
See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573736
I have a self-signed cert. So
I have a self-signed cert. So, there’s basically no chain that other sites may accept.
gmx.de seem to accept TLSv1.2
gmx.de 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:
https://lists.gnu.org/archive/html/help-gnutls/2012-01/msg00005.html
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
You could try various options in exim4.conf:
tls_require_ciphers = SECURE256
tls_require_ciphers = SECURE128
tls_require_ciphers = NORMAL
gmx.net looks okay to me on Wheezy from gnutls-cli (with libgnutls.so.26, same as exim4) :
$ gnutls-cli –crlf –starttls –insecure -d 3 -p 25 mx00.gmx.net
220 gmx.net (mxgmx010) Nemesis ESMTP Service ready
EHLO myhost.mydomain
250-gmx.net Hello …
250-SIZE 157286400
250 STARTTLS
STARTTLS
220 OK
^D
– Peer’s certificate issuer is unknown
– Peer’s certificate is NOT trusted
– Version: TLS1.2
– Key Exchange: RSA
– Cipher: AES-128-CBC
– MAC: SHA1
– Compression: NULL
Ok, have now reverted to
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…
Working for me
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]@gmx.de H=mout.gmx.net [212.227.17.21] P=esmtps X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128
Since this is something new
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
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-0005×5-Ix <= [hidden]@gmx.de H=mout.gmx.net [212.227.17.22] P=esmtps X=TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128
I notice DHE was used there,
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 http://bugs.debian.org/481132#38, 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
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.
GNUTLS problem
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/
make WITHOUT=”GNUTLS” WITH=”TLS SA_EXIM AUTH_SASL SASLAUTHD CONTENT_SCAN” reinstall
same with hotmail: works partially with TLS<1.2
I realized that I couldn’t receive mail from hotmail.com (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:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921
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