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

[Scott Ferguson <[e-mail]>]

Maciej Stachowiak wrote:
>
> On Sep 28, 2010, at 9:38 AM, Scott Ferguson wrote:
>
>>
>> #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.

The opcode itself doesn't matter. It's the extension space for 
challenge/response authentication in the handshake payload that's the 
important added value. (It's not related to cross-protocol issues, but 
still an important security issue, because servers need to protect 
themselves against non-browser websockets clients.)

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

The server hash validation is stronger than your description, because 
it's also checking that the server is in possession of the "WebSocket" 
string (a "secret"), which is more than just checking that the server 
can calculate the hash.   A future protocol's server might calculate a 
hash just like WebSockets does, but it would not be in possession of the 
"WebSocket" string. The server's possession of that "secret" is proof of 
its identity as a websockets server.

For the client validation, the "WEBSOCKET" method would be sufficient by 
itself if it could never be produced by a hijacked browser. The 
H(s-nonce, "WebSocket") would be a bit of overkill in that case, but 
it's easy to produce and strengthens the defense against future protocol 
hijacking, not specifically HTTP clients.

And if the initial client bytes do not uniquely identify the protocol as 
WebSockets (e.g. "GET") or the bytes are hijackable, then you do need to 
validate the client with something like this hash and you would want to 
check that the client possesses the "WebSockets" string in a 
non-hijackable form. If a future protocol used a similar cross-protocol 
validation technique, the hash and "WebSocket" would distinguish a 
websocket client from the future hijacked protocol. That's a stronger 
protection than the -76 random bytes, because those bytes say 
"not-HTTP"; they don't identify it as "WebSocket".

But you're right, since cross-protocol validation is a weaker 
requirement than classical authentication, it doesn't need a 
cryptographically secure hash. The shared "secret" is not secret to the 
world; it's just a secret to any non-websocket server.

-- Scott

>
> Regards,
> Maciej
>