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

[Maciej Stachowiak <[e-mail]>]

On Sep 27, 2010, at 10:13 AM, Scott Ferguson wrote:

> Maciej Stachowiak wrote:
>> On Sep 26, 2010, at 6:22 PM, Greg Wilkins wrote:
>> 
>>  
>>> 2010/9/27 Maciej Stachowiak <[e-mail]>:
>>>    
>>>> Here is an email from February where I summarized some of the risks from
>>>> cross-protocol attacks for WebSocket:
>>>>      
>>> Maciej,
>>> 
>>> thanks for the reference, but I didn't and still don't fully
>>> understand the actual risk posed by those descriptions and that we are
>>> still shadow boxing against perceived rather than real threats.
>>>    
>> 
>> The reason I am skeptical of your proposed ping-poing handshake as a defense against cross-protocol attacks is that the *only* defense protecting WebSocket servers from attacks over HTTP is the assumed inability of browser-hosted HTTP clients to send whatever carries the random nonce, or something that looks sufficiently similar. Your summary doesn't specify exactly how the nonce is sent, but I'll assume it is using a header that normally cannot be sent via cross-site XHR or similar APIs.
>>  
> 
> Yes, the "ping" packet is missing a hash, which is needed to validate the browser as a websocket browser. Modifying Greg's proposal:
> 
> C1: c-nonce=...
> 
> S2: H(c-nonce, "WebSocket")
>     s-nonce=...
> 
> C3: H(s-nonce, "WebSocket")
> 
> 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.

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

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

> 
>> A potential improvement would be to require the server to produce a random number, which is included in the ping and must be in the pong in addition to the hash. In that case, an attacker could not queue up the correct pong without looking at the server's response at all. But going down this road results in increasingly elaborate schemes, along the lines of the -76 handshake. It's also likely there are more complicated flaws that we simply haven't thought of yet. I don't think we can stake the security of this protocol just on our own ability to think up attacks within a period of only a few weeks.
>>  
> 
> 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.

Regards,
Maciej