[squid-users] Squid TPROXY issues with Google sites

[Alex Rousskov]

On 05/28/2017 05:40 AM, Vieri wrote:

> Please keep in mind that I'm basically an end-user, a sys-admin. I
> wish I had the time to study Squid's source code.

Nobody (certainly not me) has suggested anything that requires studying
Squid source code. If you think that I have, you have misinterpreted
what I have said.


> The cache log reports errors but they are not necessarily related to
> this client as there are many others actively browsing.

I recommend triaging this using a Squid instance isolated from all other
traffic. You are making both your job and the job of those who are
trying to help you more difficult by trying to save a few minutes/hours
that are usually required to set up an isolated test.


> Anyway, as a workaround I'm willing to splice/tunnel traffic to
> accounts.google.com *ONLY*, and bump everything else (although I'd
> prefer to understand why bumping isn't "working" for this site).

> I've tried this:

> acl GoogleAccounts ssl::server_name accounts.google.com
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump splice GoogleAccounts
> ssl_bump bump all

> However, traffic to accounts.google.com is not spliced, it's bumped
> like the rest.

You need to figure out why. Two common reasons are SSL-level errors and
http_access denials. Both should be reflected in access.log and
debugging cache.log.


> Can FQDNs be used in ACLs as in the example above even when peeking at step 1?

Yes. They may not work, but they can be used. They should work if the
request contains TLS SNI. Modern browser requests usually do, but you
can confirm by studying browser-Squid traffic with a tool like Wireshark.


> If I peek at step 2 then I won't be able to "bump all"

Correct.


> Likewise, If I need to stare at step 2 then I'll never be able to splice

Correct.


Alex.