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

[Greg Wilkins <[e-mail]>]

2010/9/1 Ian Fette (イアンフェッティ) <[e-mail]>:
> On Tue, Aug 31, 2010 at 6:39 PM, Scott Ferguson <[e-mail]> wrote:
>> Or at least, I think that's what the protocol is trying to do. To me, it
>> looks like a security -through-confusion protocol hacked together by someone
>> with little security experience, who believes that a complicated, confusing
>> protocol is more secure than a straightforward one. If no one can understand
>> it, no one can attack it, I guess. That's just what it looks like to me.
>
> While I can appreciate that you may not care for the complexity of the
> handshake, I would ask that you please not attack the experience of the
> people involved in its design. Critiques of the protocol are certainly
> welcome, but I don't think personal attacks are appropriate.

Ian,

I think I can rephrase Scott's concerns as a non personal attack.

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.

The algorithm encodes 2 random integers as decimal digits randomly
interspersed with other characters and spaces.  The algorithm requires
the characters to be ignored, the spaces to be counted and the number
to be divided by the number of spaces.

Dividing a random number by another random number generated from the
same random number generator can have unexpected numeric effects. I
have previously experienced a problem with a random session ID where
an attempt to "improve" a 32 bit random number by mixing in some salt
and applying another random number from the same generator actually
significantly reduced the search space.  An exploit was developed that
give 3 session ID, a bit of brute force calculation and you could
predict the next session with 1 in 48 accuracy. 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.

The space counting is to protect against injection, but is not
required if the nonce is generated after the path is passed to the
websocket client. I simply don't understand the justification given in
the specification for the random characters interspersed with the
numbers.

My counter proposal is that the nonce is sent simply as hex number in
the header.  Since these numbers are generated after the path is
passed to the websocket client, they cannot be predicted and thus
cannot be injected.

Are there any problems with this simpler approach?

regards