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

[Willy Tarreau <[e-mail]>]

On Wed, Sep 29, 2010 at 06:40:52PM -0700, Maciej Stachowiak wrote:
> > OK now I see your point. However I disagree with the need to protect
> > such a broken implementation.
> 
> As a browser implementor, I don't have the luxury of taking that stance.
> Users will blame the browser.

well, right now some blame the protocol for being complex and error-prone.

> > We're back to the "and what if the server-side implementation is buggy ?".
> 
> We can design the protocol so it's easy to make mistakes that cause a security vulnerability. Or we can make it hard to make mistakes. I prefer the latter.

I too do.

> > A publicly accessible server
> > returning 101 to random requests will just get tons of unwanted requests
> > from random HTTP scans which will cause it major trouble anyway.
> 
> Depends on what it's checking. If it looks for a string matching "Sec-WebSocket-Nonce" or what have you, that won't be in most random unwanted requests. Note that one case we are concerned about is severs protected solely by a firewall. In that case, the only way parties outside the firewall can do random scans is by hijacking a user's browser, and using the browser's HTTP capabilities.

The upgrade header won't be in random browser requests either. It's a
well-defined part of the HTTP protocol with specific semantics. Let's
be clear : I have no problem with looking at the WS nonce, and it is
required too. I mean that we must not complexify the handshake "just in
case". HTTP is a well-defined protocol with clear semantics. Some aspects 
of it are not well respected but most of them definitely are.

> But in any case, the very thing I am proposing we do is design the handshake so it's not likely that servers would be at risk from random HTTP scans.

That's my goal too : each side must be protected from the other side,
and must avoid attacking the other side, but we don't have to protect
each side from itself. So :

  - browsers must be able to distinguish between those 3 cases :
    1. servers that don't speak anything that looks like HTTP, so
       we must not blindly send too much data during the handshake.

    2. HTTP servers that don't speak websocket, so the handshake must
       ensure that it quickly fails on such a server (does not return
       101).

    3. real websocket servers

  - servers must be able to distinguish between those 3 cases :
    1. blind attacks with static data (bots, reverse FTP downloads, etc...)
       hence the need of a server-client-server check.

    2. HTTP browsers that try to make HTTP requests to a WS server
       (broken link on a page or CSRF, XHR, etc...). This is indicated
       by the lack of Upgrade and WS-specific headers ;

    3. real WS requests from browsers

Note that the first point for servers above should not even be required,
as HTTP servers don't do that right now. However I agree that it can be
a nice improvement eventhough it sometimes adds one RTT to the handshake
(in the case where the server has to talk first).

> Note that the NPN+TLS handshake won't have this problem. There's no way to produce anything that looks even remotely like it form a browser-hosted HTTP client.

I think that Adam will flame me for saying that, but in my opinion it
is equivalent : either the browser can present all what is needed or
it cannot. The Upgrade: WS header is the equivalent of the WS protocol
you'd announce in the NPN+TLS handshake. What TLS protects from is not
the server against the client, it's the client from connecting to non
WS servers (case 1 for browsers above). The Upgrade header is an HTTP
connection-specific header, it should be controlled by the lower layers
of the browser, basically at the same level as the TLS, where the user
has no control over what is sent.

> > The
> > presence of the Upgrade header *is* the only element that can dictate
> > a valid response. However I agree that the handshake should ensure
> > that a client can quickly escape from such a broken implementation,
> > the same way as right now a browser should reject responses which do
> > not look like HTTP.
> 
> That may be useful in its own right, but it would not in any way help in the case of an HTTP client being used to attack WebSocket. The HTTP client implementation will not be looking for a WebSocket server, broken or otherwise, so nothing the client does can offer any protection.

Yes it will, because a normal HTTP client must not accept 101 as a valid
response to an HTTP request, just as a WS client must not accept a non-101
response. We have two types of valid request/responses :
   - normal requests without Upgrade that cause any status except
     101 to be returned
   - Upgrade requests that cause 101+Upgrade in the response

Any combination of the two is wrong and must be rejected by the browser.
And if we want to help clients that would inadvertently retried the
response as data, that's one more reason to return "content-length:0"
and "connection: close" with the 101 response.

Also, you can't design a protocol that must protect two broken
implementations from talking to each other, because no side can rely on
the other one to do the cleanup. We need at least one compliant side to
apply our rules in order to recover.

Regards,
Willy