Re: [hybi] Moving to a CONNECT-based handshake

[Adam Barth <[e-mail]>]

On Wed, Dec 1, 2010 at 12:21 PM, Roy T. Fielding <[e-mail]> wrote:
> On Dec 1, 2010, at 8:45 AM, Ian Fette (イアンフェッティ) wrote:
>> We all know that WS over port 80 faces obstacles. That's been known for a long time, nothing has changed, and yet there remains a group that wishes to try to use it. As long as the problems are known, I see no reason to try to forbid it.
>>
>> As for strong objectors, it seems like many people who are implementing have voiced strong support for adams proposal, modulo some tweaks here and there. I would like to see how far we can get.
>
> We will get nowhere.  Adam's proposal is to use CONNECT, a method specifically
> designed for telling a normal (non-intercept, non-reverse) proxy to create a
> TCP tunnel to some other host:port, and he suggest using it to do something
> contrary to its method definition and the HTTP architecture in general.
> That would violate both CONNECT semantics and the HTTP syntax for non-proxy
> requests (not to mention our hybi charter).  Please understand that such an
> abomination will not be allowed in an Internet proposed standard even if the
> browsers deployed it, and thus should be rejected out of hand.

You're assuming that the server in a WebSocket connection is an HTTP
server.  It seems entirely reasonable to regard it as a proxy instead.
 In that case, the semantics work out fine.

> Listen to the input you have received already.  The vulnerability described
> in Adam's paper has nothing to do with the Upgrade handshake -- they
> specifically did not test the actual handshake.  What they did is test the
> post-handshake non-encrypted connection for intercept proxies that might
> (in 8 out of 47,338 cases) mistakenly interpret the unencrypted channel
> after the handshake is completed (or ignored).  Thus, it represents
> an attack on any non-opaqued channel that is being scanned by caching
> intercept proxies (an architecture that is not condoned by HTTP but does
> occur in some limited practice by idiots) when a browser is allowed to
> send arbitrary bytes over that channel.

Correct.

> One question, therefore, is whether it is important to protect the 0.0169%
> of users behind networks that are deliberately using an insecure and invalid
> form of HTTP proxy from yet another attack based on that invalid usage.
> YMMV.

For better or worse, browser vendors feel responsible to protect
"idiots" (as you call them) from themselves.  You might or might not
agree with that decision, but that's unlikely to change.

[...]

> A more sensible test would have been to use a new method, like WEBSOCKET,
> since then at least the initial handshake could remain HTTP-compliant.

Unfortunately, using a new method doesn't solve any of the problems
we're currently worried about.  CONNECT, specially, is useful because
many intermediaries already have the behavior we desire when
processing CONNECT messages.

> BTW2, "transparent proxy" != "intercept proxy".  A proxy is called transparent
> when it doesn't transform the messages exchanged, unlike intercepts (which
> aren't even true proxies since they are unknown to the client).  Please use
> the correct terminology.

For what its worth, we researched this issue when writing the paper.
These terms appear to be used interchangeably by most folks, including
Wikipedia.

Adam