Since our upgrade to Debian 12, lighttpd now uses insecure Diffie-Hellman parameters ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63 b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39 a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94 e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186 af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2 d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0 8f4df435c934063199ffffffffffffffff And this despite having pointed ssl.dh-file to a self generated dh param file, as described in https://weakdh.org/sysadmin.html In Debian 11, an identical configuration was using our locally generated secure dh parameters. Thanks,
Please clarify why you think this is insecure. This does not look like lighttpd mod_openssl default DH parameters used since lighttpd 1.4.56. Since lighttpd 1.4.56, lighttpd mod_openssl configures default DH parameters to use RFC 7919 FFDHE2048 2048-bit group https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83 RFC 7919: https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1 Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may change lighttpd mod_openssl to use FFDHE3072 by default in the future. Please note: if using GnuTLS (with lighttpd mod_gnutls) or using mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is chosen to be secure according to RFC7919 DH parameter negotiation, and there is no default set by lighttpd. That page is out-dated, at least for lighttpd. Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list now used by default since lighttpd 1.4.68. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 the future scheduled removal of ssl.dh-file. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67 The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023) https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 As linked in the lighttpd release notes: See https://wiki.lighttpd.net/Docs_SSL for replacements with `ssl.openssl.ssl-conf-cmd`, but prefer lighttpd defaults instead. Since lighttpd 1.4.68, use ssl.openssl.ssl-conf-cmd "DHParameters" to specify your own DH parameters file, as ssl.dh-file has been removed. If you have custom DH parameters, then please review RFC7919 and modern security papers to make sure what you think is secure is still considered secure by experts, as the use of parameters derived from "safe" primes is strongly recommended. It is my understanding that FFDHE3072 is the current recommendation if you are going to set explicit DH parameters. Cheers, Glenn
Hi, Thanks for your reply. The full Diffie-Hellman parameter was listed in our monthly "Nexpose" Report. Then I confirmed using openssl s_client -connect mcp.aev.etat.lu:443 -tls1_2 -cipher DHE-RSA-AES256-GCM-SHA384 -msg | grep -A2 " 0c 00" that this was indeed the parameters used. (responds with a handshake failure now, as I disabled the 2 ciphers that use Diffie-Hellman) 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. Not sure where this is coming from, but for sure not from our local configuration (which is basically being ignored...) We did use a "locally" constructed cipher list, to which we kept blacklisting ciphers as soon as Nexpose considered them insecure. 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 :-) It would have been good if this change, potentially endangering security, would have been listed in apt_listchanges. I tried adding the following to our config (with the 2 ciphers re-enabled): ssl.openssl.ssl-conf-cmd += ( "DHParameters" => "/etc/lighttpd/ssl/dhparam.pem" ) but it still reacts with its default settings, rather than ours, generated with openssl dhparam -out /etc/lighttpd/ssl/dhparam.pem 4096 I'm not really sure that it is a good idea to rely on *any* standard Diffie-Hellman parameters :-( Regards,
Repeating: lighttpd TLS configuration recommendations supercede the issue reported here. (https://wiki.lighttpd.net/Docs_SSL) 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: I trust the published RFCs by experts more than I trust Nexpose. 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()).