I have been getting increasing number of errors in my Exim log related to GnuTLS Diffie-Hellman prime number. That prime number being too small causes Exim to abort the connection and initiate a new one to send the email over an unencrypted session.
The exact error message is: TLS error on connection to foobar.example.com [x.x.x.x] (gnutls_handshake): The Diffie-Hellman prime sent by the server is not acceptable (not long enough).
With a recent enough Exim installation, you can define the tls_dh_min_bits parameter to a value that you find acceptable.
To find the length of the DH prime number of a specific host, do the following:
$ gnutls-cli -s x.x.x.x -p 25
EHLO xentoo.info
STARTTLS
Hit <CTRL-D>
You should see something like this:
\# gnutls-cli -s x.x.x.x -p 25
Connecting to 'x.x.x.x:25'...
- Simple Client Mode:
220 foobar.example.com ESMTP Sendmail 8.14.3/8.14.3/SuSE Linux 0.8; Sat, 21 Jun 2014 03:29:34 -0400
EHLO xentoo.info
250-foobar.example.com Hello xentoo.info \[y.y.y.y\], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN
250-STARTTLS
250-DELIVERBY
250 HELP
STARTTLS
220 2.0.0 Ready to start TLS
\*\*\* Starting TLS handshake
- Successfully sent 0 certificate(s) to server.
- Ephemeral Diffie-Hellman parameters
**\- Using prime: 512 bits**
- Secret key: 507 bits
- Peer's public key: 512 bits
- Server has requested a certificate.
... bunch of other stuff ...
If you want to get rid of the errors for that host (and all the others that us a “as-low-as” 512bits DH prime), you just set tls_dh_min_bits = 512 in the remote_smtp transport .
As far as I understand, such a low DH prime implies that the connection is vulnerable to attacks and that it will be easier to get the content of the connection. For me, it is not a problem. Moreover, if I don’t do this, the mail is sent unencrypted, which is even easier.
It works with Exim 4.82 in Ubuntu 14.04 (Trusty) but it doesn’t with Exim 4.72 from Debian 6 (Squeeze).
Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676563