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

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/