Re: [squid-dev] request for change handling hostStrictVerify
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-dev
Re: [squid-dev] request for change handling hostStrictVerify
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 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
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! HTH, Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] Alternate origin server selection
On 10/29/21 9:57 AM, Steve Hill wrote: > Ok, I've gone back and looked over my old debug logs. It appears what > was actually happening was: > > - Client sends "CONNECT www.google.com:443". > - Connection with TLS made to forcesafesearch.google.com. > - Client sends "GET / HTTP/1.1\r\nHost: www.google.com" > - Squid runs the peer selector to find peers for www.google.com (i.e. > the host contained in the GET request). > - It finds the appropriate pinned connection: > client_side.cc(3872) borrowPinnedConnection: conn28 > local=81.187.83.66:52488 remote=216.239.38.120:443 HIER_DIRECT FD 18 > flags=1 > - Squid then logs: > FwdState.cc(472) fail: ERR_ZERO_SIZE_OBJECT "Bad Gateway" > https://www.google.com/ > FwdState.cc(484) fail: pconn race happened > FwdState.cc(494) fail: zero reply on pinned connection The above looks like a persistent connection race, way after SslBump bumped the connections. This kind of races seem unrelated to everything we have discussed on this thread so far, but I may be missing something. > Unfortunately, I cannot reproduce this problem now. Well, if you want to reproduce it, you probably can do that using a custom origin server, but I do not see the point: There is nothing particularly "wrong" in the above sequence AFAICT; races happen. However, it is possible that the above log is lying or misleading, and there was actually a different problem, a problem related to previous discussions, but it manifested itself as ERR_ZERO_SIZE_OBJECT "pconn race happened" diagnostic. > I can remove the unpinning code and submit a new pull request, which now > works ok for me. But I'm very wary that I did originally have problems > with that which I can no longer reproduce. Unfortunately, I did not have a chance to study the rejected pull request before it was rejected, so I cannot advise you on whether subtracting something from that pull request will result in changes that should be, in principle, accepted. I suggest to imagine that the rejected pull request did not exist (instead of using it as a starting/reference point) and then describe the problem and the proposed solution from scratch. You can do that here or via a new pull request. The best avenue may depend on whether your code changes alter some key Squid principles. If they do, it might be best to get an agreement on those changes here, but GitHub discussions have better access to code and better formatting abilities. Cheers, Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
