Re: request for change handling hostStrictVeri fy
[email protected] Mon, 01 Nov 2021 08:59:25 +0100
| Newsgroups | gmane.comp.web.squid.devel |
|---|---|
| Message-ID | <38-617f9e80-1-7cdebb00@168115853> |
On Saturday, October 30, 2021 01:14 GMT, Alex Rousskov <[email protected]> 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, [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 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 [email protected] 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 _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
smime.p7s
(application/x-pkcs7-signature, 5 KB) - not displayed