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

From: Brodie Thiesfield <[email-masked]>
Date: Sun, 29 Aug 2010 18:21:35 +0900

Hi,

I would like to request a clarification of the current thinking of the 
working group.

I am a developer keen to use WebSocket for its ability to have multiple 
simultaneous outstanding requests from our clients over a single socket. 
My company's product currently uses SOAP over HTTP, however we are 
currently experimenting with existing browser implementations of 
WebSocket (+ flash where not supported). We are now sending the same 
SOAP requests over WebSocket and having some good results in our trials.

However, we need to support this product in corporate networks, and for 
this reason one of our biggest requirements is to be able to support 
single sign on from the desktop.

Prior to the server allowing the WebSocket upgrade request with a 101 
header, will it be valid to require authentication via standard HTTP 401 
authorization required dialog? (i.e. via Microsoft negotiate, basic, 
digest, etc). Only after the client is successfully authorized would we 
want to accept the Upgrade and change to WebSocket.

The -76/-00 protocol would not permit this (due to the extra bytes in 
the Upgrade request) however the document 
https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-requirements/ 
(REQ 8) states that connections must be HTTP up to the acceptance of the 
Upgrade, and (REQ 9) that existing HTTP components should be able to be 
reused.

Is this document the latest thoughts of the WG? Should I continue with 
the assumption that it is likely that this style of WebSocket handshake 
would be supported?

Regards,
Brodie

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 30 Aug 2010 10:44:13 +1000

Brodie,

I definitely would like to see the use-case that you describe supported.

It is true  that the -76/-00 drafts do not allow any other status
returns for a handshake, however I believe there is now consensus that
the handshake prior to the 101 response must be HTTP compliant.  Thus
I believe this implies that it will no longer be possible for the
websocket specification to disallow:

 + A HTTP persistent connection being used for HTTP and then being
upgraded to a websocket connection
 + A websocket server responding to a websocket handshake with a non
101 response code.
 + A websocket client acting reasonably when it receives a non 101
response to a websocket handshake.

I would hope to see this reflected in a draft  soon and this should at
least remove the prohibition on such use-cases.

However, removing the prohibition is not sufficient to make it a
supported use-case, as you will need buy in from servers and clients.

I do not think servers will be a problem, since if you use a HTTP
server that supports websockets, then it is very likely to just allow
arbitrary HTTP conversations to take place before the upgrade (as you
would have to do actual work to prevent that). Jetty certainly
supports this.

