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

["Roy T. Fielding" <[e-mail]>]

On Dec 1, 2010, at 12:41 PM, Adam Barth wrote:

> 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.

No.  It could very well be a proxy, expecting to receive both valid
proxy requests (hopefully with some form of authentication) and valid
non-proxy requests.  The CONNECT semantics are clear enough to show
that your request does not follow them, and therefore will be treated
as an error.  That error will result in error logs, occasional pages
to overworked sysadmins, and in rare cases an automatic IPfw block
and a call to the FBI.  This is because CONNECT has been used in the
past by rootkit zombies to attack HTTP servers looking for open
relay proxies.

>> 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.

You aren't protecting them -- they are already vulnerable to those
attacks via POST and anything else that can send data on port 80.
At best we just avoid piling on.

It is a basic vulnerability of the browser same-origin protocol
to assume that same-IP will result in same-origin.  Combine that
with not retaining control over the Host header field (the actual
same-origin) or the application framing that determines where a
request starts, and then we have a security hole.  That hole can
be avoided for websockets by controlling the post-handshake output,
so browser vendors can happily continue to be responsible for
protecting those admin idiots who feel compelled to install
caching intercepts that don't respect HTTP/1.1 framing, even
if we don't use the proposed CONNECT handshake.

> [...]
> 
>> 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.

What makes you say that?  CONNECT sent to a proxy doesn't have the
behavior we want unless the host:port is true, and even then the
result is a pure tunnel which will need to start its own handshake.
Most proxies already limit use of CONNECT to specific ports, for
security reasons, so that it doesn't actually get around the firewall
limitations.  CONNECT sent to an origin server doesn't work any
better than a new method.

Changing the method to WEBSOCKET doesn't change the security
characteristics of encrypting the subsequent content, since we
can do that more easily with a new method.

>> 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.

Most folks don't write Internet standards based on protocols that
already contain a different definition for "transparent proxy" (one which
we plan on replacing with "non-transforming proxy" just because of
that confusion).  We use the term intercept because it has no other
confusing-yet-standard definition.

....Roy