[squid-users] Squid TPROXY issues with Google sites

Amos Jeffries squid3 at treenet.co.nz
Fri May 26 17:00:07 UTC 2017


On 27/05/17 03:44, Vieri wrote:
> Hi,
>
> I'd like to block access to Google Mail but allow it to Google Drive. I also need to intercept Google Drive traffic (https) and scan its content via c-icap modules for threats (with clamav and other tools which would block potentially harmful files).
>
> I've failed so far.
>
> I added mail.google.com to a custom file named "denied.domains" and loaded as denied_domains ACL in Squid. I know that in TLS traffic there are only IP addresses, so I created the "server_name" ACL as seen below.

Erm, not quite. The raw-IP having to be dealt with comes from the use of 
TPROXY (or NAT), not TLS. It is used when Squid is deciding whether to 
permit the traffic on the TCP connection to be processed.

Once the TLS is received (by "peek") the TLS SNI (if any) becomes available.


> [...]
> acl denied_domains dstdomain "/usr/local/share/proxy-settings/denied.domains"
> http_access deny denied_domains !allowed_groups !allowed_ips
> http_access deny CONNECT denied_domains !allowed_groups !allowed_ips
> [...]
> reply_header_access Alternate-Protocol deny all
> acl AllowTroublesome ssl::server_name .google.com .gmail.com
> acl DenyTroublesome ssl::server_name mail.google.com
> http_access deny DenyTroublesome
> ssl_bump peek all
> ssl_bump splice AllowTroublesome
> ssl_bump bump all
>
> First of all, I was expecting that if a client tried to open https://mail.google.com, the connection would be blocked by Squid (DenyTroublesome ACL). It isn't. Why?

Any of the http_access lines you omitted from the config snippet might 
be letting it through. Order is important, and knowing the whole 
http_access sequence (and more) is just as important to correctly answer 
a question such as this. So take the below with a grain of salt, I am 
assuming nothing else in your config has subtle effects on the 
processing outcome.

There are several things that can lead to it;

* Google servers do have working rDNS. So raw-IP becomes a server 
hostname for dstdomain ACL to match.
  - the rDNS is within *.1e1.net so will not match your list shown, but 
it is enough to possibly evade your IP rules.

* If no provides access control lines match Squid inverted the action on 
the last one and does that.
   - yours are all deny, so the implicit action there is "allow all"

* "ssl_bump peek all" fetches the TLS SNI server name for 
ssl::server_name ACL to match.
  - so by the time Squid gets to processing the AllowTroublesome it 
already knows the client is trying to reach a *.google.com domain.

> Second, I am unable to scan content since Squid is splicing all Google traffic. However, if I "bump AllowTroublesome", I can enter my username in https://accounts.google.com, but trying to access to the next step (user password) fails with an unreported error.
>
> Any suggestions?

The rest of your related squid.conf is needed for that, including 
details of the files includes into the ACLs. In particular it is not 
clear what this "unreported error" is or why it happens.

Amos



More information about the squid-users mailing list