[squid-users] deny_info and CONNECT for https request gives SSL error

[Alex Rousskov]

On 10/16/2018 10:01 AM, Amish wrote:
> On 16/10/18 9:05 PM, Alex Rousskov wrote:
>> On 10/16/2018 06:29 AM, Amish wrote:
>>> In my opinion correct flow should be like this:
>>>
>>> 1) Browser sends CONNECT request
>>> 2) Check ACL
>>> 3) If denied, return with 307 (or 302)
>>> 4) If allowed, go ahead with tunneling / bumping as applicable

>> Unfortunately, that ideal sequence does not work well in practice
>> because popular browsers ignore CONNECT responses other than HTTP 200
>> and 407. As a consequence, if you want to redirect "secure" browser
>> traffic, Squid has to bump it first.

> Thing is that squid behaves differently for 2 exactly same CONNECT
> request with only difference being ssl-bump

Yes, Squid behaves differently when configured differently.

* My original response was specific to SslBump-enabled Squid ports.
Today, those configurations assume that the admin wants to bump CONNECTs
on errors (and has given Squid the certificate to enable such bumping).

* For SslBump-disabled ports (which is the default), Squid has no choice
but to deny/redirect the CONNECT request itself. Denied/redirected
CONNECT requests are mishandled by popular browsers -- Squid denial
errors are not shown to the user, and redirects are not followed.

Please note that the difference is not in matching ssl_bump actions, but
in whether the corresponding http_port was configured to use SslBump. In
the former case, whether the ssl_bump rules are checked depends on the
SslBump step where the CONNECT request is denied/redirected. In the
second/default case, ssl_bump rules are never checked.


If you prefer non-SslBump behavior, you should use it, of course! Some
admins find that browser-generated errors are insufficiently detailed
and/or produce more support queries than Squid-generated errors. YMMV.

If you want to change SslBump behavior when denying or redirecting
CONNECT requests, please make a specific proposal, keeping in mind that
many existing Squid deployments depend on Squid error pages being
displayed to the user (and/or on Squid redirects followed). Your
proposal will need to either convince folks that the existing behavior
should change or add options to optionally enable some new behavior.

Alex.