Re: [hybi] workability (or otherwise) of HTTP upgrade
Greg Wilkins <gregw@webtide.com> Tue, 07 December 2010 07:30 UTC
Return-Path: <gregw@intalio.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 BC22A3A692A for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 23:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level:
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 DNUwiCwsD6sQ for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 23:30:25 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 2E2B33A691C for <hybi@ietf.org>; Mon, 6 Dec 2010 23:30:22 -0800 (PST)
Received: by qyk11 with SMTP id 11so13768725qyk.10 for <hybi@ietf.org>; Mon, 06 Dec 2010 23:31:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.97.68 with SMTP id k4mr5341940qcn.261.1291707096614; Mon, 06 Dec 2010 23:31:36 -0800 (PST)
Sender: gregw@intalio.com
Received: by 10.220.167.203 with HTTP; Mon, 6 Dec 2010 23:31:36 -0800 (PST)
In-Reply-To: <4F2580A7-79C2-4B0A-BCE5-7FB6D9AA0ED7@apple.com>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <20101126000352.ad396b9a.eric@bisonsystems.net> <AANLkTimzQyG4hugOvHqoNrBrZFA4fGbGXQ7MZ2i+68dO@mail.gmail.com> <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>
Date: Tue, 07 Dec 2010 08:31:36 +0100
X-Google-Sender-Auth: 9KlIHcVu04976sSymq1xoYI--o0
Message-ID: <AANLkTimDtvq1+C2XPrzpEntSuRz-r183sifx3j7ojk4j@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Tue, 07 Dec 2010 07:30:29 -0000
On 7 December 2010 08:04, Maciej Stachowiak <mjs@apple.com> wrote: > > On Dec 6, 2010, at 10:44 PM, Mark Nottingham wrote: >> The difference is that we wouldn't have to figure out how to make it safe *and* compatible with the existing HTTP infrastructure; we wouldn't have to catch all of the accidental / deployment issues as well as the active attacks. >> >> That would make the way forward fairly simple: >> >> 1) Designate a new port for Websockets traffic >> 2) Allow that to be overridden (much as with HTTP and pretty much every other protocol) for people who have immediate deployment considerations (i.e., they'll use 443) >> 3) Design the protocol so that it can't spoof other protocols, by using a selection of techniques: >> a) Exchanging a nonce, with HMAC response >> b) Armouring each message >> c) Encrypting the whole damn thing >> *without* the pretence that it's HTTP. >> >> I'm sure (3) is an oversimplification and/or just plain wrong, but that's why we have Adam. #1 gives us a long-term safe > deployment strategy, whereas #2 lets the impatient deploy right away, and also gives a fallback if #1 doesn't take off in the long run. > > Adam and Eric's proposal basically does what you say, except that it doesn't designate a new port for > WebSocket traffic, and it makes a small nod towards letting servers and server-side infrastructure > dispatch between WebSocket and HTTP on the same port. I am not sure it would simplify things > > much to abandon those goals. I don't see the justification for the confidence in Adam's and Eric's proposal. Basically they are saying that in their experiment sending the method "CONNECT" was sufficient to prevent intermediaries parsing any following HTTP requests. Yet when the suggestion of sending Get+Upgrade+Hello packets is made, to similarly trip up the parsers of intermediaries, the response is that HTTP parsers are forgiving and that empirical experiments of no exploit are not proof that it is safe etc. etc. These arguments can be equally made against a CONNECT solution, as it is easy to believe that their are intermediaries that will treat CONNECT no differently from other methods and continue parsing the stream for HTTP content. We need to do the experiment, but I expect we would find that a GET+Upgrade+Hello handshake would also have 0 exploits just like CONNECT. But I do not believe that either zero result proves that either handshake is 100% safe, because essentially the issue is caused by poor intermediaries and we can always imagine more buggy intermediaries. After either "CONNECT" or "GET+Upgrade+Hello" we will need to have robust framing that gives a high probability of tripping up HTTP parsers on every message. But for both handshakes, the defence is essentially probabilistic, because we cannot prove that there is not a really stupid intermediary out there. I think it is just wrong to think that "CONNECT" makes us any safe from this consideration. The question is, given that these intermediaries are already exploitable via commonly deployed browser plugins (and the victim does not even have to be running those plugins as another browser can do the poisoning), is a probabilistic demonstration of robust framing acceptable defence for either handshake? If the answer is no for one, then it is no for the other, because there is no difference in the proofs for either. If the answer is no, then we need to consider encryption or another port. I do come back to the fact that using another port does not give a perfect success rate, but then neither does CONNECT or GET+Upgrade+Hello. Opening new ports seams like an easier ask than convincing intermediaries to change their CONNECT and/or Upgrade handling. cheers > If the goal was not to interoperate with HTTP at all, it would be much better to use an approach where everything is encrypted. One plausible way to do that would be to restrict the protocol to TLS-only, at which point the nextprotoneg proposal can take care of dispatch without having to involve the HTTP layer. I think this is a plausible option, but many hybi WG members have expressed concern about the performance issues and other barriers to deployment of an all-TLS solution. > > Another approach is to invent our own crypto and start with a key exchange. Inventing crypto makes me nervous compared to using something known (such TLS), and might well impose many of the same costs that folks are worried about with TLS. > > It's also worth noting that operating over ports 80/443 and coexisting with an HTTP server are goals that come from our charter and requirements document, so abandoning those goals would likely require a major reboot of the group. We already have implementors impatient to see a production-shippable protocol, it doesn't seem so great to me to go back to the drawing board. > > Regards, > Maciej > >
- [hybi] workability (or otherwise) of HTTP upgrade Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Julian Reschke
- Re: [hybi] workability (or otherwise) of HTTP upg… Jamie Lokier
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Eric Rescorla
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Roy T. Fielding
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Dave Cridland
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Joe Mason
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… William A. Rowe Jr.
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Adam Barth
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Brian McKelvey
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Jack Moffitt
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… Maciej Stachowiak
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Adrien de Croy
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Collin Jackson
- Re: [hybi] workability (or otherwise) of HTTP upg… Mark Nottingham
- Re: [hybi] workability (or otherwise) of HTTP upg… SM
- Re: [hybi] workability (or otherwise) of HTTP upg… Pat McManus @Mozilla
- Re: [hybi] workability (or otherwise) of HTTP upg… Scott Ferguson
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Gabriel Montenegro
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… John Tamplin
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Bjoern Hoehrmann
- Re: [hybi] workability (or otherwise) of HTTP upg… Greg Wilkins
- Re: [hybi] workability (or otherwise) of HTTP upg… Martin J. Dürst
- Re: [hybi] workability (or otherwise) of HTTP upg… Willy Tarreau
- Re: [hybi] workability (or otherwise) of HTTP upg… Simon Pieters
- Re: [hybi] workability (or otherwise) of HTTP upg… James Graham
- Re: [hybi] workability (or otherwise) of HTTP upg… Michael
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu
- Re: [hybi] workability (or otherwise) of HTTP upg… Zhong Yu