Re: [squid-dev] request for change handling hostStrictVerify
On 11/2/21 4:25 AM, k...@sudo-i.net wrote: > > On Monday, November 01, 2021 14:58 GMT, Alex Rousskov > wrote: > >> On 11/1/21 3:59 AM, k...@sudo-i.net wrote: >> > On Saturday, October 30, 2021 01:14 GMT, Alex Rousskov wrote: >> >> >> 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! >> >> > Not sure what do you mean with "Somebody should carefully expand that >> > coverage to intercepted traffic"? >> >> I meant that somebody should create a high-quality pull request that >> modifies Squid source code to properly address the problem you, AFAICT, >> are suffering from. There is already code that handles similar >> situations correctly. > I will try to implement it. Please note that implementing correct changes in this area may be difficult, especially if you are not familiar with relevant Squid code and the invariants it is trying to uphold. Please do not expect the changes to be officially accepted just because they "work" in your use case. It is your call whether or how to approach this task, but if you find yourself modifying a lot of Squid code, especially code that seems mysterious, you might want to pause and sketch a solution for the discussion here on squid-dev or via a Draft PR on GitHub. HTH, 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 11/1/21 3:59 AM, k...@sudo-i.net wrote: > On Saturday, October 30, 2021 01:14 GMT, Alex Rousskov wrote: >> >> 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! > Not sure what do you mean with "Somebody should carefully expand that > coverage to intercepted traffic"? I meant that somebody should create a high-quality pull request that modifies Squid source code to properly address the problem you, AFAICT, are suffering from. There is already code that handles similar situations correctly. 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 1/11/21 20:59, kk wrote: 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, kk 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 >> >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. Your suggestion of making Squid "forces the client to go to the resolved IP" bypasses any protections the Browser might do. This would make the CVE-2009-0801 situation happen all over again. Just with SNI as the bypass method instead of Host header. 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 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
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
[squid-dev] request for change handling hostStrictVerify
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
