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 http://security.stackexchange.com/questions/41941/consequences-of-tampered-etc-ssh-modulifor arguments.
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 <httpd-dev.2...@velox.ch> > This grew out of working on a proof of concept for > https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 ("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] http://epic.org/crypto/export_controls/regs_1_00.html > > [2] > http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_rsa_callback.html#NOTES > > [3] http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html#NOTES > -- Erwann.
