[hybi] workability (or otherwise) of HTTP upgrade

Greg Wilkins <gregw@webtide.com> Fri, 26 November 2010 05:05 UTC

Return-Path: <gregw@webtide.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 1AD903A69CC for <hybi@core3.amsl.com>; Thu, 25 Nov 2010 21:05:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 RGD5g69B9tiy for <hybi@core3.amsl.com>; Thu, 25 Nov 2010 21:05:39 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 28C123A6973 for <hybi@ietf.org>; Thu, 25 Nov 2010 21:05:39 -0800 (PST)
Received: by gwj17 with SMTP id 17so837423gwj.31 for <hybi@ietf.org>; Thu, 25 Nov 2010 21:06:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.90.98.11 with SMTP id v11mr3294294agb.58.1290748001566; Thu, 25 Nov 2010 21:06:41 -0800 (PST)
Received: by 10.236.42.204 with HTTP; Thu, 25 Nov 2010 21:06:41 -0800 (PST)
Date: Fri, 26 Nov 2010 16:06:41 +1100
Message-ID: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: HTTP Working Group <ietf-http-wg@w3.org>, hybi <hybi@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Subject: [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: Fri, 26 Nov 2010 05:05:40 -0000

I'm cross posting this message to both the hybi (websockets) and
http-bis mailing list as I think this is an issue that is very
relevant to both groups.

The hybi/websocket protocol, as currently proposed, has a handshake
mechanism that is roughly based on the HTTP upgrade mechanism.
Progress in the hybi/websocket mailing has ground to a halt because we
appear unable to get a clear consensus between the two advocated ways
forward:

 1) Make the "roughly based" HTTP upgrade mechanism a fully compliant
HTTP upgrade.
 2) Move away from HTTP upgrade and use another mechanism (potentially
CONNECT or SSL extensions)

To paraphrase the arguments against 1), there are some that are
concerned that an Upgrade based handshake will never be able to be
adequately secured against cross protocol attacks from ws-browsers to
non ws-servers. Also there is some concern that intermediaries might
not well support Upgrade and that other mechanisms might have a higher
success rate.

So I thought that it would be good to move that discussion from hybi
to HTTP-bis so we can stall progress here.... no I mean so that we can
get a wider view on the capabilities and vulnerabilities that might
apply to Upgrade.

My understanding is that Upgrade was included in HTTP for precisely
the reason that Websocket wishes to use it - ie to take an existing
HTTP connection and to upgrade the protocol run over the connection to
something with different capabilities than HTTP.
I would also expect that if there are problems with lack of Upgrade
support in intermediaries, then it would be easier to get
intermediaries to be updated to a standard generic HTTP mechanism
rather than some special purpose usage of CONNECT.

If websocket is unable to securely use Upgrade, then there must be
some fundamental flaw in Upgrade that should either be fixed in
httpbis (if allowed by the charter).   If Upgrade cannot be fixed,
then perhaps httpbis needs to somehow deprecate the mechanism and we
can look together for alternatives?

So I'd ask the httpbis readers, are there any reasons you know of that
would prevent Upgrade being used for websocket?
And I'd ask the hybi upgrade sceptics if they could perhaps voice
their concerns about Upgrade in more detail than my paraphrasing
above.

regards