On 8/26/26 2:24 PM, Clemens Lang via stunnel-users wrote:

For now, if you want to keep FFDHE enabled and/or not opt-out of crypto-policies with your stunnel config, I’d recommend following this instruction from the stunnel manpage:

...

Alternatively, it is possible to specify static DH parameters in the certificate file, which disables generating temporary DH parameters:

openssl dhparam 2048 >> stunnel.pem

Instead of generating a new set of parameters using `openssl dhparam`, I would recommend grabbing a PEM-encoded copy of the RFC 7919 ones from

https://github.com/internetstandards/dhe_groups/ tree/26f703fe44e0b4b03840e3dc7eaacf8257f7a184

Thanks Clemens! (Sorry about the slow response.)

Could you share which RHEL version you’re using? It looks like 9 or 10 based on the OpenSSL version, but both ship the same, so it’s impossible to tell from your provided output.

I'm on Fedora 44. openssl-3.5.7-2.fc44.x86_64 stunnel-5.80-1.fc44.x86_64 -- ======================================================================== If your user interface is intuitive in retrospect ... it isn't intuitive ========================================================================

On 8/31/26 16:45, Clemens Lang wrote:

Ah, that’s a lot easier to change for me. I’ve filedhttps://bugzilla.redhat.com/show_bug.cgi?id=2526328 to track this in Fedora.

Using the RFC 7919 groups would certainly avoid the CPU cost of generating fresh DH parameters, but there is a security tradeoff. Finite-field DH permits substantial discrete-logarithm precomputation that depends only on the group modulus. Once that precomputation has been performed for a particular group, it can be reused against subsequent DH exchanges using the same group. This was demonstrated by the Logjam research: David Adrian et al., "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", CCS 2015. The concern is also explicitly recognized by IETF standards. RFC 8268 states: "Using a fixed set of Diffie-Hellman parameters makes them a high value target for pre-computation.  Generating additional sets of primes to be used, or moving to larger values mitigates this issue." RFC 4419 gives essentially the same rationale for allowing SSH servers to generate new DH groups, specifically citing the risk of extensive precomputation against fixed groups. RFC 7919 itself also acknowledges the issue in Section 8.5, noting that "Using the same groups in multiple protocols increases the value for an attacker with the resources to crack any single group." Therefore, replacing stunnel's periodically generated parameters with a globally shared RFC 7919 group would not be security-neutral. With sufficiently large groups, particularly ffdhe3072 and above, the precomputation attack is believed to be impractical, so RFC 7919 makes a reasonable engineering tradeoff. Nevertheless, periodically generating unique DH parameters does provide additional protection against this class of attack. Best regards,     Mike

Hi Alicja, On 9/2/26 11:06, Alicja Kario wrote:

Except that the precomputation is still more expensive than targetted attack for the same size of parameters.

Yes, but that is also why widespread reuse of the same group matters. For a unique or frequently replaced modulus, expensive modulus-specific precomputation has relatively little opportunity to pay for itself. For a standardized group used by a very large population of servers and implementations, the same precomputation can potentially be amortized over many targets. This is the concern described by the Logjam research. The concrete attacks demonstrated there involved substantially smaller groups, but the underlying property is not specific to 1024-bit DH.

And the arguments you quoted are about 1024 bit DH, not 2048.

The demonstrated attacks were, but the standards arguments are more general: * RFC 8268 explicitly states: "Using a fixed set of Diffie-Hellman parameters makes them a high value target for pre-computation. Generating additional sets of primes to be used, or moving to larger values mitigates this issue." * RFC 7919 similarly notes that using the same groups in multiple protocols increases their value to an attacker with sufficient resources to attack a group. Of course, this does not mean that ffdhe2048 is currently known to be practically breakable. _However, I don't think cryptographic design should be based solely on attacks that have already been demonstrated to be practical._ Security margins are intended to account for future improvements in cryptanalysis, hardware, and attacker capabilities. Periodically replacing the public DH group parameters removes the possibility of amortizing modulus-specific precomputation over a long-lived or globally shared group. That is a real hardening property, even if its practical value at 2048 bits is difficult to quantify today.

If static DH parameters were such a big issue we wouldn't have them as the _only_ option in TLS 1.3.

Agreed, for finite-field DHE. RFC 7919 groups are an entirely legitimate way to implement FFDHE, and TLS 1.3 demonstrates that this tradeoff is considered acceptable. The per-connection DH key shares are still ephemeral, while the public group parameters are fixed. I don't think that implies, however, that periodically replacing those public group parameters provides no additional protection. RFC 7919 represents a reasonable standardized security/performance tradeoff; it is not necessarily the strongest hardening an implementation can reasonably provide. More importantly, I think this discussion is drifting away from the original problem. I don't consider finite-field DHE a desirable default for stunnel in 2026. The expensive DH parameter generation became noticeable because Fedora/RHEL changed the cipher-suite configuration and enabled DHE cipher suites that upstream stunnel would otherwise have little reason to use. Given that, I would prefer not to change upstream stunnel further merely to reduce the cost introduced by that downstream configuration. If DHE is explicitly enabled, stunnel's periodically regenerated group parameters are an intentional additional hardening measure. Upstream stunnel is not required to limit its security measures to the defaults chosen by OpenSSL or by a distribution, particularly when the additional protection addresses a known cryptographic property. There is therefore no claim that RFC 7919 groups are insecure. They are standardized and considered secure. I simply don't see a compelling reason to remove an existing upstream hardening measure in order to optimize a cipher-suite configuration that I would not recommend in the first place. For Fedora/RHEL, I think the cleaner solution is to reconsider whether enabling finite-field DHE by default is still useful. Avoiding that downstream deviation would also avoid the regression without requiring another downstream or upstream change to compensate for it. Best regards,     Mike