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

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Wed, Sep 1, 2010 at 2:28 AM, Greg Wilkins <[e-mail]> wrote:

> 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?
>
>
Greg, thanks for the rephrasing. I wasn't as involved with the handshake
design, so apologies in advance if I misstate something. However, I'd like
to share what I believe was the intent of the scheme, in the hopes it may
clear up some of the confusion.

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.

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.

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

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.

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.


> regards
>