Re: [hybi] workability (or otherwise) of HTTP upgrade
Mark Nottingham <mnot@mnot.net> Mon, 06 December 2010 23:54 UTC
Return-Path: <mnot@mnot.net>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529913A68D7 for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 15:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.634
X-Spam-Level:
X-Spam-Status: No, score=-104.634 tagged_above=-999 required=5 tests=[AWL=-2.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyFzfDhE9iXq for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 15:54:32 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id DF7D43A68DB for <hybi@ietf.org>; Mon, 6 Dec 2010 15:54:31 -0800 (PST)
Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 34E8B22E253; Mon, 6 Dec 2010 18:55:48 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <221B3DED-A3CC-4961-9CCF-48B6EBCB241F@apple.com>
Date: Tue, 07 Dec 2010 10:55:45 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4C4C2F2-8D85-4020-9ACA-E02FFE8431FB@mnot.net>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <AANLkTimwiGKdy2eHve9eDezMZg+duuK-AMWpeCR4GH3m@mail.gmail.com> <AB6151A1-A334-469F-BC74-1FA73E6B689A@mnot.net> <221B3DED-A3CC-4961-9CCF-48B6EBCB241F@apple.com>
To: Maciej Stachowiak <mjs@apple.com>
X-Mailer: Apple Mail (2.1082)
Cc: hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Dec 2010 23:54:33 -0000
Thanks; will have a read. Adam -- nice title, not a loaded question at all ;) Cheers, 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/
- [hybi] workability (or otherwise) of HTTP upgrade Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… Jamie Lokier
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Dave Cridland
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Joe Mason
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Brian McKelvey
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Jack Moffitt
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Collin Jackson
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… SM
- Re: [hybi] workability (or otherwise) of HTTP upg… Pat McManus @Mozilla
- Re: [hybi] workability (or otherwise) of HTTP upg… Scott Ferguson
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Gabriel Montenegro
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Martin J. Dürst
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… James Graham
- Re: [hybi] workability (or otherwise) of HTTP upg… Michael
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu