Re: Explicit proxy options and defaults

On 8/12/13 10:39 PM, Stephen Farrell wrote:
> On 12/07/2013 11:33 PM, Yoav Nir wrote:
>> Hi, Stephen
>> The choice between (2) and (3) is with the proxy.
> Maybe I wasn't being clear. Let me try again:
> If there is a reasonable (2) then I'm asking that both (2) and
> (3) be supported but for (3) to be the default.
> The explicit proxy should be just one of the players who
> can say no in this game.
>> How it communicates
>> that choice to the client is up to the group, but in any case doesn't
>> seem to matter much security-wise. Adding authentication and encryption
>> to the connection to the proxy regardless of whether it decrypts or not
>> is also a good thing.
>> Having the proxy choose (2) should not be seen as an alternative to (3).
>> (3) doesn't allow the proxy to do anything except maybe domain name
>> filtering.
> Precisely. And that (3) is the currently specified semantics for
> https via a proxy so needs to be the default.

What I'm missing in this discussion is what default means. The client 
connects to the explicit proxy. It can now either send a CONNECT (or is 
the new notation ":connect"?) or a "GET". 
One will work, the other won't, depending on the proxy. I don't see 
where defaults come into play.
> (2) is the new thing that you want to introduce where the proxy
> gets to decrypt.
>> So (2) is an alternative to the MitM proxies that require
>> installing a CA certificate and signing phony certificates. Killing off
>> those practices is a win IMO.
> Yes, one can argue that introducing (2) might help kill off the
> alternative of MITMing TLS. But equally doing away with (3) which
> we have now means weakening https:// URI security in a real sense.

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.


Received on Sunday, 8 December 2013 22:19:38 UTC