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

[Alex Rousskov]

On 10/16/2018 08:15 PM, Amish wrote:

> http_port 8080 ssl-bump ...
> http_access deny ...
> ssl_bump splice all

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

FWIW, I do not think "one would expect" can be the driving argument for
designing SslBump error handling:

* Most humans do not "expect" errors at all -- it is natural for humans
to _ignore_ errors when forming initial expectations. This is why error
handling is so difficult and/or error-prone in virtually all areas of
human endeavor.

* Most likely, it is impossible to make SslBump work correctly _and_
match the first-glance expectations of the majority of admins. One has
to either study the feature documentation (to understand how the feature
works) or use working snippets certified by someone they trust (and can
get support from). If Squid documentation is lacking, there are ways to
fix that, of course.

For example, explicit configuration of error handling via ssl_bump rules
have been attempted in the past and rejected because it makes writing
correct rules very difficult and makes the rules themselves unreadable.


> But since it already sent 200 Connection Established - there is no
> returning back.

As I had tried to explain earlier, the steps are not done in the order
you continue to imply. First, Squid discovers the error and only then it
purposefully replies with "200 Connection Established" (to be able to
deliver the error message later, when the first bumped request comes).

The described (and implemented) behavior is what many of the admins
requesting and sponsoring SslBump improvements wanted based on their
deployment experience. Your needs may be different, of course, and the
Squid Project can often satisfy conflicting needs. However, please come
to this discussion not from the "I propose to fix this obvious Squid
bug" point of view, but from the "I propose to satisfy a new use case
while still addressing other reasonable admin needs" point of view.


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

Whether forwarding errors should lead to bumped connections should not
be determined by deny_info because deny_info does not apply to many
errors. We need a mechanism that can be applied to all errors.

And again, please keep in mind that Squid decides to bump the connection
when it decides to block CONNECT. That happens _before_ Squid looks at
deny_info. Deny_info is an HTTP error adaptation mechanism. It is
orthogonal to whether the error is delivered securely to the user or
dumped on the ground by the browser.

> Also browsers not respecting code other than 200 or 407 is actually a
> browser bug. Hopefully corrected in future someday.

Very true, but based on my interpretation of browser makers' feedback on
the HTTP WG mailing list, I doubt that will happen in the foreseeable
future: Adding a proxy "security context" (in addition to the existing
"insecure" and "origin" contexts) is not a priority for them, especially
since it is only required to accommodate the needs of hated proxies.


HTH,

Alex.