Re: [hybi] Redesigning the Web Socket handshake

Greg Wilkins <gregw@webtide.com> Tue, 02 February 2010 00:14 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 668933A687A for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 16:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level:
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, WEIRD_PORT=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 tU46k2k45GMQ for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 16:14:53 -0800 (PST)
Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 2FF803A6803 for <hybi@ietf.org>; Mon, 1 Feb 2010 16:14:52 -0800 (PST)
Received: by ewy28 with SMTP id 28so3276529ewy.28 for <hybi@ietf.org>; Mon, 01 Feb 2010 16:15:24 -0800 (PST)
Received: by 10.213.103.208 with SMTP id l16mr110112ebo.65.1265069724566; Mon, 01 Feb 2010 16:15:24 -0800 (PST)
Received: from ?10.10.1.11? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id 13sm4088334ewy.5.2010.02.01.16.15.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 16:15:23 -0800 (PST)
Message-ID: <4B676E8C.70804@webtide.com>
Date: Tue, 02 Feb 2010 11:15:08 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>, hybi@ietf.org
References: <Pine.LNX.4.64.1002012305000.21600@ps20323.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.64.1002012305000.21600@ps20323.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Tue, 02 Feb 2010 00:14:54 -0000

Ian Hickson wrote:
> 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:

I think you've left out the main suggestion that's been made on this
list.

Leave the handshake more or less as it is, but specify it as a real
HTTP request and real HTTP response, rather than a binary
almost-equivalent.     I've got no objections to websocket
correctly using the existing HTTP upgrade mechanism on 80/443.


The immediate benefits of this change are:

 + that it allows the handshake to work with existing HTTP servers and
   intermediaries.

 + No need to explicitly specify behaviour such as HttpOnly cookies.
   that behaviour is inherited from the HTTP specs.

 + If HTTP/1.2 or HTTP/2.0 ever come out, then websocket will
   continue to work with new servers as the binary response
   line will not need to be changed.


It would allow some simple extensions.  For example redirection
could be supported with a 302 response.   For example is the server
responded with

   HTTP/1.1 302 Found
   Location: ws://foo.com:81

then the ws client could open port 81 and immediately start
talking websocket without any handshake at all (because of the
ws://).  If the server responded

   HTTP/1.1 302 Found
   Location: http://foo.com:81

Then it should open 81 and do another HTTP upgrade request.

This would allow both configuration of a shared port 80
or separate ports for HTTP and WS.


regards









> * 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).
>