> -----Original Message----- > From: Kaspar Brand > Sent: Sonntag, 22. September 2013 12:32 > To: [email protected] > Subject: Re: Streamlining/improving ephemeral key handling in mod_ssl? > > On 16.09.2013 07:18, Kaspar Brand wrote: > > On 15.09.2013 15:16, Erwann Abalea wrote: > >> 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'm definitely in favor of the latter (not sure how many people really > > do know that ssl_engine_dh.c can be executed as a Perl script - and if > > we hardcode DH parameters, I'd rather go for well-defined ones). > > Attached is an improved version of the second part of the patch, which > does the following: > > - completely drops ssl_engine_dh.c from mod_ssl > > - relies on DH parameters from RFCs 2407 and 3526 (which are > already included as constants in OpenSSL 0.9.8a and later), > and configures them in the callback based on the certificate's > key length (1024 bits at the minimum, 4096 bits max., currently) > > - allows admins to configure their own DH parameters via > SSLCertificateFile (already implemented with the previous version > of the patch), in which case they have precedence over the > hardcoded parameters > > Feedback on this approach is again very welcome. Increasing the minimum > required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern, > IMO, as 0.9.7 is no longer maintained, and 0.9.8a was released in > October 2005 already.
Approach seems fine to me. I cannot comment on all aspects of the implementation. Maybe you should mention the issues with the Java limitation here. Regards Rüdiger
