Re: [hybi] Upgrade Mechanism and HasMat (was Re: Extensibility mechanisms?)

Greg Wilkins <gregw@webtide.com> Mon, 26 July 2010 01:38 UTC

Return-Path: <gregw@webtide.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 F19983A6846 for <hybi@core3.amsl.com>; Sun, 25 Jul 2010 18:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.728
X-Spam-Level:
X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 1gq2LsrbbLcv for <hybi@core3.amsl.com>; Sun, 25 Jul 2010 18:38:13 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 5AFC53A6831 for <hybi@ietf.org>; Sun, 25 Jul 2010 18:38:13 -0700 (PDT)
Received: by fxm1 with SMTP id 1so6474027fxm.31 for <hybi@ietf.org>; Sun, 25 Jul 2010 18:38:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.122.208 with SMTP id m16mr5638345far.88.1280108313187; Sun, 25 Jul 2010 18:38:33 -0700 (PDT)
Received: by 10.223.112.129 with HTTP; Sun, 25 Jul 2010 18:38:33 -0700 (PDT)
In-Reply-To: <0E002C06-7F95-47D3-AA86-17DCC13905EF@apple.com>
References: <AANLkTims1er0Rbv0ysP4gRs1Kd0He8hapHeJ3nON=JQa@mail.gmail.com> <4C47C5B0.3030006@caucho.com> <AANLkTi=ND-FOH8OoD=TCbiyeSZ-h0LhxQBXN5w-2hfvj@mail.gmail.com> <20100722055452.GL7174@1wt.eu> <AANLkTik_rpxo=1OfzHkwpC5soQG_NxvGuZNXx7gdhVTh@mail.gmail.com> <20100722064945.GM7174@1wt.eu> <AANLkTim7AsQGSwLE51uktj=B1vB6roZChAtDoCrE6fFG@mail.gmail.com> <4C47FF71.3050000@ericsson.com> <18E0FF9C-6C51-4602-92E1-E44802D0D8B5@gbiv.com> <4C481C76.1060907@ericsson.com> <20100722121317.GA12582@1wt.eu> <0E002C06-7F95-47D3-AA86-17DCC13905EF@apple.com>
Date: Mon, 26 Jul 2010 11:38:33 +1000
Message-ID: <AANLkTimDqGJBz9RmBkLp60r98HM7XYaP-40n5v7Xme4H@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: multipart/alternative; boundary="001636c5b3734816ba048c4071f8"
Cc: "Roy T. Fielding" <fielding@gbiv.com>, "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Upgrade Mechanism and HasMat (was Re: Extensibility mechanisms?)
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, 26 Jul 2010 01:38:15 -0000

On 23 July 2010 02:46, Maciej Stachowiak <mjs@apple.com> wrote:

> I originally suggested computing a hash of the nonce with other data (or
> some other nontrivial computation) rather than just echoing it back.
>

Maciej,

I agree that avoiding a simple echo would be very good protection against
almost all forms of injection attack.

I think the handshake request contains a random token generated after the
URL has been passed to the browser. The handshake response could then
contain a random token generated after the connection has been accepted,
plus a simple hash of the combination of the request and response tokens.

This would allow a client to validate that the server had performed
websocket specific calculations (in addition to sending a 101 response) and
appears to address all the same security concerns that the current space
counting and random bytes do.

I beleive these tokens and hash should be  carried in normal HTTP headers
for the upgrade handshake, and that other mechanisms should be considered to
address the fast fail detection of non-ws handling intermediaries.


regards