Remove SSLv3 support #2255

yadij · 2025-09-23T12:26:40Z

This protocol has been deprecated for over 10 years.
Support has also been broken for all OpenSSL v3 users these past
4 years and nobody noticed.

Comply with RFC 7568 requirement to prohibit negotiation of
SSLv3. We technically do not need to take this extra step, but
it ensures consistent behaviour regardless of which OpenSSL
library version is used.

This protocol has been deprecated for over 10 years. Complete the compliance of RFC 7568 requirement to prohibit negotiation of SSLv3.

rousskov · 2025-09-23T13:25:48Z

src/security/PeerOptions.cc

+#if defined(SSL_OP_NO_SSLv3)
+    // compliance with RFC 7568: Prohibiting Secure Sockets Layer (SSL) Version 3.0
+    if (SSL_OP_NO_SSLv3)
+        op |= SSL_OP_NO_SSLv3;


I am not convinced we should make this "no SSLv3" decision for Squid admins, especially since Squid is quite often used to "upgrade" legacy clients and servers. The vast majority of existing Squid builds do not support SSLv3 today because OpenSSL builds disable SSLv3 by default since OpenSSL v1.1.0. Folks that use OpenSSL v1.0 today¹ probably do not want to disable SSLv3, but even they can already disable SSLv3 in their Squid configurations and/or OpenSSL builds.

We could support disabling SSLv3 by default while giving admins an option to overwrite that Squid default, but I am not convinced there is enough demand to implement that feature. And if we are really serious about disabling SSLv3 (where it is supported by an OpenSSL build), then adding that feature would require cooperating on developing a new suitable configuration interface for this -- just using SSL_OP_NO_SSLv3 when no other options were configured would not be good enough; that additional complexity raises the bar for supporting "disabling SSLv3 by default while giving admins an option to overwrite that Squid default" idea.

I would support warning admins if their Squid instance allows SSLv3 use (if we can detect that state reliably).

Footnotes

Assuming master/v8 still builds with OpenSSL v1.0. ↩

Squid is quite often used to "upgrade" legacy clients and servers

You have already imposed the design decision earlier this year that this use-case for Squid is no longer valid, to justify removal of Gopher protocol and other older code.

Squid is quite often used to "upgrade" legacy clients and servers

You have already imposed the design decision earlier this year that this use-case for Squid is no longer valid, to justify removal of Gopher protocol and other older code.

I have not imposed any design decisions.

FWIW, our (IMO, correct) decision to remove Gopher code does not imply we should add code to prohibit SSLv3 support.

Squid is quite often used to "upgrade" legacy clients and servers

You have already imposed the design decision earlier this year that this use-case for Squid is no longer valid, to justify removal of Gopher protocol and other older code.

I have not imposed any design decisions.

You proposed removal of a feature and ensured it was removed for design reasons, despite my objections that said protocol had/has actively growing usage. Ergo you imposed a design decision. Specifically to stop officially supporting translation from legacy protocols to HTTP.

FWIW, our (IMO, correct) decision to remove Gopher code does not imply we should add code to prohibit SSLv3 support.

Reasons for code removal should be applied consistently for all code meeting the stated criteria. Ergo, for the "legacy protocol" and "unsolvable security issues" criteria used for removing protocol "Gopher" we have this PR for removing protocol "SSlv3".

SSLv3 has:

major security issues that cannot be solved.

officially prohibited ("MUST NOT be negotiated") over 10 years ago.

an actively declining support worldwide.

under 1.5% support. That is just being available on a server, actual usage is far less.

I see the merit in @yadij 's position here. RFC7568 dates back to June 2015; given the age, I would not expect that there are many clients dating so far back in the past that cannot speak to Squid in TLS 1.0 or later. Do we have any hard evidence to the contrary?

Furthermore, any change here would get distributed with Squid v7, which should be scheduled to start beta in late 2026 (we didn't explicitly tie up that discussion, but that's for another thread) and is likely to be felt by real-world users probably sometime in mid 2027; 12 years should be enough to deprecate a functionality, isn't it?

@kinkie, AFAICT, your comment supports a "position" that nobody is attacking -- we all agree that SSL is old, insecure, and rarely used. SSL is also not supported by a typical Squid installation these days (as detailed in my change request).

The vast majority of existing Squid builds do not support SSLv3 today because OpenSSL builds disable SSLv3 by default since OpenSSL v1.1.0.

So ... Squid has silently stopped supporting SSLv3 since 4 years ago without anyone noticing. One more argument for merging this PR change.

rousskov · 2025-09-23T14:02:13Z

src/security/PeerOptions.cc

    }
