|
Amos, thanks for info.
The primary settings being used in squid.conf: http_port 8080 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 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) betweenNo. 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. 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.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 googleAs 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 Thank you, Mike _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
