[squid-users] acl for redirect

Mike mcsnv96 at afo.net
Fri Jun 26 18:29:25 UTC 2015


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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>



More information about the squid-users mailing list