Created attachment 25714 [details] Allow admin-choosen DH parameters for DHE enabled cipher-modes In order to be EAL4+ validated for one of our customers, Apache needs to be able to support 2048+ bits group size for Diffie-Hellman parameters. Right now, temporary parameters are 512 and 1024 bits only. We can still disallow DH at all, leaving only RSA for authentication and pre-master secret encryption, but that's a suboptimal solution, as we then loose forward secrecy. Adding a 2048 bits DH temporary key into mod_ssl is not possible, since OpenSSL would only ask for a 512/1024 bits one, depending on the "exportability" of the choosen ciper-mode. This patch adds a new configuration directive, "SSLDHParametersFile <file>", allowing the administrator to supply its own Diffie-Hellman parameters ("openssl dhparam 2048 > dhparam2048.pem" to generate 2048 bits ones, for example). If this directive is specified and parameters are found in the supplied file, then these parameters will be used whenever DHE is used to negociate the pre-master secret. If this directive is not used, then it works like it does now, leaving OpenSSL ask mod_ssl for a set of parameters of the desired size (512 or 1024 bits). We'd like this to be evaluated, discussed, and if possible, applied. Regards.
Created attachment 28699 [details] Updated patch for 2.4.2
A new version of the patch has been provided, based on httpd 2.4.2. When generating your own DH parameters, add the "-dsaparam" option to openssl commandline, this speeds up the handshake by about 15% for a 1024bits prime to 30% for a 2048bits prime. With "-dsaparam" option, the private key is limited to 160 bits for a <2048bits prime, and 256 bits for a >=2048bits one. You then have 80bits of security for a 1024bits prime, but based on NFS results you can't get much. 2048bits prime with a 256bits private key length gives you 128bits of security.
Any idea on when this might make it into 2.4.x or 2.2.x? Many thanks.
I would like to see this added to 2.2.x and 2.4.x too!
In addition, Elliptic Curve choice should also be given to the server admin in a similar way (e.g. SSLCurveList <enabled_curve_list> ). Tell the admin to execute 'openssl ecparam -list_curves' to get a list of the supported curves.
Would someone please apply this patch to 2.2.x and 2.4.x ... ?
I'd love to see this added to 2.2.x and 2.4.y
Created attachment 30804 [details] PoC: read (EC)DHE parameters from SSLCertificateFile (applies to trunk and 2.4.x) I'm fine with the idea, but the implementation in the patches submitted so far is too complex, in my opinion (in particular the SSL_read_DHparams stuff, which tries to support/read three different formats). Here is an alternative proposal: - only support PEM-formatted parameters (-----BEGIN DH PARAMETERS---- / -----END DH PARAMETERS-----) - use the existing SSLCertificateFile directive to support per-vhost, custom DHE and ECDHE parameters Attached is a - lightly tested - proof of concept, to be applied to either trunk or 2.4.x... testing and feedback welcome. To specify EC curve names, append the output of "openssl ecparam -name secp521r1" or your favorite curve to SSLCertificateFile (of course the docs for SSLCertificateFile would have to be extended, if there is a general agreement on taking this approach).
(In reply to Kaspar Brand from comment #8) > Created attachment 30804 [details] > PoC: read (EC)DHE parameters from SSLCertificateFile (applies to trunk and > 2.4.x) > > I'm fine with the idea, but the implementation in the patches submitted so > far is too complex, in my opinion (in particular the SSL_read_DHparams > stuff, which tries to support/read three different formats). This function is similar to SSL_read_X509 and SSL_read_PrivateKey defined in the same file, and used by the module to read the corresponding objects. That said, I'm not fluent in Apache internals, and I admit some things may have been done more easily. I tried to mimic how already existing elements (keys and certs) were declared, registered and used, when adding a new element type (DHParams). > - use the existing SSLCertificateFile directive to support per-vhost, custom > DHE and ECDHE parameters The original patch is also vhost-aware. It doesn't know about ECDHE, that's true. That wasn't critical at that time (2010) because nobody used ECDHE, and even today the used curve is the standard NIST P256, offering 128bits of security in theory. Since a few weeks, some people want to be able to specify the curve used, there's nothing wrong with that.
(In reply to Kaspar Brand from comment #8) I applied your patch in my testing environment with httpd-2.4.6 and it works as advertised. After appending DH parameters to the certificate file, all DH ciphers were using the expected key size. I found it a bit confusing that you actually have to put the params alongside your certificate into one file. One has to pay more attention to these additional settings on changing the certificate. But if it is actually way more easy to implement DH / ECDHE parameters this way, then it is probably the way to go.
(In reply to Erwann Abalea from comment #9) > This function is similar to SSL_read_X509 and SSL_read_PrivateKey defined in > the same file, and used by the module to read the corresponding objects. Perhaps this is an opportunity to clean up some mod_ssl cruft... I just took an extended proposal to the mailing list, to stir some further discussion: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3C52358ED1.2070704@velox.ch%3E Additionally, I think we should consider to use 2048-bit DH parameters by default if the cert's RSA/DSA key is 2048 bits or more (so that sysadmin's don't have to generate their custom DH parameters to get more than 1024 bits for DHE). Changing this by default is probably debatable, and therefore another reason I'm taking it to the list.
DH-parameters should always be at least the same size as the SSL certificate, so if I use 4096 or even 8192 bit for the certificate a DH parameter with only 2048 bit would effectively weaken the whole connection down to 2048 bit, which we don't want and in a few years we would have the exactly same situation ( DH parameters too weak and not FULLY selectable) as we do right now So please consider this and let the admin choose freely, but at least make sure DH parameters bits are never smaller than SSL certificate bits!
Comment on attachment 30804 [details] PoC: read (EC)DHE parameters from SSLCertificateFile (applies to trunk and 2.4.x) For trunk, this issue has been addressed with r1527295 (with updated documentation under https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatefile). A backport proposal for 2.4.x will likely follow.
Backport to 2.4.x proposed with r1528154. Patch available at https://people.apache.org/~kbrand/mod_ssl-2.4.x-ekh.diff.
The patch https://people.apache.org/~kbrand/mod_ssl-2.4.x-ekh.diff seems to break TLS 1.1 and 1.2 on my setup (RHEL 6.x, apache 2.4.6, openssl 1.0.1e). I haven't had a chance to look into it further, but using ssllabs.com it no longer showed me as supporting > TLS 1.0
Sorry, was a config error on my side. Patch works well.
I'm glad to see this patch being backported to 2.4. What are the considerations for backporting it to the 2.2.x branch as well?
Comment on attachment 28699 [details] Updated patch for 2.4.2 Marking as obsolete, since a different approach has been implemented in 2.4.x.
Fixed in 2.4.7 with r1542327.
Backported to 2.2.30 in r1680916.