Re: [squid-dev] request for change handling hostStrictVerify

2021-11-01 Thread kk

On Saturday, October 30, 2021 01:14 GMT, Alex Rousskov 
 wrote:
 On 10/29/21 8:37 PM, Amos Jeffries wrote:
> On 30/10/21 11:09, Alex Rousskov wrote:
>> On 10/26/21 5:46 PM, k...@sudo-i.net wrote:
>>
>>> - Squid enforces the Client to use SNI
>>> - Squid lookup IP for SNI (DNS resolution).
>>> - Squid forces the client to go to the resolved IP
>>
>> AFAICT, the above strategy is in conflict with the "SECURITY NOTE"
>> paragraph in host_verify_strict documentation: If Squid strays from the
>> intended IP using client-supplied destination info, then malicious
>> applets will escape browser IP-based protections. Also, SNI obfuscation
>> or encryption may make this strategy ineffective or short-lived.
>>
>> AFAICT, in the majority of deployments, the mismatch between the
>> intended IP address and the SNI/Host header can be correctly handled
>> automatically and without creating serious problems for the user. Squid
>> already does the right thing in some cases. Somebody should carefully
>> expand that coverage to intercepted traffic. Frankly, I am somewhat
>> surprised nobody has done that yet given the number of complaints!

> IIRC the "right thing" as defined by TLS for SNI verification is that it
> be the same as the host/domain name from the wrapper protocol (i.e. the
> Host header / URL domain from HTTPS messages). Since Squid uses the SNI
> at step2 as Host value it already gets checked against the intercepted IP


Just to avoid misunderstanding, my email was _not_ about SNI
verification. I was talking about solving the problem this thread is
devoted to (and a specific solution proposed in the opening email on the
thread).

Alex.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-devThanks Alex & Amos.

Not sure what do you mean with "Somebody should carefully expand that coverage 
to intercepted traffic"?
>then malicious applets will escape browser IP-based protections.
Browser should perform IP-based protection on browser(client) level and should 
therefor not traverse squid.



-- 
Kevin Klopfenstein
Bellevuestrasse 103
3095 Spiegel, CH
sudo-i.net


smime.p7s
Description: S/MIME cryptographic signature
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev


Re: [squid-dev] request for change handling hostStrictVerify

2021-11-01 Thread Amos Jeffries

On 1/11/21 20:59, kk wrote:


On Saturday, October 30, 2021 01:14 GMT, Alex Rousskov wrote:

On 10/29/21 8:37 PM, Amos Jeffries wrote:
> On 30/10/21 11:09, Alex Rousskov wrote:
>> On 10/26/21 5:46 PM, kk wrote:
>>
>>> - Squid enforces the Client to use SNI
>>> - Squid lookup IP for SNI (DNS resolution).
>>> - Squid forces the client to go to the resolved IP
>>



 >then malicious applets will escape browser IP-based protections.
Browser should perform IP-based protection on browser(client) level and 
should therefor not traverse squid.


Your suggestion of making Squid "forces the client to go to the resolved 
IP" bypasses any protections the Browser might do.


This would make the CVE-2009-0801 situation happen all over again. Just 
with SNI as the bypass method instead of Host header.


Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev


Re: [squid-dev] request for change handling hostStrictVerify

2021-11-01 Thread Alex Rousskov
On 11/1/21 3:59 AM, k...@sudo-i.net wrote:
> On Saturday, October 30, 2021 01:14 GMT, Alex Rousskov wrote:
>> >> AFAICT, in the majority of deployments, the mismatch between the
>> >> intended IP address and the SNI/Host header can be correctly handled
>> >> automatically and without creating serious problems for the user. Squid
>> >> already does the right thing in some cases. Somebody should carefully
>> >> expand that coverage to intercepted traffic. Frankly, I am somewhat
>> >> surprised nobody has done that yet given the number of complaints!

> Not sure what do you mean with "Somebody should carefully expand that
> coverage to intercepted traffic"?

I meant that somebody should create a high-quality pull request that
modifies Squid source code to properly address the problem you, AFAICT,
are suffering from. There is already code that handles similar
situations correctly.

Alex.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev