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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
