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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 7 Dec 2010 13:48:28 +1100
Cc: Adam Barth <ietf@adambarth.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D81508A6-F8A7-4481-AF23-9BAA300A5ADB@mnot.net>
To: Maciej Stachowiak <mjs@apple.com>
There's really very little information about Upgrade in that paper; only:

1) Speculation that "many organisations are likely to deploy network intermediaries that fail to implement the Upgrade mechanism..." without any research to support this assertion, and

2) An experiment that shows that *one* Upgrade-based design is insecure. 

I also note that the failure rates for CONNECT vs. Upgrade are almost identical in his experiments.

Cheers,

P.S. Intercepting proxies usually only mess with port 80. Food for thought...

P.P.S. Overall, though, good paper.



On 07/12/2010, at 10:27 AM, Maciej Stachowiak wrote:

> 
> Adam posted his paper to the hybi list a few days ago, it is available here:
> 
> http://www.adambarth.com/experimental/websocket.pdf
> 
> I'd like to see more detail on the data than is found in the paper, but it seems to show a real-world hazard with use of Upgrade, since many intermediaries do not understand it and at least a few are confused into treating subsequent traffic as additional HTTP requests and responses.
> 
> - Maciej
> 
> On Dec 6, 2010, at 3:17 PM, Mark Nottingham wrote:
> 
>> Adam --
>> 
>> It seems to me we can't really make any progress until we see that the assertion in your first sentence is true; it's certainly possible to construct an insecure use of Upgrade, but that doesn't prove that it's impossible to use it securely.
>> 
>> Any chance of getting that report?
>> 
>> Regards,
>> 
>> 
>> On 26/11/2010, at 5:54 PM, Adam Barth wrote:
>> 
>>> Using Upgrade for WebSockets is insecure in practice.  My colleagues
>>> and I have run an experiment using live traffic on the Internet and
>>> have successfully exploited a number of users using an Upgrade-based
>>> handshake (our exploit is harmless by proves the concept).  I'm still
>>> getting clearance from some affected vendors before releasing a report
>>> on the experiment publicly.  It's looking like I'll be able to release
>>> the report within a week.
>>> 
>>> Upgrade might well be useful for other purposes, and I think
>>> definition in HTTP is fine.  The problem is that not everyone
>>> implements Upgrade properly, which leaves room for an attack to
>>> leverage an Upgrade-based WebSockets handshake in attacks.
>>> 
>>> Kind regards,
>>> Adam
>>> 
>>> 
>>> On Thu, Nov 25, 2010 at 9:06 PM, Greg Wilkins <gregw@webtide.com> wrote:
>>>> I'm cross posting this message to both the hybi (websockets) and
>>>> http-bis mailing list as I think this is an issue that is very
>>>> relevant to both groups.
>>>> 
>>>> The hybi/websocket protocol, as currently proposed, has a handshake
>>>> mechanism that is roughly based on the HTTP upgrade mechanism.
>>>> Progress in the hybi/websocket mailing has ground to a halt because we
>>>> appear unable to get a clear consensus between the two advocated ways
>>>> forward:
>>>> 
>>>> 1) Make the "roughly based" HTTP upgrade mechanism a fully compliant
>>>> HTTP upgrade.
>>>> 2) Move away from HTTP upgrade and use another mechanism (potentially
>>>> CONNECT or SSL extensions)
>>>> 
>>>> To paraphrase the arguments against 1), there are some that are
>>>> concerned that an Upgrade based handshake will never be able to be
>>>> adequately secured against cross protocol attacks from ws-browsers to
>>>> non ws-servers. Also there is some concern that intermediaries might
>>>> not well support Upgrade and that other mechanisms might have a higher
>>>> success rate.
>>>> 
>>>> So I thought that it would be good to move that discussion from hybi
>>>> to HTTP-bis so we can stall progress here.... no I mean so that we can
>>>> get a wider view on the capabilities and vulnerabilities that might
>>>> apply to Upgrade.
>>>> 
>>>> My understanding is that Upgrade was included in HTTP for precisely
>>>> the reason that Websocket wishes to use it - ie to take an existing
>>>> HTTP connection and to upgrade the protocol run over the connection to
>>>> something with different capabilities than HTTP.
>>>> I would also expect that if there are problems with lack of Upgrade
>>>> support in intermediaries, then it would be easier to get
>>>> intermediaries to be updated to a standard generic HTTP mechanism
>>>> rather than some special purpose usage of CONNECT.
>>>> 
>>>> If websocket is unable to securely use Upgrade, then there must be
>>>> some fundamental flaw in Upgrade that should either be fixed in
>>>> httpbis (if allowed by the charter).   If Upgrade cannot be fixed,
>>>> then perhaps httpbis needs to somehow deprecate the mechanism and we
>>>> can look together for alternatives?
>>>> 
>>>> So I'd ask the httpbis readers, are there any reasons you know of that
>>>> would prevent Upgrade being used for websocket?
>>>> And I'd ask the hybi upgrade sceptics if they could perhaps voice
>>>> their concerns about Upgrade in more detail than my paraphrasing
>>>> above.
>>>> 
>>>> regards
>>>> _______________________________________________
>>>> hybi mailing list
>>>> hybi@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/hybi
>>>> 
>>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 7 December 2010 02:49:08 GMT

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