Amos,
I'm not clear on SSLBump too. It appears to be documented as a feature
for passing HTTPS traffic to an ICAP server for further analysis and
It converts incoming CONNECT requests into reverse-proxy HTTPS requests
for Squid to work with the internal encrypted details.
OK. I presume that means it can still be used in an outbound proxy
situation to the internet at large.
Bit fuzzy what you mean here. But I think so. Once the request is
converted Squid gets access to the encrypted URL and HTTP headers for
access controls.
rule/acl sets like, eg:
acl proxysearches url_regex -i google.*\?q\=proxy
http_access deny proxysearches
With SSLBump does http_access need to be replaced with something else,
eg https_access?
I did not think that was the case - does it not generate certs for the
requested websites on the fly, and if you've installed the CA cert in
Dynamic cert generation is in the pipeline. For now users without CA certs
installed see the HTTPS insecurity popup when they get Squid self-signed
cert.
Excellent!
Intercepting HTTPS without the users knowledge and consent is still
man-in-middle.
I am aware of that. Ethically I think it is between grey and wrong to
routinely check all users browsing habits, so the logs at the most (no
content) would only really be used in cases of suspected abuse of the
corporate network or external parties. The conditions of employment (in
the staff handbook) at work already make it clear to users that
monitoring may be used in certain situations. It is my intention to also
get HR to add a specific clause to alert them before we ever deploy any
kind of MITM (and for the legal dept. to verify it is OK). TBH I don't
like any kind of filtering but sadly when the company got over 50
employees a few people started muddying the waters and the "trust-based"
policy just got taken advantage of.
the client browser the only difference the user will notice is that the
issuer is different to what they get, say, at home?
Yes.
Amos
Thanks very much,
Alex
