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
Received on Fri Jul 09 2010 - 17:17:30 MDT
This archive was generated by hypermail 2.2.0 : Sun Jul 11 2010 - 12:00:03 MDT