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

Eric Rescorla <ekr@rtfm.com> Wed, 01 December 2010 19:03 UTC

Return-Path: <ekr@rtfm.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 8A4C83A6C52 for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 11:03:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.606
X-Spam-Level:
X-Spam-Status: No, score=-101.606 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001]
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 q2SR+019CmPp for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 11:03:07 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 5D8593A6C20 for <hybi@ietf.org>; Wed, 1 Dec 2010 11:03:07 -0800 (PST)
Received: by ywe9 with SMTP id 9so59384ywe.31 for <hybi@ietf.org>; Wed, 01 Dec 2010 11:04:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.91.26.24 with SMTP id d24mr2078259agj.160.1291230261057; Wed, 01 Dec 2010 11:04:21 -0800 (PST)
Received: by 10.90.154.19 with HTTP; Wed, 1 Dec 2010 11:04:21 -0800 (PST)
In-Reply-To: <20101201185759.GI19021@1wt.eu>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <20101126000352.ad396b9a.eric@bisonsystems.net> <AANLkTimzQyG4hugOvHqoNrBrZFA4fGbGXQ7MZ2i+68dO@mail.gmail.com> <4CF615B2.9010304@rowe-clan.net> <F96E5CE9-CA7D-4B70-8260-F05456D021FB@gbiv.com> <AANLkTimi5HL56PD9gLHUWs=mcbV3Eaz=GOsK38sxPevb@mail.gmail.com> <AANLkTimydOwRiVkrZn0zmxmvWP_V6yAmNbipOF73NBWD@mail.gmail.com> <AANLkTin_k_s7yOSP1QUXyy66p=gweeepySFG+C=kGYJ+@mail.gmail.com> <AANLkTim9jj0pZzNjrJ+rTXd6ZYnp284ugcKXALcj-Wt6@mail.gmail.com> <AANLkTinb4pDS25HJwnM36NK9ajyEt8MztWriR5ECEgZR@mail.gmail.com> <20101201185759.GI19021@1wt.eu>
Date: Wed, 01 Dec 2010 11:04:21 -0800
Message-ID: <AANLkTi=Jx867QjSHNJkwo_ryYML-X9HWjjCTCS=-Cbmd@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Willy Tarreau <w@1wt.eu>
Content-Type: multipart/alternative; boundary="001485f9a68c0898d304965df961"
Cc: "William A. Rowe Jr." <wrowe@rowe-clan.net>, "Roy T. Fielding" <fielding@gbiv.com>, Hybi HTTP <hybi@ietf.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: Wed, 01 Dec 2010 19:03:08 -0000

On Wed, Dec 1, 2010 at 10:57 AM, Willy Tarreau <w@1wt.eu> wrote:

> On Wed, Dec 01, 2010 at 01:52:14PM -0500, John Tamplin wrote:
> > On Wed, Dec 1, 2010 at 1:47 PM, Greg Wilkins <gregw@webtide.com> wrote:
> > > If 6543 is the websocket port, then it would not matter in an
> > > intermediary intercepted and interpreted
> > >
> > >  CONNECT some.host.com:6543 HTTP/1.1
> > >
> > > as the implementation of that is likely to be exactly the semantics
> > > that we want.
> > >
> > >
> > > An intermediary that incepts and interpets
> > >
> > >  CONNECT some.special.token HTTP/1.1
> > >
> > > is going to break.
> >
> > Breaking in a way that doesn't expose a vulnerability is fine (but
> > obviously we would prefer to avoid it), as those will eventually be
> > upgraded to be WebSocket-aware -- what we definitely can't afford is
> > an intermediary that breaks in such a way as to expose
> > vulnerabilities, which is what Adam's work on GET+Upgrade appears to
> > show.
>
> That's why I'm insisting that we ensure that what we put there either
> always breaks or that we put the real name+port, but not some randomly
> defined entity that we decide must not be resolved until someone finds
> it useful to resolve it.


It's not "randomly defined". It's a specifically reserved domain.

I realize you have concerns that people will choose to do so in any
case--concerns
which I don't share--but I don't think you're characterizing the situation
very
accurately above.

-Ekr