Nevermind... I found another fix within e2guardian:
etc/e2guardian/lists/urlregexplist
Added this entry:
# Disable Google SSL Search
# allows e2g to filter searches properly
"^https://www.google.[a-z]{2,6}(.*)"->"http://www.google.com/webhp?nord=1";
This means whenever google.com or www.google.com is typed in the address
bar, it loads the insecure page and allows e2guardian to properly filter
whatever search terms they type in. This does break other aspects such
as google toolbars, using the search bar at upper right of many browsers
with google as the set search engine, and other ways, but that is an
issue we can live with.
On 6/26/2015 5:12 AM, Amos Jeffries wrote:
On 26/06/2015 8:40 p.m., FredB wrote:
Mike, you can also to try the dev branch https://github.com/e2guardian/e2guardian/tree/develop
SSLMITM works now. The request from the client is intercepted, a spoofed certificate supplied for
the target site and an encrypted connection made back to the client.
A separate encrypted connection to the target server is set up. The resulting
http dencrypted stream is then filtered as normal.
If that order of operations is correct then the e2guardian dev have made
the same mistake we made back in Squid-3.2. client-first bumping opens a
huge security vulnerability - by hiding issues on the server connection
from the client it enables attackers to hijack the server connection
invisibly. This is the reason the more difficult to get working
server-first and peek-n-splice modes exist and are almost mandatory in
Squid today.
Amos
_______________________________________________
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
