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

[Hector Santos <[e-mail]>]

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.

> 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))
> 
> In WebSockets, #1 and #2 are HTTP, but #3 is not, it's the 
> packet with the random bytes, so you can't just use HTTP 
> header because we're no longer in HTTP mode.

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.

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'm just proposing that when non-browser clients do want to 
> use a standard authentication scheme and want save a handshake 
> round trips, that we allow that capability, which is 
> currently prevented by the current handshake design.

Yes, but unless I missing a critical point here, I don't see the 
savings is possible or worth in trying to avoid it.

If the browser session is already authenticated, then we already have 
a way to pass that information with the HTTP.Authorization header.  if 
WebSocket passed this with the same protocol mindset it used to pass 
the cookie header, I think it would work fine.

The issue I see is C2 and S3.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com