[squid-users] accessing google.com

[Amos Jeffries]

On 13/07/2015 10:39 p.m., Philipp Wehling wrote:
> Hello,
> 
> thank you for your answer.
> 
>> This is where you really do need to understand the 28,3 debug output.
> 
> I thought squid works in a "first-match"-manner... Do you have any documentation, I can read about?

Nothing that woudl be helpful Im afraid. Cleaning it up and writing a
how-to blog has been on my todo list for years now :-(

Its currently a matter of following the trace and eyeballing what it
says its doing vs what your squid.conf contains.

The debugs output should show you the squid.conf line its processing,
then the 0/1/-1 (aka fail, pass, async-delay) results of each individual
test run for that line.
Then the line result action 0/1/-1 (aka allow, deny, dunno/skip)


> 
>> That is of course following your assumption that Squid is actively rejecting the traffic with ACLs (you provide no evidence of that).
> 
> How can I proof that? When the error comes up, I get the default ACL-Block-Page.

The debugs trace will result in a deny action in one of the access
control lines. Which then logs something like "Request for ... DENIED
due to ...".

There are other things forbidden by the protocol, or errors that can
happen which Squid just responds with a DENIED page to. No ACL
processing required for that to happen.

> 
>> Chances are rather high these days that it has nothing to do with Squid since Google prefer to use HTTPS, QUIC, SPDY, or HTTP/2 protocols. All of which normally bypass Squid processing entirely.
> 
> That answer is interesting, because we have some company (blocking) policies regarding drive.google.com and everything works fine. How is it possible, that google.com bypasses these rules? Please give me more hints for my investigation.
> 

They hard-code the Chrome web browser and other apps or scripts they
produce to try the other protocols first when connnecting to their own
servers. HTTP messages coming out of their servers also contain headers
such as Alternative-Protocol or Alt-Svc requesting the cleint software
uses non-HTTP protocols.

The latest release of Squid automatically strip the HTTP headers away on
related responses. You still have to also firewall block ports UDP/443
and UDP/80 to avoid QUICK protocol. Only HTTPS decryption will prevent
HTTP/2, SPDY, and WebSockets usage since they are either inside TLS or
CONNECT tunnels.

Amos