Amos, thanks for info.
The primary settings being used in squid.conf:
http_port 8080
# this port is what will be used for SSL Proxy on client browser
http_port 8081 intercept
https_port 8082 intercept ssl-bump connection-auth=off
generate-host-certificates=on dynamic_cert_mem_cache_size=16MB
cert=/etc/squid/ssl/squid.pem key=/etc/squid/ssl/squid.key
cipher=ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:AES128-SHA:RC4-SHA:HIGH:!aNULL:!MD5:!ADH
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid_ssl_db -M 16MB
sslcrtd_children 50 startup=5 idle=1
ssl_bump server-first all
ssl_bump none localhost
Then e2guardian uses 10101 for the browsers, and uses 8080 for
connecting to squid on the same server.
Yet what is happening is there is the GET, then CONNECT and the tunnel
is created, never allowing squid to decrypt and pass the data along to
e2guardian, I suspect Google has changed their settings denying any
proxy from intercepting, because we can type the most foul terms which
are in the "bannedssllist" for e2guardian and literally nothing is
filtered at all on google, nor youtube. Yet other secure sites like
wordpress, yahoo, and others are caught and blocked, so it is just
google owned sites that are not.
More below...
On 6/24/2015 6:36 AM, Amos Jeffries wrote:
On 24/06/2015 11:03 a.m., Mike wrote:
We have a server setup using squid 3.5 and e2guardian (newer branch of
dansguardian), the issue is now google has changed a few things around
and google is no longer filtered which is not acceptable. We already
have the browser settings for SSL Proxy set to our server, and squid has
ssl-bump enabled and working. Previously there was enough unsecure
content on Google that the filtering was still working, but now google
has gone 100% encrypted meaning it is 100% unfiltered.
Maybe, maybe not.
What is happening
is it is creating an ssl tunnel (for lack of a better term) between
No. That is the correct and official term for what they are doing. And
"CONNECT tunnel" is the full phrase / name for the particular method of
tunnel creation.
their server and the browser, so all squid sees is the connection to
www.google.com, and after that it is tunneled and not recognized by
squid or e2guardian at all.
BUT ... you said you were SSL-Bump'ing. Which means you are decrypting
such tunnels to filter the content inside them.
So what is the problem? is your method of bumping not decrypting the
Google traffic for Squid access controls and helpers to filter?
Note that DansGuardian and e2guardian being independent HTTP proxies are
not party to that SSL-Bump decrypted content inside Squid. ONly Squid
internals and ICAP/eCAP services have access to it.
I found a few options online that was used with older squid versions but
nothing is working with squid 3.5... Looking for something like this:
acl google dstdomain .google.com
deny_info http://www.google.com/webhp?nord=1 google
As you said Google have gone 100% HTTPS. URLs beginning with http:// are
not HTTPS nor accepted there anymore. If used they just get a 30x
redirect to an https:// URL.
Amos
This is why we are thinking we can force the redirect, if you have ides
on how to do that. All google pages use the secure aspect, except when
that http://www.google.com/webhp?nord=1 is used, it forces use of the
insecure pages, and allows e2guardian filtering to work properly.
Thank you,
Mike
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
