Re: [hybi] WebSocket handshake (HTTP and SSO)

[Adam Barth <[e-mail]>]

On Wed, Sep 1, 2010 at 9:19 AM, Scott Ferguson <[e-mail]> wrote:
> Adam Barth wrote:
>> On Tue, Aug 31, 2010 at 6:39 PM, Scott Ferguson <[e-mail]> wrote:
>>> a) To validate the server as websocket server (as opposed to a SMTP
>>> server),
>>> the client creates a securely-generated random nonce, c_nonce and sends
>>> it
>>> in C1. The server sends back a hash in S2, like H(c_nonce, "WebSocket").
>>> Since no server other than a websocket server will generate that hash,
>>> you've verified that the server is a websocket server.
>>
>> This assumption is not correct.  Consider, for example, a protocol
>> like DNS or an HTTP proxy where the attacker is given some control
>> over the server's response.  We have no guarantee that S2 was actually
>> generated by the server and not by some other entity and just relayed
>> by the server.
>>
>
> Yes, and that's a very important point.
>
> If the hijacker has access to c_nonce or can predict it (like a non-securely
> random c_nonce), then the hijacker can generate the hash and trick a
> non-websocket server into returning it. The browser must absolutely keep the
> c_nonce secret from the hijacker and prevent the hijacker from computing
> H(c_nonce, "WebSocket") for the hash validation of the server to work.
>
> But if the hijacker can't generate H(c_nonce, "WebSocket") himself, though,
> he can't trick some non-websocket server into computing that hash. Tricking
> a server into echoing or simple manipulation, sure, but not forcing a
> computation of a hash foreign to the server's protocol.
>
> (The same issue applies to the current protocol, even though the hash
> function is different.)

Indeed.  The security argument for the non-TLS handshake then relies
not only upon the nonces but also upon the bytes of the protocol that
surround the nonces, which is one reason why its security is dodgy.

Adam