Re: [squid-users] Blocking SSL Port does not work

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