Re: [hybi] WebSocket handshake (HTTP and SSO)

[Willy Tarreau <[e-mail]>]

On Wed, Sep 01, 2010 at 09:36:18AM -0700, Ian Fette (????????????????????????) wrote:
> First, I'm not sure how important it is that the numbers are _strongly_
> random, so long as they come from a sufficiently large pool of options (e.g.
> from 0 to INT_MAX). The point of the handshake is not to establish e.g. key
> material that will be used for securing the connection. Rather, the point of
> the handshake is to ensure that each end is actually a WebSocket
> server/client. Using the same number all the time could mean that the server
> could always give back the same response, which would not be desirable as
> that would imply that the server might not actually be parsing the entire
> handshake, but rather just echoing things back. Using a different number
> each time ensures that the server is actually parsing the handshake and not
> just returning a predefined value. How strong the RNG is doesn't seem to be
> critical for this, unless I've missed something.

While not *that* important, it should be at least a little bit. The example
that Greg gave (1/48 to guess the random) means that blind attacks targetting
browsers that have that poor RNGs may still have a massive impact if the
request can be forged so that a victim server's response matches one of these
random numbers.

> As for the spaces, it's to protect against injection as you say. The goal is
> to prevent it from being smuggled in the PATH in such a way that that e.g. a
> HTTP request could be misinterpreted as a WS handshake request. As spaces
> must be encoded in the path (%20) this is designed to prevent against that,
> ditto with CRLF.

In my opinion this was only necessary because of the HTTP-like imitation
which was an incomplete implementation. With real HTTP, you can't make the
req-uri slip into the headers, because the CRLF terminates the request line.

> I think the worry is that a hex number in the header could be potentially
> confused, and not offer the same protections.

Well, we already have Content-MD5 in HTTP and it does not cause such a mess.
Once again, I think *some* of the defenses were implemented because the
protocol was redesigned from scratch and needed to have at least some
intrinsic protections that HTTP offers by default but this one could not
benefit from. That's exactly where relying on proven stable protocols is
a lot better than trying to reinvent the wheel.

Regards,
Willy