Re: [squid-dev] Alternate origin server selection

[Alex Rousskov]

On 10/28/21 12:39 PM, Steve Hill wrote:
> On 28/10/2021 16:41, Alex Rousskov wrote:
>> AFAICT, the primary obstacle here is that Squid pins the connection
>> while obtaining the origin server certificate.

> Well, I can't see why Squid needs the origin certificate - it should be
> able to make a decision off the SNI before connecting to the origin server.

Squid does not "need" any of this, of course. Configuration and/or bugs
force Squid to do what it does. If your decision-making process does not
involve the certificate, then you should be able to rewrite the fake
CONNECT request during SslBump step2, without (or before) telling Squid
to stare at the certificate (and pin the resulting connection).

There are bugs in this area, including bugs that may prevent certain
CONNECT adaptations from happening. We are fixing one of those bugs
right now. For details, you can see an unpolished/unofficial pull
request at https://github.com/measurement-factory/squid/pull/108


> I didn't seem to be able to make the decision prior to the connection
> being pinned though.  I'm not sure why - I will go back and investigate
> further.

Sounds like a plan!


Cheers,

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

[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.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev