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
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
