Re: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)

Maciej Stachowiak <mjs@apple.com> Mon, 01 February 2010 03:08 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 AE1C03A6814 for <hybi@core3.amsl.com>; Sun, 31 Jan 2010 19:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.326
X-Spam-Level:
X-Spam-Status: No, score=-106.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 ZisQGT8RpFku for <hybi@core3.amsl.com>; Sun, 31 Jan 2010 19:08:22 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C87513A6862 for <hybi@ietf.org>; Sun, 31 Jan 2010 19:08:22 -0800 (PST)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 1BB09898D893 for <hybi@ietf.org>; Sun, 31 Jan 2010 19:08:55 -0800 (PST)
X-AuditID: 11807136-b7bafae000000e8d-8e-4b6645c6ace2
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 93.0E.03725.6C5466B4; Sun, 31 Jan 2010 19:08:55 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.96.3] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KX500II67EU3Q50@gertie.apple.com> for hybi@ietf.org; Sun, 31 Jan 2010 19:08:54 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <20100201010021.GA20940@shareable.org>
Date: Sun, 31 Jan 2010 19:08:53 -0800
Message-id: <2414195D-F1E0-43FE-8CED-401EAD9AA5F1@apple.com>
References: <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com> <E379EA13-D58A-4BFB-A62D-2B931A54E276@apple.com> <4B63DD6B.5030803@webtide.com> <E765982E-06B5-48BC-B75D-02E3F9555018@apple.com> <4B64B179.9050502@webtide.com> <2D6C6FEE-2019-44E4-BD82-7BF68B30A518@apple.com> <4B64D0B3.7050503@webtide.com> <3A1BA23A-D9B6-48F5-8639-DE12CF9939C0@apple.com> <20100201010021.GA20940@shareable.org>
To: Jamie Lokier <jamie@shareable.org>
X-Mailer: Apple Mail (2.1077)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)
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 03:08:23 -0000

On Jan 31, 2010, at 5:00 PM, Jamie Lokier wrote:

> Maciej Stachowiak wrote:
>>   As I understand it, the reason is security. If you strictly limit the
>>   format of the handshake interchange, then its less likely that
>>   WebSocket could be abused to talk to a non-WebSocket server - if you
>>   need to trick it into echoing back something very specific, that's a
>>   harder problem. It also makes the checks that the handshake was
>>   correct simpler and therefore potentially more robust.
> 
> With that goal, it would be better to make the handshake response
> *not* valid HTTP, and deliberately choose something that no HTTP
> server would produce and no HTTP proxy would be likely to relay.

Previous versions of the protocol did indeed do things that way, but that seemed unacceptable.

> That would be better for security and for blocking relay through
> unaware proxies, both of which are stated goals for the protocol.

It would make sharing a port with a Web server impossible. I think that would be too high a cost relative to the benefit. Note also: HTTP resources are not the only ones that could be abused, so it would have to look like nothing that any protocol ever produces.

Side note: Ian reminded me on IRC that while some parts of the handshake are restricted beyond what HTTP allows, the protocol does in fact allow arbitrary additional headers in both the request and response. This reduces the burden on server implementors. But it also seems to reduce the security benefit. In particular, the part of the handshake where the server echoes back the origin is not part of the hardcoded handshake but rather just a normal header. In light of this I'm not sure the fixed header is pulling its weight. It does probably add some amount of protection for resources that suffer header injection attacks - to fake the WebSocket handshake you'd have to inject before the real HTTP response header, and could not rely on injecting in the middle of a response. OTOH just the special status line ("HTTP/1.1 101 Web Socket Protocol Handshake") guarantees this. Would it be reasonable to limit the hardcoded part of the handshake to the status line?

Allowing arbitrary headers also means that we already have the ability to add per-connection protocol-level metadata without breaking compatibility. In particular, if we introduce future frame types, we could also introduce request and response headers where client and server both report the extra frame types they know. For example, this would let us introduce transparent gzip compression/decrompression between the client and UA in a future protocol revision. Likewise it could be used to negotiate transparent multiplexing and large message splitting. This mostly addresses my concerns about future-proofing the protocol for later feature additions.

Regards,
Maciej