Removal of SSLv3
Nicola Tuveri
Public
Seen by 27
The Foundation is asking the BAC’s feedback on a PR that proposes to remove support for SSLv3 entirely from the codebase, more details here: https://openssl-communities.org/d/rGYnVkxK/removal-of-sslv3
I would like to know what are our community’s views on this to report within the BAC.
Should this be done at all? Wait for 4.0 (April 2026) or would this be ok already for 3.6 (October 2025) if it qualifies for a minor release update in terms of not breaking compatibility?
Please help me represent the academics view on this matter.
Peter Gutmann Tue 22 Jul 2025 1:12PM
Just as a data point, I removed the SSLv3 code from cryptlib some years ago, and that's with a lot of embedded users that hang onto old stuff forever, and no-one has ever complained. If nothing breaks I'd say remove it from 3.6.
TLS 1.0 OTOH, that's not going to be so easy to get rid of, there's a still-supported device running TLS 1.0 a few metres from where I'm sitting.
Shubham Kumar Thu 24 Jul 2025 8:32PM
Given the long deprecation timeline and the availability of upgraded protocols, it would be best to remove at the earliest release (in my opinion, not r3.6, but maybe r3.7 instead). This would provide enough time for any legacy software still depending on it to migrate to more secure and modern alternatives. From a broader perspective, migrating to higher versions will be beneficial for the ecosystem as a whole as well.
And a pre-announcement from OpenSSL will be great in alerting the broader community and encouraging proactive upgrades.
That said, if ABI stability is a major concern, deferring the removal to 4.0 will make more sense.
Matt Caswell Fri 25 Jul 2025 7:16AM
Note that the next release after 3.6 will be 4.0. There will not be a 3.7
Shubham Kumar Fri 25 Jul 2025 6:59PM
Ohh, then removing it in r4.0 will be a better option.
Poll Created Tue 29 Jul 2025 7:23AM
Removal of SSLv3: v3.6 or v4.0? Closed Fri 8 Aug 2025 7:00AM
Compared to the early comments discussing the opportunity of completely removing the SSLv3 code, which indicated some opinions in favor for removal as soon as possible, the final poll shows unanimous preference in the Academic community for removal at the next major release (v4.0, planned for Apr 2026).
What is this poll about?
The Foundation solicited advice from the BAC about when to do this: either v3.6 or v4.0.
Why is this important?
See discussion above
What are you asking people to do?
Choose the option(s) you favor.
Results
| Results | Option | % of points | Voters | |||
|---|---|---|---|---|---|---|
|
|
v4.0 | 100.0% | 5 |
|
||
| v3.6 | 0.0% | 0 | ||||
| Undecided | 0% | 22 |
|
5 of 27 people have participated (18%)
Shubham Kumar Tue 29 Jul 2025 7:23AM
Keeping it until then (v4.0) won't be an issue at all if the final decision has already decided. To remove it, it's just a matter of when to do it. And besides, it would provide ample time to the community whoever is still using it in their legacy software to migrate to a higher version.
Lakshya Chopra Tue 29 Jul 2025 7:23AM
It's more logical to bring a breaking change in a major release than in a minor release. In the minor release, preparatory work towards removing SSLv3 could be done.
Keith Takunda Chatsauka Tue 29 Jul 2025 7:23AM
As this is a major change, I would recommend that we leave this for the official release window for v4.0 in April 2026. This vote is informed by my consultation with the good people at the University of Cape Town, as well as in my day-to-day job as a fellow at NETCB ZA (Pty) Ltd as this would afford those with legacy OpenSSL libraries in their environments an opportunity to set forth a roadmap for ensuring that they do not find themselves scrambling in October '25. I trust that this is in order!
Milan Broz · Tue 22 Jul 2025 7:01AM
Remove it, but such changes should go into major releases, here 4.0. The problem is that you can still use 3.x in obscure scenarios (compiling it yourself, for example, to access some very old, non-upgradable lab equipment). I would not expect something to disappear in a 3.x upgrade (until it is not a critical fix).