<html><br />On Saturday, October 30, 2021 01:14 GMT, Alex Rousskov <rousskov@measurement-factory.com> wrote:<br /> <blockquote type="cite" cite="03983185-b4d1-83cc-cc12-df4a9a98527d@measurement-factory.com">On 10/29/21 8:37 PM, Amos Jeffries wrote:<br />> On 30/10/21 11:09, Alex Rousskov wrote:<br />>> On 10/26/21 5:46 PM, kk@sudo-i.net wrote:<br />>><br />>>> - Squid enforces the Client to use SNI<br />>>> - Squid lookup IP for SNI (DNS resolution).<br />>>> - Squid forces the client to go to the resolved IP<br />>><br />>> AFAICT, the above strategy is in conflict with the "SECURITY NOTE"<br />>> paragraph in host_verify_strict documentation: If Squid strays from the<br />>> intended IP using client-supplied destination info, then malicious<br />>> applets will escape browser IP-based protections. Also, SNI obfuscation<br />>> or encryption may make this strategy ineffective or short-lived.<br
/>>><br />>> AFAICT, in the majority of deployments, the mismatch between the<br />>> intended IP address and the SNI/Host header can be correctly handled<br />>> automatically and without creating serious problems for the user. Squid<br />>> already does the right thing in some cases. Somebody should carefully<br />>> expand that coverage to intercepted traffic. Frankly, I am somewhat<br />>> surprised nobody has done that yet given the number of complaints!<br /><br />> IIRC the "right thing" as defined by TLS for SNI verification is that it<br />> be the same as the host/domain name from the wrapper protocol (i.e. the<br />> Host header / URL domain from HTTPS messages). Since Squid uses the SNI<br />> at step2 as Host value it already gets checked against the intercepted IP<br /><br /><br />Just to avoid misunderstanding, my email was _not_ about SNI<br />verification. I was talking about solving the problem this thread is<br
/>devoted to (and a specific solution proposed in the opening email on the<br />thread).<br /><br />Alex.<br />_______________________________________________<br />squid-dev mailing list<br />squid-dev@lists.squid-cache.org<br />http://lists.squid-cache.org/listinfo/squid-dev</blockquote>Thanks Alex & Amos.<br /><br />Not sure what do you mean with "Somebody should carefully expand that coverage to intercepted traffic"?<br />>then malicious applets will escape browser IP-based protections.<br />Browser should perform IP-based protection on browser(client) level and should therefor not traverse squid.<br /><br /><br /><br />-- <br />Kevin Klopfenstein<br />Bellevuestrasse 103<br />3095 Spiegel, CH<br /><a href="http://sudo-i.net">sudo-i.net</a></html>