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

Re: [hybi] workability (or otherwise) of HTTP upgrade

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 09 Dec 2010 16:25:01 +1300
Message-ID: <4D004C0D.1070005@qbik.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
CC: Mark Nottingham <mnot@mnot.net>, Brian McKelvey <theturtle32@gmail.com>, Joe Mason <jmason@rim.com>, Maciej Stachowiak <mjs@apple.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>

just on the topic of making the transfer look like HTTP and use 
"infinite chunks"

I think that would pose serious problems for intermediaries that process 
content (such as border AV systems).

Adrien


On 9/12/2010 4:03 p.m., Bjoern Hoehrmann wrote:
> * Mark Nottingham wrote:
>> WebSockets, of course, does allow an untrusted script to touch the bytes
>> on the wire, and that's the problem. Adam has proposed one way of
>> dealing with this -- by using a non-routable hostname in the
>> request-line, he's hoping to jam any intercepting proxies so that
>> they'll fail early (13% of traffic, in his tests). As he points out,
>> though, this doesn't offer good security in all circumstances, and I
>> suspect there are probably a few other attacks that could leak through
>> this approach.
> (This isn't entirely accurate. There are three hosts involved here, one
> on the CONNECT line, one in the Host header of the handshake, and one in
> the attacker-controlled client->server traffic if the attacker can make
> client->server Websocket traffic look like HTTP traffic. If the server
> does not understand "CONNECT" and the attacker can control what goes
> over the wire, non-routable hostnames are no help. And there are some
> other problems.)
>
>> I'd suggest that if HYBI doesn't want to use another port (still the
>> most obvious and safest solution), you could explore in a number of
>> strategies for mitigating these flaws, while still using HTTP Upgrade.
>> For example:
> I think the working group has heard all the notable techniques, as you
> say if ultimately the browser controls all the bytes, then there is no
> risk; if the attacker cannot control bytes that are critical for any
> reasonable exploit, such as white space characters, then there is no
> plausible risk either; if we do not use ports commonly used for HTTP,
> and make initial communication look much unlike HTTP, there is also no
> plausible problem. If we never actually leave the HTTP realm, such as
> by using chunked encoding with two essentially infinite streams, then
> there is also no plausible risk; finally there are the "talisman" pro-
> posals, where you send something odd and hope for the best (Ian's "76"
> draft has a "send malformed HTTP message" approach, Adam et al. have
> the "CONNECT" approach, Dave Cridland suggests sending something that
> looks like a CONNECT request but really isn't, and there are some ping
> pong hello and goodbye proposals I haven't kept track of; there is a
> plausible risk to all of those, but it's far fetched and evidence does
> not support that there is a grave concern.
>
> What the Working Group does not have is a framework in which this can
> be resolved. If you want sendfile() client->server and server->client
> to work and want (within reason) perfect security, then there is no
> alternative to a dedicated port. If you want to use port 80 and want
> perfect security, then you can only use infinite chunks (although it
> is not entirely clear how secure that would be) or escaping/encryption.
> And so on. At the moment it seems the working group needs an overview
> of the many options that have been offered, or at least a straw poll
> to put some metrics behind how important it is to protect against the
> various attacks, or accomodate performance or compatibility require-
> ments. (Ideally we'd have some numbers along the lines of "If you do
> this, then the success rate is that" and so on, but there seem to be
> few takers to aid in that.)
Received on Thursday, 9 December 2010 03:25:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT