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