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

[Maciej Stachowiak <[e-mail]>]

On Sep 29, 2010, at 1:45 PM, Willy Tarreau wrote:

> On Wed, Sep 29, 2010 at 12:33:05PM -0700, Maciej Stachowiak wrote:
>>> Except that you have the Upgrade header which requires a 101 in
>>> response. A normal HTTP server will either :
>>> - ignore the Upgarde and return a classical code (200, 404, 403, ...)
>>> - consider the Upgrade header and either return 101 because it matches
>>>   the protocol it supports (WebSocket) or return an error code because
>>>   it does not support the WS protocol.
>> 
>> A standalone WebSocket server may well ignore the presence/absence of the Upgrade header, since performing the rest of the handshake does not depend on it in any way. Since checking it is not technologically required, it's likely some servers won't check it.
> 
> 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.

> 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. Same reason much application-level server code is written in languages that do not have raw pointers - why use a more error-prone tool if you don't have to?

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

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.

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.

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

Regards,
Maciej