-
-    if (sslVersion > 2) {
-        // backward compatibility hack for sslversion= configuration


FWIW, I support removing deprecated and undocumented version=X parameter because it would simplify Squid code quite a bit. I assume that such a removal would still allow admins to achieve the same configuration using an options=Y parameter. That assumption would need to be validated.

That version=X parameter removal can be done in this PR. This PR already has the necessary changes (or most of them -- I did not check carefully).

FTR; This is how SSLv3 is enabled by admin for legacy installs (i.e. sslversion=3) forces Squid to negotiate SSLv3 regardless of BCP 195 requirements.

I am struggling to find a way to connect your statement to my change request. Are you implying that admins would not be able to force SSLv3 negotiations using options=Y parameter after version=X parameter¹ is removed?

Footnotes

In the context of this thread, version=X refers to all parameter name variations that configure sslVersion data members. Depending on the directive being parsed, Squid recognizes "version", "tlsversion", "tls-version", and "sslversion" spellings (at least²). AFAICT, those spelling differences are immaterial here. ↩

git grep -E 'strncmp.*"(tls|ssl)-?"' ↩

To meet your suggested "giving admins an option to overwrite that Squid default" would be to leave this configuration option in place. Just requiring it to be set to re-enable SSLv3 now, instead of auto-enabling with a manual disable.

@yadij how about we do just that in Squid 8 and remove in 9?

To meet your suggested "giving admins an option to overwrite that Squid default" would be to leave this configuration option in place.

I did not suggest that. I actually said that "I am not convinced there is enough demand to implement that feature" and noted implementation complexities. In short, I suggested not to add that feature.

I am still struggling to understand whether sslversion=X removal would still allow admins to achieve the same configuration using options=Y parameter(s). It seems like a simple/straightforward question, but I am probably missing the reason why there is no answer on this change request thread.

To meet your suggested "giving admins an option to overwrite that Squid default" would be to leave this configuration option in place.

I did not suggest that.

You did. I cut-and-pasted that quote from your comment in the other review thread.

I am still struggling to understand whether sslversion=X removal would still allow admins to achieve the same configuration using options=Y parameter(s).

If the only PR action taken is removing sslversion= the answer would be yes. In official code that option is just appending a few hard-coded values to any options= setting.

Removal of support for options=NO_SSLv3 by this PR means that the sslversion= values 4/5/6 are no longer able to be replaced fully by options=. But, the change to hard-code NO_SSLv3 restores that.

Which leaves sslversion=3. That officially disables all TLS verisons, forcing SSLv3 as the only potential choice of transport for TLS/SSL connections. without doing anything to ensure that SSLv3 works or is even available from the used openssl.

Remove SSLv3 support

3b13db0

This protocol has been deprecated for over 10 years. Complete the compliance of RFC 7568 requirement to prohibit negotiation of SSLv3.

rousskov requested changes Sep 23, 2025

View reviewed changes

rousskov added the S-waiting-for-author author action is expected (and usually required) label Sep 23, 2025

yadij added S-waiting-for-reviewer ready for review: Set this when requesting a (re)review using GitHub PR Reviewers box S-waiting-for-more-reviewers needs a reviewer and/or a second opinion and removed S-waiting-for-author author action is expected (and usually required) labels Sep 24, 2025

rousskov added S-waiting-for-author author action is expected (and usually required) and removed S-waiting-for-reviewer ready for review: Set this when requesting a (re)review using GitHub PR Reviewers box labels Sep 24, 2025

yadij added S-waiting-for-reviewer ready for review: Set this when requesting a (re)review using GitHub PR Reviewers box and removed S-waiting-for-author author action is expected (and usually required) labels Sep 25, 2025

yadij requested a review from rousskov September 25, 2025 02:40

rousskov removed their request for review November 6, 2025 19:01

rousskov added S-waiting-for-author author action is expected (and usually required) and removed S-waiting-for-reviewer ready for review: Set this when requesting a (re)review using GitHub PR Reviewers box labels Nov 6, 2025

Merge branch 'master' into rfc7568-1

5234347

yadij requested a review from rousskov November 11, 2025 12:58

yadij added S-waiting-for-reviewer ready for review: Set this when requesting a (re)review using GitHub PR Reviewers box and removed S-waiting-for-author author action is expected (and usually required) labels Nov 11, 2025

kinkie approved these changes Nov 11, 2025

View reviewed changes

Remove SSLv3 support #2255

Are you sure you want to change the base?

Remove SSLv3 support #2255

Uh oh!

Conversation

yadij commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rousskov Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yadij Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

yadij commented Sep 23, 2025 •

edited

Loading

rousskov Sep 23, 2025 •

edited

Loading

yadij Nov 11, 2025 •

edited

Loading