Re: request for change handling hostStrictVerify

On 30/10/21 11:09, Alex Rousskov wrote:
> On 10/26/21 5:46 PM, [email protected] 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

Amos