Re: [hybi] Redesigning the Web Socket handshake

Justin Erenkrantz <justin@erenkrantz.com> Wed, 03 February 2010 06:37 UTC

Return-Path: <justin.erenkrantz@gmail.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 871533A6870 for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 22:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.985
X-Spam-Level:
X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 H9TBLQPU9BN4 for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 22:37:11 -0800 (PST)
Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by core3.amsl.com (Postfix) with ESMTP id 57C653A67E6 for <hybi@ietf.org>; Tue, 2 Feb 2010 22:37:11 -0800 (PST)
Received: by ywh39 with SMTP id 39so2689967ywh.17 for <hybi@ietf.org>; Tue, 02 Feb 2010 22:37:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=nnkUUIob66Ciw+T5xJlyBHTG6GfVMPYcP/cVLY+m/+g=; b=TjpiIB/yl5E9ymZTKGlTNHtSJdzpsJ9SJP+qiTnzkhxiSj8d7piSWzlxCBDdBY96e3 Wgeq4fIN+9mVVAQtG+6UaBD6JVwEczy+tn1GXbftqoAFzJc7PVaCPT4/Co9VsBZ+3dDp SKZaZIueuESQl6xBAwIKn1MVWyEDdD0yipS+4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Uflsfq+yAXFsYxwsN6RqaYiLIfU7srVFruKxZA+Pt+3ygReZ7hdx5gZCdDYh5ot93Y rXuhPEI70CwjCxzSGgoCstLEkEnQFmnkFXah7YzJDwOLsQUMCxyWhCxZGwjMtKbPZEtp rjWG3IbWptNJmRZgijt436qEELhF/rXWSgtfI=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
Received: by 10.91.203.4 with SMTP id f4mr3820858agq.68.1265179068692; Tue, 02 Feb 2010 22:37:48 -0800 (PST)
In-Reply-To: <9A862D96-FD32-4532-BDBE-AAC5C82DB954@apple.com>
References: <Pine.LNX.4.64.1002012305000.21600@ps20323.dreamhostps.com> <4B676E8C.70804@webtide.com> <Pine.LNX.4.64.1002020311030.3846@ps20323.dreamhostps.com> <4B679E2C.2080502@webtide.com> <FD440FEA-9F53-4F4C-8AA5-98B23318F0F7@apple.com> <5c902b9e1002021431w25768b2eu4e21244f080bed25@mail.gmail.com> <9A862D96-FD32-4532-BDBE-AAC5C82DB954@apple.com>
Date: Tue, 02 Feb 2010 22:37:48 -0800
X-Google-Sender-Auth: 743feb672700bcd7
Message-ID: <5c902b9e1002022237x1a7da5e6pd2b7d1ec7d95581e@mail.gmail.com>
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Redesigning the Web Socket handshake
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: Wed, 03 Feb 2010 06:37:12 -0000

On Tue, Feb 2, 2010 at 9:22 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Let me start by laying out the security risks in the current handshake. Then I will explain my proposed change and how I believe it addresses them.

Thanks!  For the security stuff, I think it's best if I ponder that
for a few days to see if I can grok where the risks are.  In the
meantime, there is one point that I'd like to ask clarification on:

> To give a concrete example, consider a chat service over WebSocket. Let's say it doesn't check correctness of the handshake, and does authentication in-band. An attacker could construct an HTTP POST body which would look like an authentication message plus a couple of submitted sent messages. True, the attacker cannot read the victim's chat messages, but could send chat messages as the victim. Clearly this would be a significant security breach.

I am trying to understand how a properly implemented WS or HTTP server
would fall into this trap.  For httpd, this would not be feasible -
the code that parses request bodies isn't the same that handles the
protocol.  I'm trying to think of any real server implementations that
would attempt to process an HTTP body that also includes "fake"
requests (but in a different protocol).  Maybe there's a bit of
crafting that I'm just not seeing...

> We could mitigate both of these risks, and also reduce the implementation difficulty for servers and proxies, by changing the handshake. We would remove the requirement for newlines or exact capitalization of the headers. Instead, we could have the browser generate a unique random nonce, which it includes in the handshake request. The server would be required to read it, and respond with a hash of the nonce value.

While I'm not 100% sold on the security rationale for nonce yet (still
pondering it), at the least, the nonce is pretty straightforward to
implement - so, I could certainly be willing to admit I have a blind
spot there and go with the nonce if it means I can implement this in
httpd in an otherwise-straightforward manner.

Thanks again.  -- justin