httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Streamlining/improving ephemeral key handling in mod_ssl?
Date Sun, 15 Sep 2013 10:41:21 GMT
This grew out of working on a proof of concept for ("Patch to add
user-specified Diffie-Hellman parameters"). I would appreciate to get
more feedback on the changes proposed with the two attached patches...
which is the reason I'm taking the thing to the list.

I realized that there's quite some cruft in mod_ssl's ssl_engine_init.c
for dealing with ephemeral keys (the MODSSL_TMP_KEY_* macros and their
ssl_tmp_key_init_* friends). AFAICT, the primary reason for the whole
pTmpKeys dance with SSLModConfigRec at startup was due to the need of
pre-generating ephemeral RSA keys (as RSA key generation is an expensive

Ephemeral RSA, however, is basically a dead thing: specifically, it was
used to weaken the security strength at a time when there were US
export restrictions on what was considered "strong" crypto (more than
512 bits for key exchange in the 1990s). These restrictions were lifted
many, many years ago - in early 2000, to be precise [1].

I can't think of any good reason to still support export-grade ciphers
in 2013 - and if there's a consensus on this, I propose to get rid of
ssl_callback_TmpRSA etc. completely (see also [2] for more OpenSSL
specific background).

For DHE/ECDHE, there's no need to pre-generate keys at startup. In both
cases, what is needed are pre-generated *parameters* (from which OpenSSL
generates the keys on demand for every new SSL connection, which is a
cheap operation, see also [3] and the SSL_OP_SINGLE_DH_USE which mod_ssl
unconditionally sets).

In sum, I'm thinking of a two-step approach, as demonstrated by the
two attached patches (which can be applied to either trunk or 2.4.x). I
would be interested in getting feedback on the following points, in

- Does anyone object to dropping ephemeral RSA key support (and
unconditionally disabling export ciphers), at least for 2.4.x? If so,
for what reason?

- For the newly-added 2048-bit DH parameters, are there preferences to
use another value? (Right now, I took the parameter originally proposed
for SKIP - a pre-IKE proposal for IPSec key exchange from 1995. See the
comment in ssl_engine_dh.c patch for other potential candidates.)

- Are people fine with auto-increasing the DH parameter size to 2048
bits (for certs with RSA or DSA keys of at least 2048 bits)? This will
have some negative effects on interop, most likely, but sysadmins could
configure custom DH parameters (to downgrade to 1024 bits) as a
workaround in this case.

Thanks for sharing your thoughts. Reviews/testing of the patches are
also very welcome, of course.





View raw message