polarathene
commented
2 weeks ago Just for context, 2048-bit modulus for DHE / RSA is fine (more than that is effectively wasted compute + network resources): https://github.com/mozilla/ssl-config-generator/pull/256#issuecomment-2468980060
Some may need to bump that to 3072-bit for compliance reasons beyond their control despite that. That's the only valid reason that comes to mind, beyond some flaw in the math side being discovered that weakens the security 😅
janbrasna
gstrauss
In the past this was part of the configs, only allowing curves enumerated in the json data for the configs. At some point it got removed due to bugs in implementations, and also clients and servers being able to negotiate the reasonable thing anyways.
History
The original issue #44 when lighttpd wouldn't support multiple values is hopefully just a thing of the past. The support in nginx template was removed (or not added at all) due to reasons described in #76 (for details see https://trac.nginx.org/nginx/ticket/1089 — e.g. this needs #141 resolved first).
Background
If we want to officially support OpenSSL 3.x in #260, the issue with performance #162 is relevant again, this time even for
modern(and way past any TLSv1.2 DHE suites removal from the lists) — as OpenSSL 3.x started supporting FFDH key exchange for TLSv1.3 — which is part of RFC 8446 requiring RFC 7919, allowing to negotiate unnecessarily large keys (see https://openssl-library.org/post/2022-10-21-tls-groups-configuration/ for mitigation recommendations from the authors).See the overview at https://datatracker.ietf.org/doc/html/rfc7919#section-2 for addition of groups to curves, and their codepoints.
This wasn't an issue with OpenSSL 1.x.x as it only had support for ECDH key exchange in TLSv1.3, so we didn't have to restrict anything really. That changes with OpenSSL 3.x adding support for FFDH in TLSv1.3 (and others, too: see https://dheatattack.gitlab.io/mitigations/#tls for e.g. GnuTLS versions.)
BTW for the future of OpenSSL 3.x support for RFC 7919 also in TLSv1.2 follow:
Actions
To officially extend the support to the current OpenSSL versions that now allow (and enable by default without any group restriction) FFDH too, and keep the same guidelines, we have to consider either explicitly restricting the RFC 7919 groups to a reasonable subset (as some servers already do), or decide on not allowing any FFDH key exchange to begin with, and resort back to just recommending EC curves (as we currently do, just neither explain it, not enforce it though).
This may need revisiting all the "curves" settings in servers, whether they mean any RFC 7919 groups by that (as most would probably silently do), or if they separate ECDH and FFDH settings and configure both independently (as some do, with good defaults FWIW) — to give us a better idea of how such approach is feasible, and whether we'll be able to limit or completely restrict the groups allowed.