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

[Eric Rescorla <[e-mail]>]

On Wed, Dec 1, 2010 at 11:42 AM, Willy Tarreau <[e-mail]> wrote:

> On Wed, Dec 01, 2010 at 11:04:21AM -0800, Eric Rescorla wrote:
> > On Wed, Dec 1, 2010 at 10:57 AM, Willy Tarreau <[e-mail]> 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 <[e-mail]>
> 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.
>

Which would actually be OK, as long as it didn't go somewhere under the
attacker's control.



> 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.
>

This is incorrect. The threat is that the attacker can *control* the target.

-Ekr