Re: [hybi] Redesigning the Web Socket handshake

Maciej Stachowiak <mjs@apple.com> Tue, 02 February 2010 03:28 UTC

Return-Path: <mjs@apple.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 B4DCC3A635F for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 19:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, 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 vi935QTgf9bK for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 19:28:58 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 4E3923A68C1 for <hybi@ietf.org>; Mon, 1 Feb 2010 19:28:58 -0800 (PST)
Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out4.apple.com (Postfix) with ESMTP id 1D54E89B67B2 for <hybi@ietf.org>; Mon, 1 Feb 2010 19:29:35 -0800 (PST)
X-AuditID: 11807130-b7b0aae00000102c-ac-4b679c1ed116
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay11.apple.com (Apple SCV relay) with SMTP id 8F.3D.04140.E1C976B4; Mon, 1 Feb 2010 19:29:35 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.246.17.218] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX7008AQ31ANE00@elliott.apple.com> for hybi@ietf.org; Mon, 01 Feb 2010 19:29:34 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <4B676E8C.70804@webtide.com>
Date: Mon, 01 Feb 2010 19:29:34 -0800
Message-id: <614FF5CD-6557-4DD7-85AA-AADC24BA8A08@apple.com>
References: <Pine.LNX.4.64.1002012305000.21600@ps20323.dreamhostps.com> <4B676E8C.70804@webtide.com>
To: Greg Wilkins <gregw@webtide.com>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
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: Tue, 02 Feb 2010 03:29:00 -0000

On Feb 1, 2010, at 4:15 PM, Greg Wilkins wrote:

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

This proposal doesn't address address the security vulnerabilities that Ian mentioned, and it seems make the protocol more vulnerable. Note that having newlines in the hardcoded part of the handshake is no longer particularly beneficial if you adopt the nonce scheme, thus the status line would be the only part of the headers subject to special rules, and no one here has argued that it's remotely hard to make a server send the status line of their choice. Thus, I don't see the practical benefit of your proposal, in exchange for the increase in security risk.

 - Maciej

> 
> 
> 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).
>> 
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi