W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: #250 / #251 (connect bodies)

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 27 Oct 2010 23:33:59 -0700
Message-ID: <AANLkTi=wxk=7GTEDOBA=JxkqqYASRPpgkQphdFOt_Ahy@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Oct 27, 2010 at 11:13 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Use something other than port 80, since you're not speaking HTTP?
> But I digress; that's a discussion to be had when / if WebSockets goes to IETF Last Call. Back to the topic at hand:

Sure.  To answer you question: it's one of the requirements:

   REQ. 7:  The WebSocket protocol MUST allow HTTP and WebSocket
      connections to be served from the same port.


> What property are you looking for out of using the CONNECT method to the server that rules out other methods?
> What specific security vulnerabilities are raised by using Upgrade (a useful discussion to be had in any case)?

There are a lot more details in
but the high-level idea is that there a bunch of network
intermediaries that listen to traffic and think they understand HTTP.
Unfortunately, these boxes are much better at understanding
HTTP-as-she-be-spoke rather than HTTP-as-specified (to borrow a
neologism from the HTML WG).

>From CONNECT, specifically, we'd like to get WebSocket-oblivious
intermediaries to ignore the rest of the bytes on the socket.  CONNECT
lets them know that the rest of the bytes coming from the client
aren't going to be HTTP, so they shouldn't try to understand the
semantics of those bytes.

If everyone perfectly implemented HTTP-as-specified, we could use
Upgrade for that purpose because that's what Upgrade is supposed to
mean also.  Unfortunately, Upgrade is extremely rare in
HTTP-as-she-be-spoke, which means many of these intermediaries think
that the subsequent bytes sent by the client have HTTP semantics.  Of
course, in WebSockets, the attacker is given great latitude to select
bytes-on-the-wire after the handshake completes, which means the
attacker's script running in a browser can craft bytes that look a lot
like HTTP but avoid the security invariants the browser usually
imposes on script code running on behalf of a web site.

Most notably, the attacker can spoof the Host header.  If you consider
an enterprise deployment with a firewall and a transparent (Roy will
correct me that the proxy isn't technically transparent, but that's
folks call it) proxy (which is a common deployment pattern), the
attacker can sometimes get the transparent proxy to retrieve HTTP
resource otherwise protected by the firewall.  For example, stealing
product plans from an internal wiki.


> On 28/10/2010, at 5:07 PM, Adam Barth wrote:
>> That's true, but we don't know of any non-TLS WebSocket handshake that
>> connects more than about half the time.  If you want to reliably
>> connect to the server, you need to use TLS.
>> Adam
>> On Wed, Oct 27, 2010 at 11:04 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>> Intermediaries that aren't expecting CONNECT are just as likely to ignore it (i.e., many, but not all, will error out, whereas the rest will pass it through). E.g., try CONNECTing to Squid running as a transparent proxy, or against a L7 load balancer, or...
>>> Cheers,
>>> On 28/10/2010, at 4:59 PM, Adam Barth wrote:
>>>> On Wed, Oct 27, 2010 at 10:53 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>>>> On 28/10/2010, at 4:48 PM, Willy Tarreau wrote:
>>>>>> On Thu, Oct 28, 2010 at 02:14:53PM +1100, Mark Nottingham wrote:
>>>>>>> Because CONNECT is for establishing a connection to a proxy, not a gateway (which is what you're doing).
>>>>>> That's true but the semantics of the CONNECT method is the closest to what we
>>>>>> need in WebSocket. After all, we're negociating a bidirectionnal tunnel between
>>>>>> the browser and the application through the HTTP infrastructure.
>>>>> This is neither horseshoes nor hand grenades. CONNECT is unique (and badly designed, as a method) because it doesn't go through, it terminates at the proxy. Sending a CONNECT to an origin server makes no sense, and is likely to be blocked by all sorts of infrastructure.
>>>>> You'd be better off using Upgrade, which is very much designed for this use case.
>>>> Unfortunately using Upgrade for WebSockets causes security
>>>> vulnerabilities because many intermediaries don't understand its
>>>> semantics and ignore it.  On the other hand, CONNECT is widely used
>>>> and has the behavior we want.
>>>> Adam
>>> --
>>> Mark Nottingham   http://www.mnot.net/
> --
> Mark Nottingham   http://www.mnot.net/
Received on Thursday, 28 October 2010 06:35:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC