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

[Amish]

On 16/10/18 10:07 PM, Alex Rousskov wrote:
> On 10/16/2018 10:01 AM, Amish wrote:
>
>> 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.

So if I have following config:

http_port 8080 ssl-bump ...
acl denyit src all
deny_info http://192.168.1.1/blocked.html denyit
http_access deny denyit
ssl_bump splice all

i.e. ssl-bump enabled on port but splice everything. (test case)

In this case one would expect that squid would not bump the connection 
and return with 307 instead of 200.

But since it already sent 200 Connection Established - there is no 
returning back.
> 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.

My proposal for would be to add "-n" (nobump) option to deny_info.

If -n is specified then squid will send 307 directly instead of 200.

Case 1)
deny_info http://192.168.1.1/blocked.html denyit

Return with 200 and bump it (existing behaviour)

Case 2)
deny_info 3xx:http://192.168.1.1/blocked.html denyit

Return with 200 and bump it (existing behaviour)

Case 3)
deny_info -n http://192.168.1.1/blocked.html denyit

Return with 307 Temporary Redirect and Location: header

Case 4)
deny_info -n 302:http://192.168.1.1/blocked.html denyit

Return with 302 Found and Location: header.

Case 1 and 2 above applicable only for sslbump cases.

For non-sslbump it already behaves as 3) and 4) above.


This would not change anything for existing users who want existing 
behaviour.

But allow people like me to *NOT* bump connection when deny_info is 
activated.

Please give a thought,

Thank you,

Amish