Alex Crow wrote:
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.
CONNECT requests are ONLY valid in forward proxy (outbound?).
The bug which older Squid have allowing them to happen in other modes
(accel and transparent) was fixed a while back.
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?
No it makes the URL and header available to http_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!
You appear to be in the one valid use-case for SSLBump. And in a
position to push out a local authoritative CA to the workstations
preventing the insecurity popup from appearing.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.5
