[Ach] New study on Forward Secrecy

christian mock cm at coretec.at
Wed Dec 31 01:24:33 CET 2014

On Tue, Dec 30, 2014 at 06:25:44PM +0100, Aaron Zauner wrote:

> We should - maybe - think about removing DHE (or, at the very least, not
> prefer it over ECDHE handshakes anymore) from our current

I'm against dropping DHE, as the problem is not a flaw in DHE as such,
but in implementations. That the problem is so wide-spread is again
attributable to openssl.

Prefering ECDHE would be OK, with the usual caveat about trusting NIST

Another issue is that I'd like to have real-world data on client
library compatibility with bigger DHE key sizes.

FYI, that's my openssl bug report on the issue (which hasn't shown up
yet in their bug tracking system):

--- cut ---
The documentation for SSL_CTX_set_tmp_dh_callback and
SSL_set_tmp_dh_callback is misleading with regard to the "keylength"
parameter provided to the callback.

The documentation and the example imply that the "keylength" parameter
will be adequate to whatever the used RSA key is, when in reality they
can only ever take the values 512 or 1024 (The same seems to apply for
the ECDH callback, although I'm not 100% positive).

Although one could argue that it is not stated explicitely, this seems
to be a widespread misunderstanding; the EXAMPLE section in
doc/ssl/SSL_CTX_set_tmp_dh_callback.pod falls into this trap, as did
the INN2 TLS code, and probably also Apache until they fixed it in

Also, a recent paper (http://www.w2spconf.com/2014/papers/TLS.pdf)
finds "we discovered that 82.9% of the servers supporting DHE used
Diffie-Hellman parameters that are weaker than their RSA signature
So I think this is a real-world security problem.

Details (in 1.0.1j):

When calling the callback, the "keylength" parameter is
generated thusly (s3_srvr.c:1632):


which can only ever return 512 or 1024 (ssl_locl.h:439):

#define SSL_EXPORT_PKEYLENGTH(a) (SSL_IS_EXPORT40(a) ? 512 : 1024)
--- cut ---


Christian Mock                          Wiedner Hauptstr. 15
Senior Security Engineer                1040 Wien
CoreTEC IT Security Solutions GmbH      +43-1-5037273
FN 214709 z

CoreTEC: Web Application Audit - Damit so etwas nicht passiert!



More information about the Ach mailing list