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

[Eric Rescorla <[e-mail]>]

On Sat, Oct 9, 2010 at 1:40 PM, Willy Tarreau <[e-mail]> wrote:

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


As far as I know, it's not correct that failing to support this header
creates
deadlock.

(1) RFC 2616 does NOT require clients to send Connection: close if they
do not want to create a persistent connection. (The requirement in 8.1.2.1
is only SHOULD level.

(2) Servers are permitted (and at least the servers I am familiar with do)
to simply close the connection regardless of whether it is persistent
(i.e., regardless of whether either side sent a Connection: close).
(S 8.1.4.)

Thus, it's quite possible to implement an HTTP server which does not
deadlock
without looking at the Connection header at all, simply by having a short
timeout.

Moreover, even treating the *presence* of a Connection: close as an
indication
of there being no more requests is merely a SHOULD level requirement
(S 14.10):

  HTTP/1.1 defines the "close" connection option for the sender to
   signal that the connection will be closed after completion of the
   response. For example,

       Connection: close

   in either the request or the response header fields indicates that
   the connection SHOULD NOT be considered `persistent' (section 8.1)
   after the current request/response is complete.

Accordingly, it's not at all clear to me that it's safe to rely on
Connection: close



> Saying that some servers won't support Upgrade
> makes some sense, but saying that some won't support close clearly does
> not.
>

It may be clear to you but it's not clear to me.


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

I'm not convinced that that's true: Adam has already explained how to make
a
content aware load balancer that speaks Websockets, simply by having the
Host header appear in the encrypted portion.



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

I think there's a fairly obvious distinction between the assumption that
servers do not have trivially exploitable remote vulnerabilities (something
that no protocol design feature in this WG can ameliorate) and the
assumption that you appear to want to make, namely that servers will do
things
that (1) are not required for interoperate and (2) are not even MUST-level
requirements in the relevant specification.

-Ekr