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

[Eric Rescorla <[e-mail]>]

On Mon, Oct 11, 2010 at 1:42 PM, Willy Tarreau <[e-mail]> wrote:

> On Mon, Oct 11, 2010 at 07:07:18AM -0700, Eric Rescorla wrote:
> > On Sun, Oct 10, 2010 at 10:33 PM, Willy Tarreau <[e-mail]> wrote:
> >
> > > On Sun, Oct 10, 2010 at 09:17:21PM -0700, Eric Rescorla wrote:
> > > (...)
> > > > 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.
> > >
> > > That's what I meant with the "deadlock", we can only end the transfer
> on
> > > a timeout if the client expects a close and the server does not close.
> > > Even if the timeout is short, it makes the situation very uncomfortable
> > > for the user.
> >
> >
> > I don't understand what you mean here. There are two issues:
> >
> > (1) when the response is finished
> > (2) when the connection can be closed.
> >
> > Only the first affects the user experience, but they don't really
> interact.
>
> Yes they do for components which rely on the close only and don't require
> any content-length (eg: most monitoring tools). If the server did not care
> about the close in the request and waited for a second request instead of
> closing, the client would wait for the server to close to determine the
> end of the response, which is after the keep-alive timeout of the server.


I don't see how this makes sense. Regardless of the setting of Connection:
close
if the server is not going to either put a length field or chunked encoding,
it
needs to close the connection at the end of the response. Timeouts don't
enter into it. I don't know what you mean by "monitoring tools" here...



> > Even
> > if the client is using persistent connections, the server still needs to
> > either
> > incorporate a length indication or terminate the response after sending
> the
> > response. In neither case does the user experience a stall.
>
> This is mandatory for persistent connections only.


It's not an issue of mandatory or not. It's an issue of minimal
functionality.



> While it's recommended for
> other connections, we still see some servers that don't advertise a content
> length for HTTP/1.0 request (even Tomcat until very recently).


I don't understand what point you're making here. It's entirely possible for
a
server to be interoperable while ignoring Connection: close simply by always
using a length field/chunked encoding and using a timeout. This leads to
neither
deadlock nor interop problems. If you think there is an interop problem
here,
please describe the sequence of events that causes it. If not, then I don't
see
how you can rely on proper Connection: close behavior as a security feature.



> > No, I don't agree on this. Once you're reduced to this kind of survey you
> > no longer have any reasonable assurance of security. Surveys are
> sometimes
> > OK for resolving interoperability questions, but in this case you are
> > relying on this property for a security purpose.
>
> I still think that since the complexity of the hanshake only relies on a
> fear
> of massive attacks making use of browsers and shared hosting environments,
> if
> we fail to find a deployed vulnerable servers, the massive attack risk
> vanishes. It's not to say that no braindead server could not be attacked,
> but that such a vector is basically useless.
>

Who said anything about "massive attacks"? That's not my concern. My concern
is deploying a new feature which makes otherwise secure systems insecure.


>
> > Yes, that's why using CONNECT is a desirable feature, since for
> > interoperability
> > reasons servers/proxies cannot treat data that appears in the tunnel as
> if
> > it were HTTP traffic.
>
> And that's also why there cannot be a second request after the 200.


Yes, that's my point. That you can't really have an interoperable CONNECT
implementation at all without ignoring everything after the 200. By
contrast,
you can have an interoperable implementation while ignoring Connection:
close.
This is why I feel more comfortable relying on the CONNECT behavior than
on Connection: close.



> >
> > Yes, I agree that this would be required. I don't agree that it's a
> > dealbreaker.
>
> Well, first it's not compatible with any existing infrastructure, which is
> a bit limited outside of the lab.


Yes, I agree it requires an infrastructure change. I don't agree that it's a
dealbreaker.



> Second, it means that the front server
> would first have to acknowledge a WS handshake on behalf of any possible
> server behind it and finally have to return in WS frames a "Sorry man, I
> thought I could hand that connection to someone but there's nobody where
> you want to go".


No, this is not correct. The server can process the entire handshake,
including
the encrypted destination portion, and then only after that respond to the
request.
This requires, as Adam suggested, having the initial "Host" block encrypted
with a key supplied only by the client.



> > I don't see how this creates any meaningful increase in the state that
> must
> > be maintained by the infrastructure element, which must already maintain
> > TCP buffers, which are far larger.
>
> Exactly, it *has* to maintain TCP buffers as well as contexts, it cannot
> filter based on anything advertised in the handshake.
>

Again, this is incorrect. All the relevant material appears immediately
after
the TCP handshake.


All that is just based on the fact that we fear that some components will
> accept to process an HTTP request after both a "Connection: close" and a
> CONNECT that returns a 200.
>

I really don't understand what aspect of Adam or my proposal you're arguing
against
here.


I'd be tempted to suggest that such broken implementations simply deserve
> to be taken down...
>

Given that those implementations are compliant with 2616, I don't know on
what
basis you claim that they are broken.


-Ekr