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

[Greg Wilkins <[e-mail]>]

2010/9/2 Ian Fette (イアンフェッティ) <[e-mail]>:
> 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).

True, and I expect to see many implementation that just send 1234 5678


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

How could the hex number be confused? How could it not offer the same
protection?
If we can't answer these questions, then we don't understand the
problem and thus we are unlikely to design a good solution.

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

True.   It is designed to protect against a server that can be tricked
into sending a valid 101 response and
then valuable data without authentication.   The chances of that are
already extremely remote, and if such
a server did exist it would be vulnerable to so many other exploits.
It does strike me as a lot of bother for a
vanishingly small vulnerability.


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

At the time this "feature" was unilaterally added to the draft, I
argued strongly against it being adopted as the ietf-00 draft because
there had been no due diligence on the proposal (and there are real
intermediary problems as a result). Now using the "it's implemented so
accept it" argument is really not very acceptable considering the
history of this.

However, I do agree it is not a hugely important technical issue
(unlike the placement of the the random bytes).   So I'll just rest my
case by saying that when I implement the Jetty client,  I think I will
use the fixed string

Sec-WebSocket-Key1: the ietf process failed 12345678


cheers