OpenSSL mission vs legacy systems
I see time and time again that low security enforcement is protected from changes because of breaking support in legacy systems and I have trouble understanding how that relates to the OpenSSL mission:
“We believe everyone should have access to security and privacy tools, whoever they are, wherever they are or whatever their personal beliefs are, as a fundamental human right.”
For example in the case of RSA key lengths:
“However this would break even more legacy use cases. To allow them but not allow generating insecure keys by default these minimum (and possibly maximum) key sizes should be made configurable.”
https://github.com/openssl/project/issues/809
I understand that said legacy systems are the “.., whoever they are, wherever they are or whatever their personal beliefs are,..” part of the mission statement.
But in my mind “.. everyone should have access to security and privacy tools ..” means that we deliver something that actually IS secure to use.
Is there a strategy for dealing with these security issues or are they dealt with case by case?
Am I the only one feeling that we sometimes try to serve some use cases which in reality doesn’t make sense?
Clemens LangMon 30 Mar 2026 10:35AM
I agree that we should move forward with raising the floor, but I'd advocate for doing this through configuration (and then updating the default config) over hardcoding something. Doing this via configuration
allows tightening these settings without updating to a newer OpenSSL version, e.g., in response to new research on cryptographic algorithms
provides a path for users that just need to interact with some legacy hardware that doesn't support anything newer, and therefore a path out of "OpenSSL is just broken, guess I won't update"
matches what OpenSSL does for the TLS stack, where this is configurable, e.g. using the `ciphers` and `cipersuites` settings and `SECLEVEL`
allows distributions to ship with the settings that work for them depending on their release cycle (e.g., Fedora with a release every 6 months probably wants a different default config from RHEL, which doesn't want to break compatibility and needs to live with a config for 10 years)
I did make an initial attempt quite a while ago in https://github.com/openssl/openssl/pull/19084, but it seems we couldn't agree whether this should go into provides or core, and I didn't have the time to keep pushing on this. Maybe we should re-visit this, and also expand the scope (hello scope creep!) a bit to not only cover digests used in signatures?
Richard Levitte (individual) ·Thu 26 Mar 2026 1:55PM
A policy that spells out under what conditions algorithms will move from the default / fips providers to the legacy provider would probably be a good step forward in this regard.