Re: [hybi] Insight you need to know: Browsers are at fault when servers crash

Willy Tarreau <w@1wt.eu> Mon, 26 July 2010 07:55 UTC

Return-Path: <w@1wt.eu>
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 51AE43A6A74 for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 00:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=-1.812, BAYES_20=-0.74, HELO_IS_SMALL6=0.556]
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 HS8ZHXjx1YUa for <hybi@core3.amsl.com>; Mon, 26 Jul 2010 00:55:33 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 1BA713A6A73 for <hybi@ietf.org>; Mon, 26 Jul 2010 00:55:32 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o6Q7tnxI007651; Mon, 26 Jul 2010 09:55:49 +0200
Date: Mon, 26 Jul 2010 09:55:49 +0200
From: Willy Tarreau <w@1wt.eu>
To: Adam Barth <ietf@adambarth.com>
Message-ID: <20100726075549.GB7263@1wt.eu>
References: <AANLkTilfxps1wWjFrwrH_3Js6Q9E331AMKFRNHfeHcdL@mail.gmail.com> <AANLkTi=vPAnnK0=gE=YN10vt9b-f6sWXXcwK+La5SriO@mail.gmail.com> <623C6D70-B4AF-49EC-BA07-6F90BD0FFFBF@apple.com> <AANLkTi=Q-PVrdaWuOu3H=wUiphe6JB4C+LauSOXKozoY@mail.gmail.com> <AANLkTi=Z-Zw3gJAdwQMAqG5UUVnV_kgsGm3M_qQ2Bwt7@mail.gmail.com> <8B47440C-7CFD-442F-94E3-96A8EBE7D25D@apple.com> <AANLkTimRo_ubic96z3VgwexiOw0KJg10HQedmcuBs6jp@mail.gmail.com> <FA3856A4-FF29-430E-8BE4-3049F1E33A03@apple.com> <AANLkTim14YJgikfeU9k84xMqtcFt0cdqJQZcsNmvt-Eo@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AANLkTim14YJgikfeU9k84xMqtcFt0cdqJQZcsNmvt-Eo@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] Insight you need to know: Browsers are at fault when servers crash
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 07:55:34 -0000

Hi Adam,

On Mon, Jul 26, 2010 at 09:39:22AM +0200, Adam Barth wrote:
> Mike wanted to know if there was any way to avoid the round-trip in
> the current handshake (I think he views round-trips as quite
> expensive).  That leaves us with the following requirements:
> 
> 1) Zero round trips.
> 2) We can't send attacker-controlled bytes to the server before the
> server proves it understands web sockets.
> 
> So how can we start sending content before hearing back from the
> server?  The idea is to encrypt the bytes using a key that a WebSocket
> server can derive but that look uniformly at random to a non-WebSocket
> server.  The easiest way to do this is for the client to send the
> server a nonce and then for the client and server to hash that nonce
> with a GUID that identifies the WebSocket protocol to generate an
> encryption key.  You can then encrypt the attacker's content using
> that key (e.g., using AES, RC4, or whatever you like).
> 
> Now, I should say this give slightly weaker security properties than a
> handshake that waits for the server to opt-in.  For example, if the
> server falls over (or generates print jobs) when it receives random
> bytes, then we'll still get in trouble, but limiting the attacker to
> random bytes reduce the attack surface significantly.  It's probably
> also a good idea to limit how much data we're willing to send before
> hearing back from the server, but this idea allows some flexibility
> beyond zero.
> 
> There isn't really any dependency between the format of the handshake
> and this trick for saving the round-trip.  You can build the entire
> handshake using this idea so that the server only receives
> random-looking bytes, but, as Maciej mentions, that makes it difficult
> to share with an HTTP server.  You can also this this idea at the end
> of an HTTP-like handshake to get started sending data without waiting
> for the server to reply.

This principle sounds good, and in my opinion would be compatible with
Greg's proposal of putting the nonce in a request header. Basically the
client chooses a random key, advertises it as a nonce and can start
sending data encrypted with that key. It must then check once the server
responds that the hash of the key that confirms its will to use it
for all data past the headers.

Willy