On 24/03/2012 12:21 a.m., Michał Wiącek wrote:
Hello,
I have small problem with configuring squid as transparent filtering
gateway for http/https in my local Network.
I redirected on firewall all http https to my squid host, and http working,
https not .
"tranparent filtering". Now there is a contradiction in terms.
* transparent - invisible / non-changing / undetectable
* filtering - adaptation / changing
You seem to be speaking of a interception gateway filter.
SSL was designed to prevent man-in-the-middle attacks (aka interception)
from being done.
I know that problem with ssl is that it have to connect to destination
Server not to squid host, but is there any way to pass connections trough
squid (i do not want intercept, i want fully ssl connection to destination
point, but with filtering urls)?
This is not possible. The URL is inside the encryption. You must decrypt
the traffic in order to even see the URL.
Also, you have already intercepted it. Simply by passing the packets to
Squid in the first place you are violating the TCP connection layers
guarantee of delivery to the original destination.
If i configure broswer to use .pac scripts it is working (but i not want
that, have many programs hardwere who need connect and can not configure
proxy (and what Reed be able connet in different places)),
Then use WPAD on your network and configure the browser to
"auto-detect". The browser can then be moved between networks without
any further configurations and will use whatever proxy it can find with
WPAD/PAC on wherever it gets plugged in.
without
configuring broswer my redirecting not working , in log for ssl connections
i have NONE/400 3632 NONE error:invalid-request - NONE/- text/html
I do not want filter https on firewall cause i want authenticate users by
Authentication does not work on intercepted traffic. Whether it is
intercepted HTTP or intercepted HTTPS or anything else. The proxy is
sitting in the middle of what should be a direct two-party connection
between the browser and the web server. Any browser worth trusting *will
not* give private user credentials to an MITM third-party listening in
on the connection.
The best you are going to get is session *authorization* based on some
non-login criteria.
ldap (by the way my firewall CPU is at limit now)
Using the firewall to redirect traffic to Squid, which passes it back
out through the firewall will *double* the firewall load.
If anyone have have good idea pls share and maybe paste some example
WPAD and PAC. That avoids the firewall load doubling, allows proper
authentication, allows SSL processing by Squid, and leaves the browser
able to be moved seamlessly between networks.
Amos
