[hybi] Redesigning the Web Socket handshake
Ian Hickson <ian@hixie.ch> Mon, 01 February 2010 23:47 UTC
Return-Path: <ian@hixie.ch>
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 6A54E28C163 for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 15:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level:
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 QppY94aOuq-j for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 15:47:11 -0800 (PST)
Received: from looneymail-a4.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 8CDE728C1DD for <hybi@ietf.org>; Mon, 1 Feb 2010 15:47:11 -0800 (PST)
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a4.g.dreamhost.com (Postfix) with ESMTP id 179D683CF for <hybi@ietf.org>; Mon, 1 Feb 2010 15:47:47 -0800 (PST)
Date: Mon, 01 Feb 2010 23:47:46 +0000
From: Ian Hickson <ian@hixie.ch>
To: hybi@ietf.org
Message-ID: <Pine.LNX.4.64.1002012305000.21600@ps20323.dreamhostps.com>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [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: Mon, 01 Feb 2010 23:47:12 -0000
There have been a number of suggestions recently for changing how the handshake works in Web Sockets. I'd rather avoid doing this unless we can get a significant improvement out of it, so I'd like to solicit feedback on how much of an improvement such changes would result in. The main suggestions are: * Using a challenge instead of a fixed sequence of bytes for the handshake. Basically the client would send a nonce, and the server would have to send back some value generated from that nonce. - this means the server has to read the handshake, which avoids the cross-site message forgery attack. - we could make it even more secure by saying that you have to xor something derived from this nonce with the frame types (or maybe every byte) of all the data sent and received, so that even if the server still muddles through without a nonce, you can't possibly inject anything meaningful into the stream. - makes it less likely that an attack can be found where you can cause the server to echo text back to do a cross-protocol attack. - means that people who are using infrastructures with limitations on header order or whatnot can still use it. - it has been suggested that we'd still want the first few bytes of the response to be fixed (and unique) even with the nonce; this would lose most of the legacy intermediary benefits, though. - it would dramatically increase the complexity of the simplest possible websocket server. Right now you can have a server that doesn't even read the client handshake at all; this would force you to parse it. You could no longer write simple test servers that just send back a bunch of frames, for instance. * Not using HTTP at all is something I'd like to do, but since people are going to reuse port 443 with this regardless of what we say, it seems better to make it usable with HTTP-based parsers. * Using ports 81/815 instead of 80/443 would be ideal, but IANA said that if we look like HTTP, we must use ports 80/443. * Using CONNECT instead of GET with an Update has been suggested by some people. From the point of view of Web Sockets it doesn't matter either way, it's just an opaque handshake. From the point of view of HTTP, it doesn't seem CONNECT is very well defined, so I'm not sure what the implications of this are. As far as I can tell, we wouldn't do an Upgrade, we'd just be using the HTTP server like a proxy. It seems a bit dubious from an HTTP semantics point of view. As far as I can tell, it would mean that we don't have to worry about the server sending back something that looks like HTTP, though, which would get around the issue of limitations in legacy intermediaries. I'm especially interested in feedback regarding actual effects these changes would have on concrete deployed softare (like, how much easier would this make deploying Web Socket on a specific load balancer) and protocols (like, what actual attacks does this prevent or allow). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
- Re: [hybi] Redesigning the Web Socket handshake Greg Wilkins
- Re: [hybi] Redesigning the Web Socket handshake Justin Erenkrantz
- [hybi] Redesigning the Web Socket handshake Ian Hickson
- Re: [hybi] Redesigning the Web Socket handshake Greg Wilkins
- Re: [hybi] Redesigning the Web Socket handshake Ian Hickson
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Greg Wilkins
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Vladimir Katardjiev
- Re: [hybi] Redesigning the Web Socket handshake Francis Brosnan Blázquez
- Re: [hybi] Redesigning the Web Socket handshake Justin Erenkrantz
- Re: [hybi] Redesigning the Web Socket handshake Justin Erenkrantz
- Re: [hybi] Redesigning the Web Socket handshake Jamie Lokier
- Re: [hybi] Redesigning the Web Socket handshake Jamie Lokier
- Re: [hybi] Redesigning the Web Socket handshake Jamie Lokier
- Re: [hybi] Redesigning the Web Socket handshake Jamie Lokier
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Greg Wilkins
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Justin Erenkrantz
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Roberto Peon
- Re: [hybi] Redesigning the Web Socket handshake Justin Erenkrantz
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Justin Erenkrantz
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Jamie Lokier
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Jamie Lokier
- Re: [hybi] Redesigning the Web Socket handshake Martin J. Dürst
- Re: [hybi] Redesigning the Web Socket handshake Lars Eggert
- Re: [hybi] Redesigning the Web Socket handshake Maciej Stachowiak
- Re: [hybi] Redesigning the Web Socket handshake Martin J. Dürst