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

Willy Tarreau <w@1wt.eu> Wed, 01 December 2010 19:41 UTC

Return-Path: <w@1wt.eu>
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 397853A6C91 for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 11:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, 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 ifv+fOntFoEs for <hybi@core3.amsl.com>; Wed, 1 Dec 2010 11:41:16 -0800 (PST)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id B8ED928C0E6 for <hybi@ietf.org>; Wed, 1 Dec 2010 11:41:15 -0800 (PST)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id oB1JgMID021394; Wed, 1 Dec 2010 20:42:22 +0100
Date: Wed, 01 Dec 2010 20:42:22 +0100
From: Willy Tarreau <w@1wt.eu>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20101201194222.GK19021@1wt.eu>
References: <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> <AANLkTi=Jx867QjSHNJkwo_ryYML-X9HWjjCTCS=-Cbmd@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AANLkTi=Jx867QjSHNJkwo_ryYML-X9HWjjCTCS=-Cbmd@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
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:41:17 -0000

On Wed, Dec 01, 2010 at 11:04:21AM -0800, Eric Rescorla wrote:
> 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.

Maybe, but this domain *can* be resolved. Something that can be resolved
while its goal is not to be is obviously an issue, especially if it was
choosen precisely for that purpose.

I can predict that if some ISPs are fed up with getting tons of requests
for the .invalid TLD, they will simply announce it with a wildcard in their
servers, just as verisign did with the .com and suddenly all their customers
will be able to resolve it.

The fact that .invalid is reserved for invalid domains does not technically
imply that it will never resolve. Either the handshake does not care whether
the host resolves or not, then we can safely put the correct one, or it relies
on the fact that it must never ever resolve and we must use something that
cannot be resolved.

Right now we're just playing with guesses, I'm sorry Eric.

Regards,
Willy