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

[Scott Ferguson <[e-mail]>]

Hector Santos wrote:
> Scott Ferguson wrote:
>>> When not just use the a HTTP.Authorization header?
>>
>> That's not possible with DIGEST with the current handshake. It is 
>> possible with BASIC.
>
> If we are on the same wave length, I don't follow the HTTP AUTH 
> protocol difference.

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.

The advantage of a challenge/response style like DIGEST is you avoid 
sending the credentials in the clear. The disadvantage is that you have 
to wait for the server challenge before proceeding. For HTTP non-browser 
clients, challenge/response isn't really viable because it adds round 
trips.

But for WebSockets non-browser clients, the server challenge is already 
built into the protocol, so someone could use a challenge/response 
authentication with zero extra overhead, and gain the benefit of 
protecting the credentials from snooping.

>
>> but I'd like to allow/encourage DIGEST or better for non-browser 
>> clients (it would be invisible to the application developer).
>>
>> The DIGEST operation looks something like (numbers are packets):
>>
>>  1. client's GET/Upgrade - no authentication information
>>  2. s_nonce: server challenge (i.e. client needs to wait for a 
>> round-trip to start.)
>>  3. client auth: user, H(s_nonce, H(user, password))
>>
>
> Oh, I see. I was thinking in terms of two cases:
>
> 1) Browser Already Authenticated
>
> In this case, the browser has HTTP.Authorization
>
>    C1:  WebSocket GET/Upgrade include HTTP.Authorization
>    S2:  Handles session accordingly
>
> 2) Browser Not already Authenticated
>
>    C1:  WebSocket GET/Upgrade with NO HTTP.Authorization
>    S2:  Issue 401 with HTTP.WWW-Authenticate: scheme
>    C3:  WebSocket Closes Socket, performs login
>    C4:  WebSocket GET/Upgrade include HTTP.Authorization
>    S5:  Handles session accordingly
>
> What I am wondering is about S2, C3 and C4 in general.

That design is basically due to a HTTP limitation because the core HTTP 
protocol is C1/S2, which WebSockets can fix because its minimal 
handshake is C1/S2/C3/S4. Because of the extra packets built into the 
WebSockets handshake, you can merge your C3/C4/S5 into the standard 
C1/S2/C3/S4 saving a round trip.

The authentication handshake would look like:

  C1: WebSocket GET/Upgrade (no authorization is needed here)
  S2: WebSocket 101 with BASIC or DIGEST challenge (s_nonce or request 
for BASIC)
  C3: Client HELLO/AUTH with the authentication credentials (BASIC or 
DIGEST)
  S4: server validation of the credentials.

Which is the same as the current handshake:

  C1: WebSocket GET/Upgrade (no authorization is needed here)
  S2: WebSocket 101
  C3: Client HELLO/AUTH (credentials = 8 random bytes)
  S4: server validation of the credentials (the 8 random bytes)

The only real difference is allowing other credential types beyond the 
current random bytes. If you think of the 8 random bytes as client 
authentication, this wouldn't even change the protocol, just allow 
different authentication schemes than "random bytes."

The point I'm making is that the above authorization-required handshake 
is the exact same as our current non-authorization handshake, i.e. we 
can piggy-back the authorization without any extra round trips.

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

-- Scott