[squid-users] LEGACY_SERVER_CONNECT, ALLOW_UNSAFE_LEGACY_RENEGOTIATION does not work - SSL bump, OpenSSL 3

[Amish]

On 29/12/22 20:23, Alex Rousskov wrote:
> On 12/28/22 23:17, Amish wrote:
>
>> But now what?
>
> If your Squid never peeks at origin servers (i.e. it always stares) 
> and your proxy never serves/secures plain-text "GET https" requests, 
> then you can run with the createClientContext(true) hack until 
> somebody volunteers a long-term solution (as discussed below).

Yes it always stares. So current hack will work for mr. Just that I can 
not use squid shipped by Arch Linux and will have to compile is manually.

What is plain text "GET https" request?

I do use squid as intercept proxy for http (port 80) and https (port 443 
and stare bump). I hope above hack will not break that.

> There are several ways to fix this bug long-term, including these two:
>
> Minimal: Create a TLS context object dedicated to peeking at origin 
> servers. It will probably have to be admin-configurable to accomodate 
> various TLS v1.2 (and earlier) corner cases, but we can try to start 
> without adding support for such configuration. Continue to use the 
> existing configurable context for staring and other needs but call 
> createClientContext(true) for that existing context.

I wish I could code it. But I have no idea about TLS and OpenSSL APIs 
and also squid code.

I believe as more people switch to OpenSSL 3.0, we will see more people 
(using sslbump) complain about squid not connecting to unpatched origin 
servers.

I think easiest option to tackle this issue could be to have 
tls_outgoing_sslopflags directive which gets applied (ORed) to all SSL 
(peek, stare, splice) connections. And then those who wants squid to be 
able to connect to unpatched origin server can set it to 0x4. And then 
we do not need above hack. Peek and stare both will continue to work as 
it is currently.

If it is acceptable solution then I may try my hands on creating PR if 
it is not too complicated.

> Flexible: Replace tls_outgoing_options with tls_outgoing or a similar 
> directive that supports ACLs. The new directive must be used once for 
> each set of context configuration parameters (unlike  the existing 
> tls_outgoing_options that could be (mis)used multiple times, 
> accumulating some parameters and overwriting others). At configuration 
> time, Squid will create as many TLS context objects as there are 
> tls_outgoing directives. At runtime, Squid will evaluate ACLs and pick 
> the right context object for the current outgoing TLS connection 
> attempt. For example, you would be able to configure Squid to use one 
> context for peeking at servers and another for staring at them.

I thought squid (intentionally) supported multiple tls_outgoing_options. 
I had asked that question long back.

http://lists.squid-cache.org/pipermail/squid-users/2018-July/018582.html

Hope there is no plan to remove that feature(!) in future else my 
scripts will break.

> Unfortunately, even the minimal solution requires non-trivial 
> development work. I do not have enough free time to give you a 
> ready-to-use blueprint for its implementation.
>
> https://wiki.squid-cache.org/SquidFaq/AboutSquid#how-to-add-a-new-squid-feature-enhance-of-fix-something 
>
>
> HTH,
>
> Alex.

Thank you very much again

You have been of great help.

Regards,

Amish.