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

Adam Barth <ietf@adambarth.com> Tue, 07 December 2010 00:58 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 B472B3A68DE for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 16:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.992
X-Spam-Level:
X-Spam-Status: No, score=-3.992 tagged_above=-999 required=5 tests=[AWL=-1.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 DeJGYsepp0Cp for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 16:58:42 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 3A6043A68DA for <hybi@ietf.org>; Mon, 6 Dec 2010 16:58:42 -0800 (PST)
Received: by qyk11 with SMTP id 11so13441894qyk.10 for <hybi@ietf.org>; Mon, 06 Dec 2010 17:00:06 -0800 (PST)
Received: by 10.220.185.79 with SMTP id cn15mr1751069vcb.54.1291683605397; Mon, 06 Dec 2010 17:00:05 -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 s26sm712526vcr.37.2010.12.06.17.00.04 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 17:00:04 -0800 (PST)
Received: by iwn40 with SMTP id 40so16122868iwn.31 for <hybi@ietf.org>; Mon, 06 Dec 2010 17:00:03 -0800 (PST)
Received: by 10.231.160.78 with SMTP id m14mr6693229ibx.128.1291683603429; Mon, 06 Dec 2010 17:00:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.12.77 with HTTP; Mon, 6 Dec 2010 16:59:33 -0800 (PST)
In-Reply-To: <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> <F4C4C2F2-8D85-4020-9ACA-E02FFE8431FB@mnot.net>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 06 Dec 2010 16:59:33 -0800
Message-ID: <AANLkTi=+EmQXdm8+7wr9QmF=TXpW=UVuwyVc12JtxewN@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
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: Tue, 07 Dec 2010 00:58:43 -0000

On Mon, Dec 6, 2010 at 3:55 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Thanks; will have a read.
>
> Adam -- nice title, not a loaded question at all ;)

That title is optimized to be evocative for the program committee.  We
considered toning it down for you all.  :)

Adam


> 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/
>
>
>
>