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

Maciej Stachowiak <mjs@apple.com> Thu, 09 December 2010 06:20 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 0D1023A69EC for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 22:20:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.624
X-Spam-Level:
X-Spam-Status: No, score=-106.624 tagged_above=-999 required=5 tests=[AWL=-1.265, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, 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 dNkucC0o2Pum for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 22:20:09 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C43583A69EA for <hybi@ietf.org>; Wed, 8 Dec 2010 22:20:02 -0800 (PST)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id C0FB3C28B47E for <hybi@ietf.org>; Wed, 8 Dec 2010 22:21:31 -0800 (PST)
X-AuditID: 11807136-b7b9aae0000052f6-5c-4d00756b704a
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 10.20.21238.B65700D4; Wed, 8 Dec 2010 22:21:31 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.72.145.91] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LD5003OADNOOD20@gertie.apple.com> for hybi@ietf.org; Wed, 08 Dec 2010 22:21:31 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <AANLkTi=k0Czvm_pW=N3zPAGZdKyqZGduGJUp8dk3PByX@mail.gmail.com>
Date: Wed, 08 Dec 2010 22:21:23 -0800
Message-id: <36DC5313-2555-46AC-B618-B4FFCBD99C7D@apple.com>
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> <25E88686-BE24-4EFD-8330-25916C891664@mnot.net> <AANLkTi=k0Czvm_pW=N3zPAGZdKyqZGduGJUp8dk3PByX@mail.gmail.com>
To: Jack Moffitt <jack@collecta.com>
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: hybi HTTP <hybi@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, 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 06:20:52 -0000

On Dec 8, 2010, at 8:10 PM, Jack Moffitt wrote:

> One path is to combine the separate port idea along with the
> encryption based approach. On the WebSocket port, you could avoid all
> the intermediary issues, but perhaps be limited by firewalls.
> However, you would not need any obfuscation and could easily use
> sendfile().  On the TLS port you use NPN to get a WebSocket that is
> not going to cause security problems with intermediaries.
> 
> For the short term, we get WebSocket on the port with the highest
> success rate, and in the long term, we have firewalls accepting the
> new port as killer applications make people care.
> 
> If we're going to lose the sendfile(), why not go the rest of the way?
> Or is there something I'm missing in the port 80 but just XORed case?

If the attacker can choose an arbitrary port to connect to, then you still need some form of obfuscation or attempt to avoid looking like valid HTTP, since they could chose port 80, 8080, 8000, or other ports not infrequently used for HTTP.

Regards,
Maciej