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

[Eric Rescorla <[e-mail]>]

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



> >    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.
>
> Indeed, however two lines below the requirement is a MUST for the client :
>
>   An HTTP/1.1 client that does not support persistent connections MUST
>   include the "close" connection option in every request message.


I don't see how this is relevant. The question is whether servers
universally
treat the field's presence as an indication of no future requests.




> > Accordingly, it's not at all clear to me that it's safe to rely on
> > Connection: close
>
> Well, the best way to wipe any doubt would be to test it on a variety of
> servers.
>

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.



> BTW, I believe that Adam's example was that he could write a program on
> a shared server that could return a valid handshake to the CONNECT request.
> But since the valid response is a 200, by definition it's an establishment
> of a tunnel between both sides, which ends only by the close. So once again
> there is no other request on the wire after the handshake (rfc2817, #5.3).
>

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.


> I don't agree with that point at all. We're doing the same mistake again
> that we did with -76 handshake : the intermediaries should not wait for
> the connection to be completely established to take a routing decision.
> Look at this very common example :
>
>                       <--- hosting provider's infrastructure --->
>
>                                   /---- server farm A
>  client --- internet --- content <----- server farm B
>                          switch   \---- server farm C
>
> Some server farms are shared and other ones are dedicated to some
> customers, which is the typical scenario we find at almost every
> hosting provider's, because some customers with very poor code,
> high traffic or nasty reputations can cause negative side effects
> on other sites if shared on the same farms. Here, an HTTP content
> switch (reverse proxy and/or load balancer) will simply look at
> the host header and forward the request accordingly to the proper
> server.
>
> With Adam's proposed handshake, this is not possible anymore with
> currently deployed components. We would have to implement WebSocket in
> all front components just so that they can decrypt the host header and
> see what farm is supposed to process it, if any at all.


Yes, I agree that this would be required. I don't agree that it's a
dealbreaker.




> Not only this
> is not compatible with existing HTTP infrastructure, but doing so makes
> the frontend component sensible to new DoS attacks because it has to
> maintain a context before even knowing if it has to handle the request.
>
>
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.

-Ekr