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

[Scott Ferguson <[e-mail]>]

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.

-- Scott



-- Scott