Re: [PATCH] https_port interception options

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
Received on Mon Jun 17 2013 - 06:10:31 MDT