Re: [hybi] workability (or otherwise) of HTTP upgrade

Mark Nottingham <mnot@mnot.net> Thu, 09 December 2010 03:54 UTC

Return-Path: <mnot@mnot.net>
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 1C2803A68C2 for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 19:54:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.617
X-Spam-Level:
X-Spam-Status: No, score=-104.617 tagged_above=-999 required=5 tests=[AWL=-2.018, BAYES_00=-2.599, 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 tcvBfwAqhHet for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 19:54:38 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id B60A63A68BA for <hybi@ietf.org>; Wed, 8 Dec 2010 19:54:38 -0800 (PST)
Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D5A3822E258; Wed, 8 Dec 2010 22:55:59 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <mgj0g6hseqb6j92au80f8d1ook058nb33m@hive.bjoern.hoehrmann.de>
Date: Thu, 09 Dec 2010 14:55:56 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <25E88686-BE24-4EFD-8330-25916C891664@mnot.net>
References: <F4D1B715-3606-4E9A-BFB2-8B7BC11BE331@mnot.net> <57D4B885-B1D8-482F-8747-6460C0FFF166@apple.com> <37A00E8D-B55C-49AD-A85C-A299C80FFF17@mnot.net> <4F2580A7-79C2-4B0A-BCE5-7FB6D9AA0ED7@apple.com> <BB31C4AB95A70042A256109D461991260583956C@XCH117CNC.rim.net> <EA41A6C7-971C-4EC8-AA6F-96363B7FDC4C@gmail.com> <73E53F19-E0E7-4ADB-B765-ABAF0B4A6736@mnot.net> <r2f0g6d7bj770kg0db5ptr027ninmckns8@hive.bjoern.hoehrmann.de> <20C2FBB9-901F-4235-AF23-EC8262585905@mnot.net> <mgj0g6hseqb6j92au80f8d1ook058nb33m@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1082)
Cc: hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
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: Thu, 09 Dec 2010 03:54:40 -0000

On 09/12/2010, at 2:45 PM, Bjoern Hoehrmann wrote:

> * Mark Nottingham wrote:
>> I still haven't seen anyone explain why CONNECT is better than, say, WEBSOCKET_PLEASE.
> 
> As I understand it, some people hope that the HTTP framing implied by
> "CONNECT" (essentially, anything the client sends after the server does
> send it's HTTP response is not interpreted as HTTP traffic) is very
> widely implemented, while a WEBSOCKET-specific method might follow a
> different code path in deployed implementations, whatever that might
> entail (it's common for servers to close the connection if they see a
> method they do not recognize, but who knows what the odd server does.)

CONNECT to a server (intermediary or origin) that isn't expecting it can and will be treated like any other method that isn't understood -- it's perfectly legitimate for a server to generate a 405 Method Not Allowed.  As such, using CONNECT isn't a guarantee that the message framing has changed on the request, until the server agrees to its semantics. Given that those semantics are specific to configured proxies, and an intermediary "agrees" by forwarding the message even when it doesn't understand its semantics, this is indeed an entirely hope-based assumption; that every intermediary (firewalls, virus scanners, caching proxies) is built to understand CONNECT, even when many of them can't be configured as an explicit proxy at all. 


>> Also, from a quick read of the archive, it appears that encoding the
>> stream (e.g., XOR, removing newlines, etc.) was shot down very quickly
>> because people couldn't do sendfile().
> 
> I think there is a rough consensus to do some XOR obfuscation if that
> is necessary or helpful, even though some would rather be able to do
> the easy sendfile() call instead, but the benefits are not very clear
> (if the attacker learns or can predict the XOR key, you've not gained
> much, in some scenarios anyway.)

I was thinking more about stripping newlines, etc., but yes, it's more expensive. Just not sure why that's an issue, which is why I asked...

> 
>> That makes me wonder: what are the use cases for using sendfile() with
>> WebSockets that can't be addressed by HTTP (more reliably, by everything
>> I've seen here)?
> 
> (I think the question would be more aptly put as an issue of "you can
> do this using simple commands to the hardware" versus "you have to
> pump everything through the main processor"; while static files would
> be a good example, you could also imagine, say, a camera that offers a
> "WebM" stream you'd like to direct directly at the network equipment.)

I see. I still wonder, given that HTTP streaming is evolving pretty fast, and realtime streaming requires UDP, not TCP. 

--
Mark Nottingham   http://www.mnot.net/