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?
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.
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?
Josef EdwardsThu 9 Apr 2026 10:32PM
So how about those atomics for some reason?
Frederik Wedel-HeinenSat 18 Apr 2026 7:25PM
https://github.com/openssl/technical-policies/pull/118
For anyone who is interested: I’ve prepared a policy for dealing with removal. I don’t know if I was able to cover all the bits from this discussion so please feel free to leave a review.
Peter GutmannThu 23 Apr 2026 2:15AM
A belated comment on Viktor's observation that security improves by "raising the ceiling, rather than the floor" based on a situation I ran into last week, in some cases the floor is made of poured concrete and will never be raised. EAP-PEAP/TLS/TTLS uses as it's de facto standard shared-secret auth MSCHAPv2, which needs MD4 and (single) DES, and it's not going away... probably ever. And this isn't on ancient legacy systems, it's on stuff shipping right now running on the latest hardware and software (kinda odd seeing an ML-KEM-initiated tunnel being used to carry MD4 hashes). So you need to at least have the ability to re-enable some of this cruft even if it's, well, cruft.
Frederik Wedel-Heinen ·Thu 26 Mar 2026 10:37AM
As I state in the original post I do understand that we can’t pull the plug tomorrow but I’m looking for the strategy to support the mission.
I gather from this discussion that: yes we do care and have the legacy provider that supports some segregation and compile time configs that supports another type of segregation.
Now what I am missing is perhaps an overview over what and how to understand which decisions have been made and which have not been made. This relates very much to Jon’s comment about transition plans and education.
Would it be worthwhile to have some sort of documentation about this? I can prepare something which could serve as a starting point.