Re: [hybi] workability (or otherwise) of HTTP upgrade
Mark Nottingham <mnot@mnot.net> Tue, 07 December 2010 02:47 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 8FF4B3A68E7 for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 18:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.685
X-Spam-Level:
X-Spam-Status: No, score=-104.685 tagged_above=-999 required=5 tests=[AWL=-2.086, 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 bNmjg5ISTsNz for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 18:47:15 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 1A9AA3A68E5 for <hybi@ietf.org>; Mon, 6 Dec 2010 18:47:14 -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 A90F122E258; Mon, 6 Dec 2010 21:48:32 -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 13:48:28 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D81508A6-F8A7-4481-AF23-9BAA300A5ADB@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: Tue, 07 Dec 2010 02:47:16 -0000
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/
- [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