Re: [hybi] Redesigning the Web Socket handshake

Maciej Stachowiak <mjs@apple.com> Wed, 03 February 2010 16:31 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 2862728C123 for <hybi@core3.amsl.com>; Wed, 3 Feb 2010 08:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Level:
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 GAs9Td0b5BZJ for <hybi@core3.amsl.com>; Wed, 3 Feb 2010 08:31:10 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id D1E0E28C0ED for <hybi@ietf.org>; Wed, 3 Feb 2010 08:31:10 -0800 (PST)
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id CAED283487DB for <hybi@ietf.org>; Wed, 3 Feb 2010 08:31:53 -0800 (PST)
X-AuditID: 1180711d-b7b18ae000001001-61-4b69a4f9b61e
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 2B.4F.04097.9F4A96B4; Wed, 3 Feb 2010 08:31:53 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.86.222] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX900FLBXX5E320@gertie.apple.com> for hybi@ietf.org; Wed, 03 Feb 2010 08:31:53 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <5c902b9e1002030806tdf7d34ci40446f500cd2b22f@mail.gmail.com>
Date: Wed, 03 Feb 2010 08:31:52 -0800
Message-id: <6C07376F-263A-4CB6-9932-635079ED5932@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> <BD4D49B1-6EB0-425E-BA3C-AE34DE826739@apple.com> <5c902b9e1002030738j20d6a20dud9154b956c338a28@mail.gmail.com> <E1EB568E-F023-4C69-B66A-AF55F1703438@apple.com> <5c902b9e1002030806tdf7d34ci40446f500cd2b22f@mail.gmail.com>
To: Justin Erenkrantz <justin@erenkrantz.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: Wed, 03 Feb 2010 16:31:12 -0000

On Feb 3, 2010, at 8:06 AM, Justin Erenkrantz wrote:

> On Wed, Feb 3, 2010 at 7:52 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>> The goal is more like "first few bytes" than "probably first packet". Remember, we're trying to defend against cross-protocol attacks, so what well-behaved clients and servers will do is not super relevant. I am more concerned with the security of the protocol than pleasing the aesthetic sense of HTTP gurus.
> 
> No, but what matters is what well-behaved servers will do when they
> accidentally break the only security mechanism when they reset the
> status reason and clear those hash'd bytes.

This won't lead to a security failure, it will lead to a connection failure.

> Many servers and proxies will allow the status reason to be overriden
> and replaced (think localization).  The failure case is going to be
> abysmal to track down and completely fatal - the handshakes will fail
> because some intermediary is rewriting the status reason and there
> won't be *anything* at all that a client can do about it.  Suck.  At
> least if it is in a separate HTTP header, it's a pretty good bet that
> it won't be touched and will survive most interactions with reasonable
> servers and intermediaries.

Do you have examples of servers that will actually do this to a 101 response? Will they do this even to modules designed to handle a protocol upgrade?

As for intermediaries, the kind that like to rewrite requests and responses will not work with WebSocket anyway, unless they are updated. Only HTTPS proxies (i.e. CONNECT type) are likely to work. For proxies that are updated to handle WebSocket over non-SSL connections, they can also be updated to make sure not to mangle the status line.

If this is a real problem that will actually occur, then sure, we should design around it, but there's not much we can do with "it might happen".

> Oops.  My bad.  (Perhaps we should consider another name besides
> "origin" - that's a very overloaded term?) 

"Origin" is the usual term of art for this in web technology. As in, "same origin-policy". It's also used in the XMLHttpRequest spec, the WebSocket client spec, HTML5, and probably other specifications as well.

Regards,
Maciej