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

[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

[squid-dev] request for change handling hostStrictVerify

[kk]

Hi Guys!
Sorry I was unsure if this was the correct point of contact in regards to 
hostStrictVerify.

I think I am not the only one having issues with hostStrictVerify in scenarios 
where you just intercept traffic (tls) and squid checks the SNI if the IP 
address from the Client is the same as squid resolve it. The major issue in 
that approach is that many services today change their DNS records at a very 
high frequency, thus it's almost impossible to make sure that client and squid 
do have the same A record cached.

My Proposal to resolve this issue would be the following:
- Squid enforces the Client to use SNI! (currently, this is not done and can be 
considered as a security issue, because you can bypass any hostname rules)
- Squid lookup IP for SNI (DNS resolution).
- Squid forces the client to go to the resolved IP (and thus ignoring the IP 
which was provided in the L3 info from the client)

Any thoughts?


many thanks & have a nice day,

Kevin

-- 
Kevin Klopfenstein
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