On 8/06/2013 3:36 a.m., Alex Rousskov wrote:
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.
Okay, yes it would be.
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.
No. Please look at the if-statements which this patch is altering again.
if (hijacked && !s->flags.tunnelSslBumping) {
...
self_destruct();
}
There is no way to configure working interception for 3.3+ on https_port
without "ssl-bump" flag being present as well.
Bit of a problem.
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).
The intention of this patch was to make your "Furthermore," argument
case actually work.
You have shown why it wont work (ssl_bump access list checks also halt
the proxy, and more reliance on the ssl-bump hack). But we still need
something to do that.
Amos
