Re: [PATCH] https_port interception options

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.
Received on Fri Jun 07 2013 - 15:36:56 MDT