Re: [hybi] Upgrade Mechanism and HasMat (was Re: Extensibility mechanisms?)

[Maciej Stachowiak <[e-mail]>]

On Jul 25, 2010, at 6:38 PM, Greg Wilkins wrote:

> 
> 
> On 23 July 2010 02:46, Maciej Stachowiak <[e-mail]> wrote:
> I originally suggested computing a hash of the nonce with other data (or some other nontrivial computation) rather than just echoing it back.
> 
> Maciej,
> 
> I agree that avoiding a simple echo would be very good protection against almost all forms of injection attack.
> 
> I think the handshake request contains a random token generated after the URL has been passed to the browser. The handshake response could then contain a random token generated after the connection has been accepted, plus a simple hash of the combination of the request and response tokens.

I don't see the value of a random token in the handshake response. How does that provide any additional protection? Anything echoed produced by the server might well be controlled by the cross-protocol attacker, so a random token generated by the server is no more effective than a fixed string.

> 
> This would allow a client to validate that the server had performed websocket specific calculations (in addition to sending a 101 response) and appears to address all the same security concerns that the current space counting and random bytes do.
> 
> I beleive these tokens and hash should be  carried in normal HTTP headers for the upgrade handshake, and that other mechanisms should be considered to address the fast fail detection of non-ws handling intermediaries.

I would have to see a more detailed version of this proposal to evaluate its security. I think it is effectively only as strong as sending a nonce (at an arbitrary place in the request headers), and echoing back a simple hash of that nonce that doesn't include any other data. Which I think is at the weaker end of nonce-based defenses.

Regards,
Maciej