Hi Ian, hi Mike,
On 24. Aug 2026, at 13:49, Michał Trojnara <[email protected]> wrote:
A few years ago, the Red Hat/Fedora stunnel packaging was changed to use the system-wide crypto policy as the default cipher configuration:
https://gitlab.com/redhat/centos-stream/rpms/stunnel/-/blob/c10s/stunnel-5.6...
This third-party patch changes stunnel's default cipher list to PROFILE=SYSTEM. Since the system crypto policy enables finite-field DHE cipher suites, stunnel's existing code detects that DHE is available in your server-mode frontend sections and generates temporary 2048-bit DH parameters.
Thanks for bringing that to my attention. This is indeed unfortunate, since we enable FFDHE system-wide in the assumption that implementations use RFC 7919 (i.e., the well-known FFDHE parameters from its Appendix A) rather than generating new parameters at runtime. We can’t disable FFDHE now in existing releases, because it would break compatibility. I brought this up with my team, and we agree that we’ll probably drop FFDHE from the DEFAULT policy in RHEL 11 completely.
The parameters are generated when the per-day worker starts and regenerated every 24 hours. The 100 ms poll() calls you are seeing come from a delay in stunnel's OpenSSL DH-generation progress callback. The delay is there to throttle CPU usage during DH parameter generation.
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/26f703fe44e0b4b03840e3d... These also have the advantage that they’ll definitely work in FIPS mode, which is not a given for locally generated groups. I’ll look into maybe replacing the generation with the static RFC 7919 groups instead downstream, but no promises on that one. 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. Clemens -- Clemens Lang RHEL Crypto Team Red Hat