Repeating: lighttpd TLS configuration recommendations supercede the issue reported here. (https://wiki.lighttpd.net/Docs_SSL)
> I now removed that cipher list (falling back to the default), and this > disabled the 2 remaining ciphers (DHE-RSA-AES256-GCM-SHA384 and > DHE-RSA-AES128-GCM-SHA256) that used Diffie Hellman :-) As you noticed, using the lighttpd TLS configuration recommendations does not include the ciphers using the finite field Diffie-Hellman parameters which caused Nexpose to generate warnings. --- Regarding the DH parameters used by default by lighttpd when finite field Diffie-Hellman parameters are used: > > Please clarify why you think this is insecure. > I trust Nexpose on this one. The theory goes that any "standard" > parameter is insecure, as a would be attacker would only need to "crack" > it once, and then be able to use it against a huge number of sites. I trust the published RFCs by experts more than I trust Nexpose. > I'm not really sure that it is a good idea to rely on *any* standard > Diffie-Hellman parameters :-( I'm not familiar with your expertise in this security area. What are your credentials that would give weight to your opinion? On the contrary: While there is the theoretical possibility of the well-known standard parameters being cracked, there are different potential pitfalls for generating custom parameters and then not cryptographically analyzing those custom parameters for weaknesses. It does not appear that you are performing that analysis on your custom parameters, and so my recommendation is to use the standard parameters which have been analyzed by experts for weaknesses. That does not guarantee safety, but does add more confidence to safety of the standard parameters when compared to custom parameters lacking expert analysis for weaknesses. As you have outsourced your security analysis to Nexpose, I recommend you follow up with Nexpose for more detailed guidance. I suggest that removing those ciphers is best practices at this point, unless you must support older clients which do not support more modern ciphers. If you still trust Nexpose more than other experts, I urge you to reconsider. Do you think Nexpose knows better than the OpenSSL developers? `man SSL_CTX_set_dh_auto` ``` Typically applications should use well know DH parameters that have built-in support in OpenSSL. The macros SSL_CTX_set_dh_auto() and SSL_set_dh_auto() configure OpenSSL to use the default built-in DH parameters for the SSL_CTX and SSL objects respectively. Passing a value of 1 in the onoff parameter switches the feature on, and passing a value of 0 switches it off. The default setting is off. If "auto" DH parameters are switched on then the parameters will be selected to be consistent with the size of the key associated with the server's certificate. If there is no certificate (e.g. for PSK ciphersuites), then it it will be consistent with the size of the negotiated symmetric cipher key. Applications may supply their own DH parameters instead of using the built-in values. This approach is discouraged and applications should in preference use the built-in parameter support described above. ``` Note: other TLS libraries such as GnuTLS use the expert-recommended standard parameters and no longer provide an option to set custom DH parameters. ``` Prior to GnuTLS 3.6.0 for the ephemeral or anonymous Diffie-Hellman (DH) TLS ciphersuites the application was required to generate or provide DH parameters. That is no longer necessary as GnuTLS utilizes DH parameters and negotiation from [RFC7919]. ``` --- Issue resolution: Since lighttpd 1.4.60, lighttpd switches on SSL_CTX_set_dh_auto() in lighttpd mod_openssl, and this causes openssl to ignore "DHParameters" even when explicitly set. This will be fixed in lighttpd 1.4.72. In lighttpd 1.4.72, if you explicitly set "DHParameters", lighttpd will switch off SSL_CTX_set_dh_auto() so that openssl will honor the user-supplied parameters. Even so, the expert recommendation is to allow openssl 3.0.0 and later to select the DH parameters (which lighttpd does by enabling SSL_CTX_set_dh_auto()).
