Exim dislikes the Postfix DH-cipher-length
- For using ECDHE ("perfect forward secrecy") it's necessary to define two
files with DH-primes:
root@mx2:~# postconf | grep dh_
smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
ECDHE work's fine, but not with older versions of Exim:
013-08-27 14:57:40 1VEIq4-0001mV-BC TLS error on connection to
mx0.jpberlin.de [220.127.116.11] (gnutls_handshake): The Diffie-Hellman
prime sent by the server is not acceptable (not long enough)
Those exim versions expect a length of 2048 (hardcoded), just in newer
versions it's possible to configure the necessary length down to 512 or
We're not sure who does right and who not.
*) Looks like Postfix isn't able to use a length of 2048. Why?
*) Or is it a mistake in Exim, because nobody uses 2048 and Exim
shouldn't expect that length by default (or at all)?
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin
Tel: 030 / 405051-42
Fax: 030 / 405051-19
Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Geschäftsführer: Peer Heinlein -- Sitz: Berlin
- On Sun, Sep 01, 2013 at 01:59:38PM +0200, Peer Heinlein wrote:
> For using ECDHE ("perfect forward secrecy") it's necessary to define twoThis matches the OpenSSL API, where one registers a DH parameter
> files with DH-primes:
> root@mx2:~# postconf | grep dh_
> smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
> smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
callback via SSL_CTX_set_tmp_dh_callback(3) and the callback is
when appropriate invoked to provide parameters with either 512 or
1024 bits. The callback function is never called with any other
> ECDHE work's fine, but not with older versions of Exim:Also not with OpenSSL prior to 1.0.0, nor with RedHat's OpenSSL
1.0.x, since RedHat disables EC algorithms.
> 013-08-27 14:57:40 1VEIq4-0001mV-BC TLS error on connection toThe Postfix SMTP client does not set any lower bound on the DH
> mx0.jpberlin.de [18.104.22.168] (gnutls_handshake): The Diffie-Hellman
> prime sent by the server is not acceptable (not long enough)
> Those exim versions expect a length of 2048 (hardcoded), just in newer
> versions it's possible to configure the necessary length down to 512 or
parameters. If the server is unauthenticated, a MITM attack works
at any parameter length. If the server is authenticated, it is
expected that server operators will not misconfigure the server
with parameters easily vulnerable to brute-force attack.
> We're not sure who does right and who not.Nothing in the TLSv1, TLSv1.1 or TLSv1.2 RFCs specifies how the
server is to choose ephemeral Diffie Hellman parameters.
Nor does http://tools.ietf.org/html/rfc5114#section-3.3 specify
any particular strategy for selecting the DH group for a given
> *) Looks like Postfix isn't able to use a length of 2048. Why?Nothing in OpenSSL provides any information to Postfix about when
a non-export (not 512) group might need more than 1024-bits of EDH
security. The latest development code from the master branch has:
#define SSL_EXPORT_PKEYLENGTH(a) (SSL_IS_EXPORT40(a) ? 512 : 1024)
this macro is ultimately used to set the "keylength" argument to the
DH parameter callback.
> *) Or is it a mistake in Exim, because nobody uses 2048 and EximThe Exim SMTP client can reasonably set the floor at 1024, in any
> shouldn't expect that length by default (or at all)?
context where export ciphers are not accepted. Anything beyond that
risks interoperability problems, so my take is that Exim is overly
It may be appropriate to start a thread on the openssl-users list
that asks the developers and experts to clarify application selection
of EDH parameters beyond 1024-bits.
Given the relative performance of EDH (MODP groups) vs. EECDH (elliptic
curve groups), just make sure the client's cipherlist lists EECDH
algorithms before EDH algorithms (default with OpenSSL 1.0.0 or later)
and you won't need to worry about EDH algorithm strength for too much
longer (once most servers support EECDH, you'll rarely use EDH).