Re: [hybi] Handshake was: The WebSocket protocol issues.

[Willy Tarreau <[e-mail]>]

On Sat, Oct 09, 2010 at 09:43:21AM -0700, Eric Rescorla wrote:
> On Fri, Oct 8, 2010 at 10:57 PM, Willy Tarreau <[e-mail]> wrote:
> 
> > On Fri, Oct 08, 2010 at 05:43:06PM -0700, Eric Rescorla wrote:
> > > This case definitely needs to be addressed. It's a completely standard
> > > hosting
> > > configuration.
> >
> > it is correctly addressed by respecting the HTTP protocol which consists in
> > sending Connection: close in the request so that there is no risk that
> > either
> > the web server or any intermediary consider additional data as a second
> > request.
> >
> 
> As I understand this suggestion, for it to provide security it relies on
> servers always
> treating any message with Connection: close as the final message. I don't
> know if
> servers always do this correctly, but since it's not really required for
> interoperability,
> I suspect that some do not.

I really don't buy that. It's been the default mode for HTTP till 1.0 and
the default switched to keep-alive with 1.1. Supporting this header is a
huge requirement to support old browsers, crawlers and various monitoring
tools, otherwise you get back to the situation where both sides wait for
the other one to close. Saying that some servers won't support Upgrade
makes some sense, but saying that some won't support close clearly does
not.

> All other things being equal, I would generally prefer to have a design
> which failed
> safely even if the server did not process Connection: close correctly. I
> believe that the
> design that Adam and I proposed in fact satisfies that desideratum

But it causes other issues caused by its breakage of interoperability with
HTTP content-aware infrastructure components such as URL switchers and load
balancers which are already deployed in almost all shared hosting environments
(namely URLs, Host header and Cookies). So it maybe it satisfies the
requirement of protection against some types of not yet identified servers,
but it does not satisfy anymore the compatibility with existing
infrastructure.

Also, if we're talking about imaginary server implementations, why not
agree that some servers could systematically experience an exploitable
buffer overflow and fire /bin/sh everytime they receive a CONNECT request
with anything that does not look like an IP address ?

We can imagine many things, but at one point, when paranoia prevents one
from satisfying basic requirements, it must be reasonable. Especially
since the advertised goal is to protect from remotely controlled browsers
that will already be able to do much more things by exploiting plain HTTP
than what they can do with a reasonable WS handshake.

Regards,
Willy