Re: [hybi] workability (or otherwise) of HTTP upgrade
Adam Barth <ietf@adambarth.com> Fri, 26 November 2010 06:53 UTC
Return-Path: <ietf@adambarth.com>
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 9EF823A69CC for <hybi@core3.amsl.com>; Thu, 25 Nov 2010 22:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Level:
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[AWL=-1.723, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 GW9Y1ozP7D9G for <hybi@core3.amsl.com>; Thu, 25 Nov 2010 22:53:38 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 1E6F33A697A for <hybi@ietf.org>; Thu, 25 Nov 2010 22:53:38 -0800 (PST)
Received: by gyb13 with SMTP id 13so869696gyb.31 for <hybi@ietf.org>; Thu, 25 Nov 2010 22:54:40 -0800 (PST)
Received: by 10.101.10.27 with SMTP id n27mr1325122ani.238.1290754480218; Thu, 25 Nov 2010 22:54:40 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id b26sm1142023anb.33.2010.11.25.22.54.38 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Nov 2010 22:54:38 -0800 (PST)
Received: by iwn40 with SMTP id 40so2116825iwn.31 for <hybi@ietf.org>; Thu, 25 Nov 2010 22:54:37 -0800 (PST)
Received: by 10.231.12.2 with SMTP id v2mr1076359ibv.3.1290754477593; Thu, 25 Nov 2010 22:54:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.12.77 with HTTP; Thu, 25 Nov 2010 22:54:07 -0800 (PST)
In-Reply-To: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com>
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>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Fri, 26 Nov 2010 06:53:39 -0000
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 >
- [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