[squid-dev] Moving from Bump-Server-First to Bump/Peek/Splice

[Alex Rousskov]

On 09/11/2015 11:38 AM, Steve Hill wrote:
> 
> I'm currently using Bump-Server-First, but I'm fiddling with
> Bump/Peek/Splice and have uncovered some compatibility problems with the
> way I'm currently doing things, so I'm hoping for some advice:
> 
> 
> To enforce Google's Safe Search, Google recommends setting up a CNAME in
> the local DNS server to redirect requests for www.google.com to
> forcesafesearch.google.com.

It may important that Google wants you to modify the IP address of
www.google.com, not the domain name itself. CNAME is there for DNS
administration convenience, but from HTTP/SSL/browser point of view, the
connection is still to something named www.google.com.

What you are doing with CONNECT rewrite is different (even if it works
or used to work).


> A DNS change like that would apply to the
> whole network and I want to only apply it to certain users, so I'm doing
> this a slightly different way: The "CONNECT www.google.com" request gets
> sent to an ICAP REQMOD method, which rewrites it to "CONNECT
> forcesafesearch.google.com", causing Squid to connect to the appropriate
> IP address.  The rest of the request behaves as though the connection
> was to www.google.com - i.e. the HTTP requests within the bumped
> connection appear as https://www.google.com/... etc.
> 
> With Bump-Server-First, this works ok - the CN and SANs are copied from
> Google's original certificate into the forged cert, so as far as the
> browser is concerned the certificate is valid for www.google.com.

I suspect this works because the [old] server-first bumping code does
not send [correct] SNI to Google. You should be able to confirm or deny
that by studying SSL packets. SNI and server certificate are a part of
unencrypted handshake so it is easy to look at what Squid receives and
sends.

Note that things may change. See, for example, Squid bug 4293 which
required us to fix SNI to match the rewritten domain name. I do not know
whether that fix affects the [old] server-first bumping code and your
use case.


> However, with the new Bump functionality, the CN of the forged
> certificate appears to come from the (rewritten) CONNECT request

At least two very different scenarios would result in the forged
certificate having forcesafesearch.google.com CN:

1. Squid receives www.google.com CN from Google, but uses
forcesafesearch.google.com CN in the forged certificate. This is what
you think is happening.

2. Squid receives forcesafesearch.google.com CN from Google and uses it
in the fake certificate. This is what I suspect may be happening.

Again, you can easily check this by looking at the Squid-Google SSL
handshake with wireshark or some such.


> Is there a better way of doing what I'm doing?

I think so, but it requires some development. Instead of rewriting
CONNECT requests in ways that Google does not want you to do, I would do
what Google suggests -- rewrite the IP address. Specifically, I would
allow the eCAP/ICAP adapter to leave the CONNECT request "as is" but
tell Squid what IP address to use when satisfying that request, as if
that IP came from a DNS server when resolving the CONNECT host name.

With this solution, no SslBump would be required at all!

A high-quality implementation would have to address things like DNS
caching, IPv6, and cache_peers, but I think it would be a generally
useful feature.


> What is the reasoning behind the change to using the name from the
> CONNECT string, rather than copying it from the server's certificate, or
> have I misconfigured something?

The reason to use a CONNECT name would be to match browser expectations
(the code may not realize that it is looking at the rewritten CONNECT).
I know we do that in recent code when serving Squid errors. However,
let's revisit this question after you confirm that #2 is not happening.


> A related second question is that obviously when transparently proxying
> traffic, the host name isn't available in the CONNECT request, so the
> above rewrite method doesn't work anyway.  I'm using an external ACL at
> Bump Step 2 to look at the SNI that's obtained from the client handshake
> and decide whether to bump - is there any way for the external ACL to
> change the IP address that Squid will connect to, to replicate the
> rewrite above?

I do not think so, but this functionality can be added. It is very
similar to the eCAP/ICAP solution I proposed above (before I read your
suggestion here), and it would use the same existing transaction
metadata mechanism with the external ACL. Alternatively, you can
continue to use eCAP/ICAP for transparent connections -- they generate
fake CONNECT requests that are sent to adaptation services...


> Also, I've noticed that the "%un" external ACL format code is never
> being filled with the user name when calling an external ACL during bump
> step 2, even though the request has been authenticated.

If the TCP connection has been authenticated, then this is a bug and you
should file a bug report.

If you are talking about HTTP authentication methods that authenticate
individual transactions and not whole connections (e.g., Basic), then
there is no HTTP at SslBump step #2 yet.


> Any advice gratefully received, looks like I'm spending next week
> working through these issues. :)

You may get more advice on the squid-users list, where there are
probably more folks facing similar problems.


HTH,

Alex.