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

[Scott Ferguson <[e-mail]>]

Maciej Stachowiak wrote:
> On Sep 27, 2010, at 10:13 AM, Scott Ferguson wrote:
>
>   
>> With that modification, the client does not send websocket data until the server has been validated as a websocket server, and the server does not process websocket data until the client has been validated as a websocket client. (There's no need for a S4 "pong" packet since the server is already validated as websocket when the client validates S2.) That protocol is pretty much the minimum required, and doesn't add overhead beyond the current handshake.
>>     
>
> Yes, I think that would be stronger in the scenario I describe, but it would be highly vulnerable to a bad RNG on the server, in part because the final authentication of the client does not involve the c-nonce at all.
>   

But that weakness is fundamental to all authentication. If keys or 
nonces can be predicted because they're not random, then you're always 
vulnerable to replay attacks. That issue is not specific to any 
particular protocol/handshake; it applies to all of them.

> More generally, I am not 100% confident that this approach will hold up in the long term against novel attacks.
>   

That's not really a point.

Since nonce/hash as authentication is a well-known pattern, it's 
potential vulnerabilities are also well-known. The issue of novel 
attacks would be more of a problem with a new security pattern, which is 
why sticking to the old patterns is generally a good idea.

>   
>> I'd propose two additional changes that aren't required, strictly speaking, but would be helpful for other security-related reasons:
>>
>> 1. Use "WEBSOCKET" instead of "GET" as the HTTP method. This is helpful because it lets validating servers quickly reject websocket requests (e.g. well-behaved HTTP servers), and lets server administrators use existing security frameworks (which are often HTTP method based), to specify websocket security easily. With the current "GET", it's somewhat of a problem for a server administrator to specify a different policy for GET vs websockets.
>>
>> 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.

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

-- Scott

> Regards,
> Maciej
>
>
>
>
>
>