httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erwann Abalea <>
Subject Re: Streamlining/improving ephemeral key handling in mod_ssl?
Date Sun, 15 Sep 2013 13:16:23 GMT
Ideally, the second patch should integrate the 2048bits parameters inside
the "generated section", and adapt the Perl code accordingly.
That way, a paranoid sysadmin can run this file in his perl interpreter,
and have his own 512/1024/2048 parameters generated by OpenSSL.
You could also decide to remove that possibility once admin-chosen DH
parameters become available.
I don't really trust these particular parameters, given the current
context. See Thomas' response in

Maybe you can consider using some speed-optimized versions of those
parameters, with the optional length field added and set to a suitable
value? That's what the "-dsaparam" option for the "openssl dhparam" call
does. There's no security problem if you use ephemeral keys.

2013/9/15 Kaspar Brand <>

> 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
> operation).
> 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
> particular:
> - 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.
> Kaspar
> [1]
> [2]
> [3]


View raw message