[squid-dev] Alternate origin server selection

[Alex Rousskov]

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.