Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Viktor Dukhovni (postfix-usersdukhovni.org)
Date: Sun Sep 01 2013 - 12:00:33 CDT
On Sun, Sep 01, 2013 at 01:59:38PM +0200, Peer Heinlein wrote:
> For using ECDHE ("perfect forward secrecy") it's necessary to define two
> files with DH-primes:
> rootmx2:~# postconf | grep dh_
> smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
> smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
This matches the OpenSSL API, where one registers a DH parameter
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 to
> mx0.jpberlin.de [188.8.131.52] (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
The Postfix SMTP client does not set any lower bound on the DH
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 Exim
> shouldn't expect that length by default (or at all)?
The Exim SMTP client can reasonably set the floor at 1024, in any
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).