The problem will be the clients.  There is nothing compelling the
clients to open websocket connections using their HTTP stacks, which
may be capable of handling redirections, 401's, set-cookies and other
HTTP stuff commonly used for authentication and authorization. Even if
the clients do use their HTTP stacks for the websocket handshake,
there are problems with some features (eg 401's) which need
interaction from a user, as their may not be appropriate UI mechanisms
associated with websocket.  So either you will need to develop your
own client that you know will support the features that you want, or
their has to be a commonly accepted set of HTTP features that commonly
deployed websocket capable browsers will accept.

My feeling is that the browsers vendors are less keen on supporting
HTTP features on websocket handshakes, while the server vendors are
very keen.  I think some time and experience with real deployments is
needed for those two positions to converge.  Thus I think at this
stage having the prohibition on such features removed is the best we
can expect and that will allows  servers/browsers to experiment with
supporting HTTP features.

cheers

On 29 August 2010 19:21, Brodie Thiesfield <[email-masked]> wrote:
> simultaneous outstanding requests from our clients over a single socket. My
> company's product currently uses SOAP over HTTP, however we are currently
> experimenting with existing browser implementations of WebSocket (+ flash
> where not supported). We are now sending the same SOAP requests over
> WebSocket and having some good results in our trials.
>
> However, we need to support this product in corporate networks, and for this
> reason one of our biggest requirements is to be able to support single sign
> on from the desktop.
>
> authorization required dialog? (i.e. via Microsoft negotiate, basic, digest,
> etc). Only after the client is successfully authorized would we want to
> accept the Upgrade and change to WebSocket.
>
> The -76/-00 protocol would not permit this (due to the extra bytes in the
> Upgrade request) however the document
> Is this document the latest thoughts of the WG? Should I continue with the
> assumption that it is likely that this style of WebSocket handshake would be
> supported?
>
> Regards,
> Brodie
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: John Tamplin <[email-masked]>
Date: Sun, 29 Aug 2010 22:18:40 -0400

> supporting HTTP features.

I agree that we need to solve authentication with WebSockets, but it isn't
clear emulating HTTP Auth is the best answer.  Since the connection is under
program control and the program has presumably already authenticated itself
with the server, perhaps just providing a way to pass credentials to the
WebSocket constructor (which would then be passed in the handshake) would be
sufficient.  Of course that could always be done by client and server
agreement to send the credentials as the first message, though it may be
common enough to support it directly rather than having every app reinvent
it slightly differently.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 30 Aug 2010 13:01:29 +1000

John,

>From the point of view of a combined HTTP/websocket server, it would
be simplest if we can just use existing mechanisms for things like
BASIC, DIGEST, OAUTH, OpenID, acegi, NTML etc. etc.
So while there may be better security mechanism that could be applied
to websocket only client and servers, it would be unproductive to
prohibit the use of existing security mechanism if a way can be found
to use them.

For some of these, providing credentials ahead of time may be
sufficient, but others will be issuing challenges with nonces that
will need to be handled etc.  For the mechanisms that are already
supported in browser (BASIC, DIGEST), I would not think it would be
too difficult to support those if the browser had previously collected
credentials from the user (and it could just fail if it had not).

The hard ones are the mechanism that are not supported in the browser,
but in js libraries.  If they depend on headers, redirects and other
status codes, then such things need a way to be tunnelled through the
websocket API. I completely understand the reluctance to allow
arbitrary headers to be passed via the websocket API, yet I'm
concerned that will drive us to having to recreate new security
mechanisms that will in the end probably require some control over
headers anyway.  So I think the first step is to remove the
prohibition on using these mechanisms and then to build the consensus
on the use-cases that might justify support in the ws API.

cheers

---

From: Hector Santos <[email-masked]>
Date: Sun, 29 Aug 2010 23:03:47 -0400

> I agree that we need to solve authentication with WebSockets, but 
> it isn't clear emulating HTTP Auth is the best answer.  Since 
> the connection is under program control and the program has 
> presumably already authenticated itself with the server, perhaps 
> just providing a way to pass credentials to the WebSocket 
> constructor (which would then be passed in the handshake) would be

+1, IMO, this would be a session management implementation issue.

We had this design requirement since 1996 with our multi-device 
connections and dealing with common user session management between 
the different clients.  The server will always need to check and 
secure for independent websocket entry points.

Whether a server application needs call for signaling an 
authentication requirement via websocket is another subject to discuss.

In our design, we have two clients that can be started via a browser - 
one Native GUI, the other Java-Based. They both start a TCP session 
for interactive I/O communications over a PPP framing API layer/wire. 
So two sessions are started - one browser, one non-browser.

Regardless of how authentication takes place via browser, HTTP AUTH or 
cookies, when the non-browser is launched, a session id is passed 
which will clone the session.

If the login takes place via the native GUI client, the user has an 
option to open a homepage browser session by passing a session id as 
part of the url.

No matter what method and direction is used, the backend server needs 
to control/secure all that any way.

Overall, the issues we experience is controlling direct url request 
that might bypass the initial authentication and/or cookie settings, 
including javascripting requirements.

I don't currently see how websockets will change this or the need 
correct session management on the back one.

The following illustration can illustrate the point:

    http://www.winserver.com/public/vimg.wct?src=wcrpcnet7.png

The light yellow WCRPC is our missing piece and WEBSOCKET is what we 
excited us to possibly use.  But User can connect with any of the 
yellow WCN clients.

Session management controls is important and I will also note to 
product managers it might change any user/node licensing you have.  It 
was one of the first things we had to do back in 1996 since users were 
no long connecting just one way.

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

---

From: Hector Santos <[email-masked]>
Date: Sun, 29 Aug 2010 23:37:13 -0400

> BASIC, DIGEST, OAUTH, OpenID, acegi, NTML etc. etc.

It sounds like it might be simple, but it must be explored. The 
methods are drastically different in its human login I/O method.

> prohibit the use of existing security mechanism if a way can be found

The issue we found are mix authentication issues with similar dual or 
multi-channel client connections. This is a session management issue 
that has to be controlled and secured by the hosting server.

I think the better question is if we think allowing websocket for HTTP 
AUTH authentication is useful and that would include the browser 
websocket response 401 detection to popup the browser HTTP AUTH based 
login box.

---

From: John Tamplin <[email-masked]>
Date: Sun, 29 Aug 2010 23:41:19 -0400

> prohibit the use of existing security mechanism if a way can be found

How many websites actually use HTTP Auth to protect the data?  In my
experience, not many, because they want to control how the user logs
in and of limitations like not supporting logout.  If you let the WS
server return a 401 so the browser asks for credentials, I don't see
how you support SSO, OpenID, OAUTH, etc.  Since I would expect
virtually all WebSocket client apps to have been loaded from a normal
web server, they already have their own authentication for RPC/etc
requests back to that server for protected resources.  In that case,
what you want is to just pass those credentials to the server, whether
by some first-class WebSocket facility, passing HTTP cookies over
WebSocket, or letting the app send them in a WebSocket message.

Anyway, this strikes me as something to go over in detail when we are
further down the road from where we are.  I think we need to finish up
the framing and get basic agreement on how the handshake should look,
and then we can take up how to get credentials to a WebSocket server.

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Aug 2010 00:16:30 -0400

John Tamplin wrote:

> in and of limitations like not supporting logout.  

John, one really can't design protocols based on subjective opinions 
like this.  HTTP AUTH is a standard and it should be expected it will 
be used regardless of the perceived numbers.

I still see many sites use HTTP AUTH. Our system allows operators to 
use BASIC, DIGEST and cookie-based form logins and mixed depending on 
the user browser setting. BASIC was the original offering and there 
are still many customers using it, mostly combined combined with SSL. 
DIGEST was still optional so you didn't guarantee it and JS was still 
something that wasn't forced upon their users - for security reasons.

Of course today, you see more JS logins and we push the more 
"acceptable" javascript based logins, but its not forced.

Also, PCI requirements can caused many non-standard javascript login 
implementations to fail. DIGEST+SSL with NONCE support is acceptable 
for PCI compliance.

Also, you can have a logout box even with BASIC/DIGEST by combining it 
with a session cookie.  Issuing a 403, combining with a 401 again when 
the session cookie is not there, will invalidate the credentials in 
most, if not all the browsers tested over the years.  Only when the 
user has cookies off,  do we redirect them to a "CLOSE YOUR BROWSER" page.

> and then we can take up how to get credentials to a WebSocket server.

+1, and when we get there, IMV a key design question will be if a 401 
will trigger a HTTP AUTH browser popup or whether the websocket class 
should have a  OnAuth() event where perhaps the JS can do a redirect 
to a login page.

For that matter, offer the main "page change flow" events:

   OnAuth()      triggered by 401
   OnRedirect()  triggered by 302

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 30 Aug 2010 09:21:35 -0700

John Tamplin wrote:
> How many websites actually use HTTP Auth to protect the data?  

Non-browser clients do. With Hessian (binary RPC over HTTP), HTTP auth 
is very typical.

I'd prefer to build in WebSocket support to allow for a piggy-backed 
DIGEST-style authentication, allowing the server response to send its 
challenge and replace the clients first random bytes with an 
authentication/hello frame, which would be the DIGEST credentials.

> Since I would expect virtually all WebSocket client apps to have been loaded from a normal
> requests back to that server for protected resources.  

Non-browser clients exist and are important. You can't assume all 
interactions are from a browser.

> and then we can take up how to get credentials to a WebSocket server

We do need to make one change in the handshake, because the first client 
data (the random bytes) is the logical place to put authentication 
credentials.

If we just punt and make applications write their own authentication 
instead of piggybacking on the handshake, it would cost an extra round trip.

-- Scott

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Aug 2010 09:33:20 -0700

On Mon, Aug 30, 2010 at 9:21 AM, Scott Ferguson <[email-masked]> wrote:

> Non-browser clients do. With Hessian (binary RPC over HTTP), HTTP auth is
> very typical.
>

Is the desire here:
(1) to actually have it use digest.
(2) to be digest password store compatible.
(3) to be password compatible and challenge/response

I ask because depending on the answer this is either an argument for or
against TLS-only.

-Ekr

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Aug 2010 13:54:40 -0400

> authentication/hello frame, which would be the DIGEST credentials.

I can support the idea based on how Tamplin is viewing non-HTTP 
authentication method as the "new pseudo standard" - cookie-based 
authentication methods and how WebSocket is persistent with passing 
browser cookies.

So one may suggest to be also persistent with passing standard 
HTTP.Authorization headers as well.

Another related item is the draft to add cookie based Authentication 
schemes.

http://ltgt.net/projects/http-cookie-auth/draft-broyer-http-cookie-auth-00.html

So perhaps websocket server should begin to pass

      WWW-Authenticate: scheme

headers with the anticipation standard WWW-Authenticate: cookie 
schemes will be available and supported by WebSocket clients.  I 
believe some already using the draft guideline.

Whether the server honors or support the Authorization here generated 
by the  websocket implementation is another matter.  But it might good 
to have it available and see how its employed.

It would definitely change how we currently authenticate secondary 
session channels. But I think its worth an exploration.

> interactions are from a browser.

+1.

> data (the random bytes) is the logical place to put authentication 

When not just use the a HTTP.Authorization header?

> instead of piggybacking on the handshake, it would cost an extra round 

But you also can't prevent this - when an non-authenticate request 
comes in.

As I pointed out in a previous point, this was among the #1 issues we 
had in our framework.  It was tricky to get the right flows and it 
included redirection.

The question becomes can a websocket server trigger the websocket 
client to perform an authentication process and how is that done?

Is a 401 with WWW-Authenticate: headers sufficient?  Is a 403 
sufficient to short-circuit the request?  Do we need to redirect the 
websocket client?

etc.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 31 Aug 2010 07:37:40 +1000

On 31 August 2010 03:54, Hector Santos <[email-masked]> wrote:
> But you also can't prevent this

+1

The handshake is a HTTP request that in many cases will be directed at
a general purpose HTTP server running applications that often have
sophisticated and mandated authentication mechanisms.

It may be difficult for deployers to get an exception to a deployment
policy that says: "all web applications will use XYZ authentication",
so any inability for the handshake to penetrate work with common
authentication mechanisms will an impediment to deployment.   Allowing
authentication exceptions for websocket handshakes may complicate
authentication schemes and increase risk of human error creating
security holes. Even if authentication exceptions are allowed for the
websocket, human error will mean that sometime wrong URL will be used
and the ws handshake will see authentication failures, so at the very
least these need to be handled in a reasonable way.

I really don't think we want to be in the game of: "oh you are using
XyZ authentication! why do you want to use that? You can use WS if
only you change to use PqY authentication".  We should just work with
commonly deployed HTTP authentication mechanisms, even if we think
they are rubbish etc.

cheers

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 30 Aug 2010 15:01:23 -0700

Hector Santos wrote:
> Scott Ferguson wrote:
>
>> We do need to make one change in the handshake, because the first 
>> client data (the random bytes) is the logical place to put 
>> authentication credentials.
>

That's not possible with DIGEST with the current handshake. It is 
possible with BASIC, 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.

There's currently no place to put the Authorization credentials in the 
WebSockets handshake without forcing extra round trips.

> But you also can't prevent this - when an non-authenticate request 

Nowhere do I suggest that digest or any specific authentication scheme 
become mandatory.  I have no idea what your comment is responding to.

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.

 From the experience of Hessian, there will be non-browser clients who 
would like to piggyback on standard authentication, and not be forced to 
write their own.

-- Scott

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 30 Aug 2010 15:12:26 -0700

> commonly deployed HTTP authentication mechanisms, even if we think

What are you talking about?

I'm just pointing out that the current handshake cannot support any 
challenge/response authentication mechanism like HTTP DIGEST. It's only 
capable of HTTP BASIC authentication.

-- Scott

---

From: Brodie Thiesfield <[email-masked]>
Date: Tue, 31 Aug 2010 07:31:11 +0900

All,

> supporting HTTP features.

I can accept that it may not happen, as long as it is theoretically
possible. It seemed that it would be from the current documents, but it
obviously still has some debate to continue. It would just be easier for
us to have the browser handle the user login via the standard HTTP
authentication conversation.

Regards,
Brodie

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Aug 2010 23:18:07 -0400

Scott Ferguson wrote:
> 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).
> 
> 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.

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 31 Aug 2010 09:19:00 -0700

Hector Santos wrote:
>> possible with BASIC.

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

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.

> 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

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Aug 2010 15:42:24 -0400

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

> can piggy-back the authorization without any extra round trips.

Ok, I trust your engineering here to see this.

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

Using the specs to model in my recent "proof of concept" work, I had a 
devil of a time getting it right causing the browser (chrome) to 
continue returning an INVALID_STATE_ERR and never firing OnOpen. It 
never set the websocket.readyState to 1 (open).

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.

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 31 Aug 2010 18:39:23 -0700

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

Exactly.

> 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

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 31 Aug 2010 21:20:47 -0700

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

>>> a challenge from the server before sending its credentials. BASIC just sends
>>> the user and credentials in clear text.
>>>
>>
>>  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.
>>>>
>>>
>> 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):
>
> 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.
>
> 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.)
>
> 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.

---

From: Adam Barth <[email-masked]>
Date: Tue, 31 Aug 2010 21:59:51 -0700

On Tue, Aug 31, 2010 at 6:39 PM, Scott Ferguson <[email-masked]> 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.

Adam