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

[Ian Fette (イアンフェッティ) <[e-mail]>]

On Tue, Aug 31, 2010 at 6:39 PM, Scott Ferguson <[e-mail]> wrote:

> Hector Santos wrote:
>
>> Scott Ferguson wrote:
>>
>>  Hector Santos wrote:
>>>
>>> DIGEST is a challenge/response style authentication, which means it uses
>>> a challenge from the server before sending its credentials. BASIC just sends
>>> the user and credentials in clear text.
>>>
>>
>> Sorry, missed this (not so) subtle point. BASIC does not require an
>> initial server challenge hence it can work unsolicited.
>>
>
> Exactly.
>
>
>>  Also probably related, I see no security benefit in this handshake. The
>>>> bad guy client can always validate a server handshake response whether it
>>>> was correct or not.
>>>>
>>>
>>> I don't understand. A bad client can't generate the correct
>>> authentication credentials. That's the whole point of authentication.
>>>
>>
>> I was referring to the websocket client random data and the websocket
>> server "reassembly" and response.
>>
>> Well, bad guys will most like implement websocket clients which ignore the
>> server response (always accept it) and simply move the ready state to open,
>> and fire the onOpen.  I didn't see how this challenge helps except maybe to
>> mitigate MITM threats.
>>
>>
> Oh.
>
> I think what it's trying to do is validate that the client is a websocket
> client and the server is a websocket server before sending any content that
> might be an attack (like a SMTP mail message or printer commands.)
>
> Here's what I think the protocol is trying to do (the actual algorithm is
> obscure):
>
> 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.
>
> b) To validate the client as a websocket client (as opposed to a hijacked
> HTTP client), the server sends a securely-generated random nonce, s_nonce
> and sends it in S2. The client sends a hash back in C3, like H(s_nonce,
> "WebSocket"). Since no hijacked non-websocket client can generate that hash,
> you've verified that the client is a websocket client.
>
> So now the websocket protocol is free to run, having verified that the
> client and server are both websocket implementations.  Of course, those
> websocket implementations might be hijacked too, or the attacking client
> might be a non-browser valid websocket client but that's a different story
> (or rather, it's the same story as my request for authentication support,
> but unrelated to the security fields in the current protocol.)
>
> Or at least, I think that's what the protocol is trying to do. To me, it
> looks like a security -through-confusion protocol hacked together by someone
> with little security experience, who believes that a complicated, confusing
> protocol is more secure than a straightforward one. If no one can understand
> it, no one can attack it, I guess. That's just what it looks like to me.
>

While I can appreciate that you may not care for the complexity of the
handshake, I would ask that you please not attack the experience of the
people involved in its design. Critiques of the protocol are certainly
welcome, but I don't think personal attacks are appropriate.



> -- Scott
>
>
>
> -- Scott
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>