Re: [hybi] Handshake was: The WebSocket protocol issues.

[Maciej Stachowiak <[e-mail]>]

On Sep 28, 2010, at 9:38 AM, Scott Ferguson wrote:

> Maciej Stachowiak wrote:
>> On Sep 27, 2010, at 10:13 AM, Scott Ferguson wrote:
>> 
>>> 
>>> 2. Use a new AUTH or HELLO opcode/packet for the C3 hash instead of overloading PING. This would make the packet's purpose clear and give a space for any future challenge-based authentication to put its credentials in a future spec extension. (I'd recommend any authentication extension/C3-payload use HTTP style authentication headers so the extension could just use existing security handshakes.)
>>>    
>> 
>> #1 seems like an improvement, but #2 doesn't seem to give any security benefit.
>>  
> 
> #2 is certainly a security benefit for servers. If a server provides a non-browser service, it needs the ability to authenticate. That should be an obvious security need.

Can you explain the security benefit specifically of changing the opcodes of the packets involved in the handshake? It's not clear to me. A new authentication scheme may or may not have benefits on its own, but changing the handshake message opcodes does not seem to make any difference to this.

> 
>>> No, it's different from -76, because the properties of the nonce/hash pattern are well known. The flaw with -76 is just what you describe: it's inventing new security patterns and is likely to have complicated flaws. Sticking to a well-known pattern is the right way to go.
>>>    
>> 
>> Nonce/hash is a well-known mechanism. But I do not believe there is a lot of knowledge on using it as a defense against cross-protocol attacks. Generally it is used as part of a challenge-response mechanism for authentication purposes, but authentication is not the goal here. There is no shared secret or public-private keypair involved.
>>  
> 
> Authentication is the goal here. The whole point of defeating a cross-protocol attack is authenticating both the client and the server as implementing the correct protocol. Once you've validated both sides as implementing websockets, then any attack is no longer a cross-protocol attack.
> 
> The shared "secret" is the "WebSocket" value in the hash. For server authentication, H(c-nonce, "WebSocket"), only a websocket server will ever produce that hash because on a websocket server has that "secret". SMTP cannot produce that response because it don't have that secret (and doesn't produce hashes at all, of course.)

This does not seem like a classical authentication problem to me. There is no actual secret and no actual proof of identity. Rather, the cross-protocol defense provided depends on the presumed inability of stock servers or browser-hosted client code to send or meaningfully process particular messages. For example, the security of this scheme would be largely unaffected if the hash was not cryptographically secure, which is surely not the case with actual authentication schemes. Robustness against cross-protocol attacks is simply not the same problem.

Regards,
Maciej