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

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

From: Adam Barth <ietf@adambarth.com>
Date: Thu, 25 Nov 2010 22:54:07 -0800
Message-ID: <AANLkTimwiGKdy2eHve9eDezMZg+duuK-AMWpeCR4GH3m@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, hybi <hybi@ietf.org>
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
>
Received on Friday, 26 November 2010 06:55:16 GMT

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