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

[Adam Barth <[e-mail]>]

2010/12/1 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.

Hopefully the FBI will learn to ignore these calls and focus on more
important issues.

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

The browser's same-origin policy does not make that assumption.
Java's does, however, and it is indeed a security problem for Java.

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

Are you referring to WebSockets or some other browser feature?  One of
the security invariants browsers enforce is the integrity of the Host
header.

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

That's true.  Alternatively, we can use CONNECT to achieve the same goal.

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

The empirical evidence we collected as part of the experiment we conduced.

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

Indeed.  If you read the handshake proposal, that's exactly what we suggest.

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

It seems like you're talking about improving how often the handshake
succeeds in non-attack scenarios.  That's a separate issue.  The
empirical evidence that we've collected suggests that the
CONNECT-based handshake completes roughly as often as the
Upgrade-based handshake.  Of course, both completion rates are
relatively low.  For high completion rates, folks will want to use
TLS.

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

We can encrypt subsequent content with the same degree of ease with
either 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.

Fortunately our paper is not an Internet standard.  :)

Adam