Re: [hybi] Redesigning the Web Socket handshake

Jamie Lokier <jamie@shareable.org> Wed, 03 February 2010 02:44 UTC

Return-Path: <jamie@shareable.org>
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 1F9B13A6BB8 for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 18:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.616
X-Spam-Level:
X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599]
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 pWXalJ6tHKjb for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 18:44:03 -0800 (PST)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 353623A6BB4 for <hybi@ietf.org>; Tue, 2 Feb 2010 18:44:03 -0800 (PST)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1NcVEP-0005Ys-E0; Wed, 03 Feb 2010 02:44:41 +0000
Date: Wed, 03 Feb 2010 02:44:41 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Maciej Stachowiak <mjs@apple.com>
Message-ID: <20100203024441.GR32743@shareable.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <FD440FEA-9F53-4F4C-8AA5-98B23318F0F7@apple.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
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 02:44:04 -0000

Maciej Stachowiak wrote:
> Did anyone really say that? Isn't mod_pywebsocket a proof that it is in fact possible: <http://code.google.com/p/pywebsocket/>?

Curious: Is it compliant?  I.e. does it reject requests which aren't
matching the exact octets needed, and create a response which does
match the exact octets needed?

Or does it just work without being WebSocket spec compliant?

> As far as I can tell, the WebSocket spec does not require special
> hardcoded handling of the request handshake. It's totally allowed to
> run it through a normal HTTP stack. In fact, it's totally allowed
> for servers to do no checking of the client request handshake at
> all, but that creates a security hole (possibility of violating
> integrity of a WebSocket service with XDomainRequest, cross-site XHR
> or cross-site form submission), one of the security holes we are
> trying to fix.

Is it permitted to not check the client request and be WebSocket spec compliant?
(Not just work, but be able to claim compliance.)

> FWIW I think my nonce proposal would allow doing this for the
> response at no cost in security - getting your victim to echo back a
> hash of an unpredictable nonce is so unlikely that there's no need to
> count on newlines in the handshake.

hash(nonce) + regular HTTP would go through proxies.

Current proposal intentionally fails at compliant HTTP proxies, on port 80,
doesn't it?

That would be a significant change in behaviour.

Other than that, I do like the idea, as an "are you a WebSocket server" check.

(I'm wondering why the CORS check used for XmlHttpRequest is
unsuitable, though.)

Maybe we can take the nonce idea further: An "are you a WebSocket
server that supports subprotocols X,Y,Z that I must have" check, where
a WebSocket server that doesn't support X,Y,Z would fail it.  That'd
be infinitely more reliable than HTTP's Expect mechanism, which relies
on proactive implementation by server developers who sometimes don't,
making it unusable.

If you like that idea, I'll describe how it would work.

(Starts getting ideas about nonce-verified proxy opt-in too... Hmm.)

-- Jamie