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

Adrien de Croy <adrien@qbik.com> Thu, 09 December 2010 03:23 UTC

Return-Path: <adrien@qbik.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 6120C3A6893 for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 19:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.061
X-Spam-Level:
X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=-3.462, BAYES_00=-2.599]
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 oSMl22hMRPsu for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 19:23:38 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 4472E3A6964 for <hybi@ietf.org>; Wed, 8 Dec 2010 19:23:36 -0800 (PST)
Received: From [210.55.214.39] (unverified [210.55.214.39]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3093)) with SMTP id <0017841652@smtp.qbik.com>; Thu, 9 Dec 2010 16:25:01 +1300
Message-ID: <4D004C0D.1070005@qbik.com>
Date: Thu, 09 Dec 2010 16:25:01 +1300
From: Adrien de Croy <adrien@qbik.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <BB947F6D-15AA-455D-B830-5E12C80C1ACD@mnot.net> <81870DB1-B177-4253-8233-52C4168BE99D@apple.com> <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>
In-Reply-To: <r2f0g6d7bj770kg0db5ptr027ninmckns8@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 08 Dec 2010 23:13:42 -0800
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:23:40 -0000

just on the topic of making the transfer look like HTTP and use 
"infinite chunks"

I think that would pose serious problems for intermediaries that process 
content (such as border AV systems).

Adrien


On 9/12/2010 4:03 p.m., Bjoern Hoehrmann wrote:
> * Mark Nottingham wrote:
>> WebSockets, of course, does allow an untrusted script to touch the bytes
>> on the wire, and that's the problem. Adam has proposed one way of
>> dealing with this -- by using a non-routable hostname in the
>> request-line, he's hoping to jam any intercepting proxies so that
>> they'll fail early (13% of traffic, in his tests). As he points out,
>> though, this doesn't offer good security in all circumstances, and I
>> suspect there are probably a few other attacks that could leak through
>> this approach.
> (This isn't entirely accurate. There are three hosts involved here, one
> on the CONNECT line, one in the Host header of the handshake, and one in
> the attacker-controlled client->server traffic if the attacker can make
> client->server Websocket traffic look like HTTP traffic. If the server
> does not understand "CONNECT" and the attacker can control what goes
> over the wire, non-routable hostnames are no help. And there are some
> other problems.)
>
>> I'd suggest that if HYBI doesn't want to use another port (still the
>> most obvious and safest solution), you could explore in a number of
>> strategies for mitigating these flaws, while still using HTTP Upgrade.
>> For example:
> I think the working group has heard all the notable techniques, as you
> say if ultimately the browser controls all the bytes, then there is no
> risk; if the attacker cannot control bytes that are critical for any
> reasonable exploit, such as white space characters, then there is no
> plausible risk either; if we do not use ports commonly used for HTTP,
> and make initial communication look much unlike HTTP, there is also no
> plausible problem. If we never actually leave the HTTP realm, such as
> by using chunked encoding with two essentially infinite streams, then
> there is also no plausible risk; finally there are the "talisman" pro-
> posals, where you send something odd and hope for the best (Ian's "76"
> draft has a "send malformed HTTP message" approach, Adam et al. have
> the "CONNECT" approach, Dave Cridland suggests sending something that
> looks like a CONNECT request but really isn't, and there are some ping
> pong hello and goodbye proposals I haven't kept track of; there is a
> plausible risk to all of those, but it's far fetched and evidence does
> not support that there is a grave concern.
>
> What the Working Group does not have is a framework in which this can
> be resolved. If you want sendfile() client->server and server->client
> to work and want (within reason) perfect security, then there is no
> alternative to a dedicated port. If you want to use port 80 and want
> perfect security, then you can only use infinite chunks (although it
> is not entirely clear how secure that would be) or escaping/encryption.
> And so on. At the moment it seems the working group needs an overview
> of the many options that have been offered, or at least a straw poll
> to put some metrics behind how important it is to protect against the
> various attacks, or accomodate performance or compatibility require-
> ments. (Ideally we'd have some numbers along the lines of "If you do
> this, then the success rate is that" and so on, but there seem to be
> few takers to aid in that.)