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

[Amish]

On 29/12/22 22:32, Alex Rousskov wrote:
> On 12/29/22 10:41, Amish wrote:
>> 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).
>
>> What is plain text "GET https" request?
>
> It is an unencrypted HTTP GET request arriving at http_port and using 
> an https URI scheme in its target URI. These requests are relatively 
> rare, mostly seen in environments where specialized HTTP clients 
> outsource TLS work to their forward proxies.
>
>
>> 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.
>
> I share that hope, but cannot guarantee success.

Thanks for the info.

>
>>> 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.
>
> Why would adding such a new directive be better than committing the 
> createClientContext(true) change that you have tested? AFAICT, such a 
> commit would enable the old directive to do what the new directive is 
> meant to do. Just like a new directive, this commit will break either 
> peek or stare cases (depending on the problematic origin server).
>
> The only advantage I see is that the new directive you propose would 
> allow to preserve the old configuration behavior, but since that 
> behavior is wrong/exceptional/surprising, I doubt it is worth 
> preserving long-term (which is what adding such a new directive would 
> do).

I do not know what createClientContext() actually does. I thought it was 
just a way to test your theory.

If you tell me the starting point then I may try to look at the code and 
try to implement your minimal way to fix it.

In the mean time, do you think this bug needs to be reported as an issue 
on Github? I can do that.

Thanks and regards,

Amish.

>> 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
>
> IMO, Squid support for multiple tls_outgoing_options directives is
>
> * poor (and probably buggy)
> * unnecessary (one can always get the same result without it)
> * a configuration design mistake (we should have prohibited it)
> * significantly complicates fixing/enhancing the underlying code
>
>
> > Hope there is no plan to remove that feature(!) in future else my
> > scripts will break.
>
> If it were my call, it would have been removed (while fixing the 
> problem you have reported on this thread): It is better to adjust your 
> scripts (a one-time pain) than suffer from this mistake long-term. It 
> is _not_ my call, and Squid is full of other features that cause 
> ongoing pains and complicate progress because it is very difficult to 
> reach consensus that something should be _removed_.
>
>
> Cheers,
>
> Alex.
>
>
>
>>> 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.
>
>
>>> 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 
>>>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users