Re: Alternate origin server selection
Alex Rousskov <[email protected]> Thu, 28 Oct 2021 11:41:23 -0400
| Newsgroups | gmane.comp.web.squid.devel |
|---|---|
| Message-ID | <[email protected]> |
On 10/28/21 9:24 AM, Steve Hill wrote: > For transparently proxied traffic, the client makes a connection to > www.google.com's IP address, which Squid intercepts. Squid must then > SSL-peek the request to figure out that it is connecting to > www.google.com. The onward connection can then be redirected to the > virtual IP. IIRC, Google has recommended (to my surprise) something like that as well, for environments where DNS modifications are inappropriate and bumping is possible. I cannot find that recommendation now, unfortunately. > There is code to do this: > https://github.com/squid-cache/squid/pull/924 > This allows an external ACL to record an alt-host note, or an ICAP > server to return an X-Alt-Host header, specifying a new origin server to > connect to. > > The pull request was rejected, as it adds CVE-2009-0801 vulnerabilities. > > I'm hoping for some guidance on the best way to achieve this. While I disagree with some of the assertions made in that PR review and the unilateral approach to closing that PR, I hope we can find a positive way forward here. Your use case deserves Squid support IMO. AFAICT, the primary obstacle here is that Squid pins the connection while obtaining the origin server certificate. Please confirm that without that origin server certificate you cannot make the decision whether to redirect the HTTP request. In other words, the client-intended destination IP address and the client-supplied SNI are not sufficient to correctly determine whether the connection must be bumped (in relevant cases). Also, if you need the server certificate indeed, please confirm that when the origin server uses TLS v1.3, the proposed scheme will have to fully bump the Squid-server connection before redirecting the request. Just staring at the TLS ServerHello will not be enough because the origin certificate comes later, in the encrypted records. I hope to suggest the right solution based on your feedback. Thank you, Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev