On 06/07/2013 08:51 AM, Amos Jeffries wrote: > The configuration of https_port when intercepting traffic currently > requires both the ssl-bump and one of intercept or tproxy options to be > explicitly configured. > > This alters the situation slightly to make intercept/tproxy imply > ssl-bump option and remove a likely self_destruct() call.
I do not think we should enable SslBump implicitly, for several reasons discussed below. SslBump is a rather dangerous feature with rather unusual side-effects. Requiring admins to enable ssl-bump manually moves liability from Squid developers to Squid admins (and their bosses) while increasing the chance that they actually look for SslBump documentation first. There are two typical cases for https intercept: 1. Folks that want to bump intercepted traffic. These folks will have no problem adding explicit ssl-bump token to the https_port option. 2. Folks that do not know about bumping and probably do not want it, but think that they need to intercepted HTTPS traffic to "proxy" it. These folks should not add https_port to their configuration (at least not without further consideration). Adding ssl-bump for them implicitly will often just send them on the wrong path. I have not tested this, but I suspect that after applying this patch, Squid will issue a warning to folks that do not have any ssl_bump rules (because they know nothing about SslBump): WARNING: No ssl_bump configured. Disabling ssl-bump on https_port Needless to say, the above would be rather confusing for folks that do not have ssl-bump on https_port. Moreover, the code will then undo the effects of this patch by setting flags.tunnelSslBumping to false. Furthermore, Squid is already capable of proxying intercepted SSL (and other connections) without any bumping. There is no good configuration support for that at the moment(**), but making ssl-bump implicit will prevent us from adding such support in the future. We should not lock ourselves out from that desirable enhancement. There are other reasons to avoid this change. If you disagree with my position, please document the reasons you think this change is desirable (your description says what the patch does but not why we should do it). Thank you, Alex. P.S. (**) Currently this can be configured using a combination of ssl-bump flag on the HTTPS interception port and ssl_bump none directive matching traffic on that port. Ideally, the behavior triggered by that combination should be the default for intercepted https_ports, and not what the proposed patch does. Note that ssl_bump rules may already be enabled (for an http_port) so implicitly enabling ssl-bump on https_port will tell Squid to use those existing rules while, again, the default should be to use "ssl_bump none" for that https_port.
