[squid-users] accessing google.com

[Philipp Wehling]

Hello,

> 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 :-(

Thats too bad. This really would be helpful.

> 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)

I dont see any line number in cache.log - even with 28,9

> 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 ...".

I dont see any of this lines either. Same with 28,9. An I forced a ACL-Block.

> 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.

This is the way im trying to find out what is causing the problems and pin down the failure.


Im using squid 3.1.22-1 on CentOS 5 - if this is important.



kind regards,
pwe

----- Ursprüngliche Mail -----
Von: "Amos Jeffries" <squid3 at treenet.co.nz>
An: "Philipp Wehling" <philipp.wehling at megatel.de>
CC: squid-users at lists.squid-cache.org
Gesendet: Montag, 13. Juli 2015 13:14:25
Betreff: Re: [squid-users] accessing google.com

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