Re: Explicit proxy options and defaults

On Sun, Dec 8, 2013 at 2:19 PM, Yoav Nir <synp71@live.com> wrote:

> Whereas for servers people can argue that TLS is a small part of the cost,
> for a proxy, decrypting and re-encrypting is a huge part. The bandwidth
> that a proxy can support is likely 10 times greater for CONNECT vs GET.
> People will never do the GET unless there is a very good reason that
> justifies the cost, and if such a reason exists (filtering, caching), they
> won't agree to CONNECT at all.
>
>
So, I think we largely agree on this, but that the way you have stated
makes it hard to tease out.  Let me test my understanding with a slight
reformulation:

A proxy can be configured to either act on a flow or to allow a flow to
pass.  If it is configured to allow a flow to pass, it will support CONNECT
for that flow (for example, an enterprise might require all flows pass
through a proxy, but permit CONNECT for targets within its own
administrative domain).  If it is configure to act, it must decrypt any
encrypted flow before acting, then re-encrypt the result after the action
(e.g. in order to log a communication's content).  Because the latter is
more expensive, it is not often the default, but when it is required,
CONNECT will never be substituted for it.

Is that a fair reformulation of your point?

If so, I tend to agree, with two caveats:  because the whole system tends
to be more heavyweight in support calls this configuration set is more rare
than it should be; there are cases where the second configuration is the
overall default (because it is simpler to configure and there is no
capacity constraint for that particular system).

To return to Stephen's point, I don't see any harm in declaring CONNECT to
be the default semantic, but I agree that there is a clear need to improve
the other proxy semantics.  If an explicit proxy can only tell a client on
a per destination basis that it doesn't support CONNECT, using it will mean
a big performance penalty much of the time.

Ted


> Yoav
>
>
>