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

[Scott Ferguson <[e-mail]>]

Ian Fette (イアンフェッティ) wrote:
> On Wed, Sep 1, 2010 at 2:28 AM, Greg Wilkins <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     The current handshake contains a number of unusual security features
>     that I do not think have had the rigorous analysis that such security
>     algorithms deserve.
>
>     Dividing a random number by another random number generated from the
>     same random number generator can have unexpected numeric
>     effects....I fear that this
>     algorithm, combined with a poor random number generator, may similarly
>     be vulnerable, specially as the random characters and spaces will
>     reveal more information about the internal state of the generator.
>
>
>
> 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.

The randomness is important because if the hijacker can predict the next 
random number, he can pre-generate the server's response in the initial 
attack and might be able to trick the target server into echoing that 
response (as Adam pointed out earlier.)

To repeat Greg's point, randomness is a tricky business and it's very 
possible to reduce your bits of randomness by using non-cryptographic 
algorithms, like the operations in the current draft, without realizing 
the problems. You might have 64 bits of integer but only 8-12 bits of 
randomness.

That's why a plain hex-encoded nonce can be better than something 
complicated, because you know how many bits of randomness it has.
>
> 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. 

This is one of the problems in the current handshake. The parts that are 
trying to validate the server as a websocket server and the parts that 
are trying to validate the client as a websocket client are jumbled 
together in a way that makes it hard to evaluate and appears to 
compromise both validations.

For server validation, any hijacker injection of those keys is 
irrelevant if the key/nonce is kept secret from the hijacker and if the 
hash calculation is sound. It doesn't matter if he can inject bogus 
keys, because the bogus keys will cause the server to return a bogus 
hash and a bogus hash will be rejected by the client.

What matters is keeping the key/nonce secret from the hijacker, and 
using a solid hash function, so he can't generate the real hash.

For client validation, the draft looks pretty ad hoc. I don't see any 
clear strategy for validating the client as websocket. The presence of 
spaces in the header or the random bytes after the GET are not really 
verifying the client is a websocket client. They're just trying to break 
HTTP, which isn't the same thing.

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

That's one of the dangers of the current spec. Because it's confusing 
and looks like it does a lot, it appears more secure than a 
straightforward, standard security design.

> I think some of the confusion is that this handshake isn't really 
> designed to provide a secure channel (e.g. choose keys that will be 
> used to encrypt further data), rather the handshake is to protect 
> against cross-protocol attacks, and so there are slightly different 
> criteria.

I don't think anyone has suggested that.
>
> While I might agree that it could perhaps be simpler and still work, 
> there is also an argument for defense in depth, and frankly it is not 
> difficult to implement (we and others have already done it), so I'm 
> inclined not to want to revisit it just for the sake of "I would 
> prefer something simpler" - would really rather move forward. There 
> are some open issues on the handshake that I would love to discuss, 
> e.g. #4 - making sure that we fail on intermediaries that won't 
> forward data properly but at the same time not hang on intermediaries 
> - but redoing the whole thing based on preference without any real 
> demonstrated problems (and having people already implemented it makes 
> me confident it's possible to implement) isn't really that enticing.

Even with a defense in depth strategy, each security layer needs to 
solve its intended problem correctly.

-- Scott
>  
>
>     regards
>
>