Subject: [hybi] handshake status

From: John Tamplin <[email-masked]>
Date: Tue, 2 Nov 2010 17:34:17 -0400

This email is an attempt to summarize the points of debate over the handshake:

1) the use of GET+Upgrade vs WEBSOCKET vs CONNECT+BogusHost
  - a few concerns with GET+Upgrade:
    - proxies that don't support it may appear to
    - implementations may ignore Upgrade and continue as if it is a
normal HTTP request
    - attacker-controlled bytes in the GET line and the Host header
may be used to attack other protocols
  - concerns about WEBSOCKET method:
    - new method will likely impede interoperability
    - same concern about attacker controlled bytes
  - concerns about CONNECT
    - requires significant changes to current server architectures
    - bogus host address may confuse intermediaries

2) preventing attacker control of bytes in the header
    - current proposal has limited control and likely vulnerabilities
    - Adam's proposal solves this completely, at the expense of
significant complexity and possible problems with intermediaries
    - is allowing attacker controlled bytes totally a show-stopper, or
if we restrict them would that be sufficient?

3) do we need to mask payload bytes
    - doing so could ensure that the client/server both speak WebSockets
    - if not, it is possible that some attacks are enabled, but it isn't clear

If I have missed a significant point on one of these or if there are
other questions about the header, please reply with what should be
added.

We have been talking about this for a while, and I am not sure we are
making any progress.  Some options:

1) go with the current draft approach, knowing it is flawed but also
that it is currently in the wild (as browsers are shipping v76) and is
likely to stay there for at least some time
2) go with Adam's proposal (or at least the basic idea if not the
details) which seems to safely prevent attacks using WebSockets or and
mostly against WebSockets, though at the expense of complexity and
perhaps some interoperability
3) go with some variant of Greg's proposal, which is to make the
GET+Upgrade approach HTTP-compliant and restrict what the attacker can
do but not prevent all possible attacks

I am beginning to wonder if we shouldn't just punt on this in order to
get something deployed, which would be to use a dedicated port and a
dedicated handshake for the first draft, and then we can continue to
work on alternate handshakes (and perhaps TLS/NPN will be a viable
option by that time).  The problem is the longer we wait to define
something, the more entrenched v76 becomes and the less likely our
improvements since v76 will see adoption.

With a dedicated port, we don't have to worry about many of these
problems.  Some deployments of WebSocket servers would just be totally
separate from the HTTP server (which would limit the possibilities for
shared hosting services, at least initially), and others could add
separate infrastructure for receiving and processing WebSocket
connections (which seems like it would be no harder than modifying
them for CONNECT).

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

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 02 Nov 2010 15:32:37 -0700

John Tamplin wrote:
> dedicated handshake for the first draft, 

+1

A dedicated port and handshake would work with existing server 
architectures as long as the host/uri concept exists somewhere in the 
handshake, which I assume it would.

Since the sharing of the HTTP protocol is clearly a thorny issue, I'd 
rather get a clean, simple design out using a new port so we can get 
something working now, and then resolve HTTP compatibility as time permits.
> connections (which seems like it would be no harder than modifying

Yep. It would be easier because the new websocket protocol handling 
would be strictly focused on websocket.

-- Scott

---

From: John Tamplin <[email-masked]>
Date: Tue, 2 Nov 2010 18:57:17 -0400

On Tue, Nov 2, 2010 at 6:32 PM, Scott Ferguson <[email-masked]> wrote:
> A dedicated port and handshake would work with existing server architectures
> as long as the host/uri concept exists somewhere in the handshake, which I
> assume it would.
>
> Since the sharing of the HTTP protocol is clearly a thorny issue, I'd rather
> get a clean, simple design out using a new port so we can get something
> working now, and then resolve HTTP compatibility as time permits.

Ok, as a strawman to start discussion along those lines, I propose basically
Adam's proposal minus the CONNECT request/response parts and using XOR:
 - call the scheme wsdirect / wssdirect (or something similar, but basically
   expose in the scheme how the connection should be made)
 - client chooses 16-byte random nonce and sends it immediately on the
   wire
 - next the client sends HTTP-style headers (tag: value\r\n, terminated by an
   empty line) including Host (or target URI), Origin, Cookies, etc, each XOR'd
   with successive bytes of the client nonce (ie,
       output[i] = input[i] ^ clientNonce[i & 15]).
 - server replies with its own random nonce and reply headers, again XOR'd
   but with both:  output[i] = input[i] ^ clientNonce[i & 15] ^
serverNonce[i & 15].
   This validates that the server understands the WebSocket protocol.
 - after that the connection is established and WebSocket frames are
   exchanged as defined in the current draft.  I don't believe they need to be
   XOR'd, since a non-WebSocket server is highly unlikely to generate a valid
   WebSocket handshake response.

This should get through proxies as well as SSL does currently (though
some corporate
proxies may block traffic to ports besides 443).

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 02 Nov 2010 16:34:14 -0700

>    WebSocket handshake response.

Two suggestions.

  1) the first bytes should identify the protocol, something like 
"WEBSOCKET\n"

  2) I'd still like a HELLO/PING/AUTH pair for extension space for a 
challenge/response. Basically, one more frame from the client after the 
server reply. We don't need to define the auth, just allocate extension 
space for it.

--- Scott

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Nov 2010 17:22:56 -0700

> Adam's proposal minus the CONNECT request/response parts and using XOR:

If you're willing to remove the requirement to make the handshake look
like HTTP, then I think this is a pretty reasonable design.

>       output[i] = input[i] ^ clientNonce[i & 15]).

I would use the HMAC-SHA1 of the clientNonce and a WebSocket GUID, but
I'm willing to believe that's being pedantic.

>   but with both:  output[i] = input[i] ^ clientNonce[i & 15] ^

I would require clientNonce != serverNonce to prevent trivial server
implementations.

>   WebSocket handshake response.

Maciej will be sad about this bullet point because it makes it easier
for the attacker to use the HTTP facilities in the browser to attack a
not-perfectly-implemented WebSocket server.

> proxies may block traffic to ports besides 443).

Indeed.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 3 Nov 2010 11:21:01 +1100

> Adam's proposal minus the CONNECT request/response parts and using XOR:

Isn't that a fourth proposal and just adding more confusion?

Frankly, what I really would like to see, is that we follow the IETF
process of amending the draft. We have a draft that is based on
upgrade.  It has some identified problems and some proposals  that
have been made to fix them.     I think there is some consensus that
the proposals are at least an improvement on the current draft, so I
really would like to see the editor find that consensus and create a
draft -04 that represents the best we think we can do with upgrade.

In parallel, let's refine the connect proposal (which is itself a
separate draft) and come up with the best we can make that proposal.

Then once both have been refined, we can see if there is a consensus
to switch the IETF draft to use the connect proposal.

regards

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 3 Nov 2010 09:39:01 +0900

> draft -04 that represents the best we think we can do with upgrade.
So long a we're talking process, I believe it is the chairs who declare
consensus, not the editor. Feel free to ask the chairs to declare consensus
on items and I will happily incorporate them into a -04 draft. Frankly
though I was hoping we would be able to make some more meaty progress on the
handshake before -04. Internal security tests are making me rather
despondent about the current handshake, so I'm hoping we will be able to
come to an agreement on something better.

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: John Tamplin <[email-masked]>
Date: Tue, 2 Nov 2010 21:02:47 -0400

>  1) the first bytes should identify the protocol, something like

Ok.

> server reply. We don't need to define the auth, just allocate extension

What sort of benefit would you expect to get from this extra roundtrip?  Why
not just add headers in the initial request or response that would control that
(which would necessarily be an extension)?

Also, I have done some brief tests on using a dedicated port, and the results
are not good.  I have tried several production proxies, and none of them allow
CONNECT on arbitrary ports, basically only 443.  Squid's default configuration
is also setup that way, so if we move away from HTTP ports we will lose a
significant chunk of connectivity from places sitting behind such proxies.
That also means that even using port 80 doesn't help unless we use GET+Upgrade.

It is certainly possible that these proxies would be configured to
allow WebSockets
traffic, but it is likely to take time and until that time many users
would not be
able to use WebSockets.

---

From: John Tamplin <[email-masked]>
Date: Tue, 2 Nov 2010 21:12:08 -0400

> Isn't that a fourth proposal and just adding more confusion?

It doesn't seem the groups on either side of the vast chasm of
evolving the GET+Upgrade approach and a totally different approach are
showing any sign of converging, so I wanted to toss out the idea of
avoiding the issue entirely,   That is essentially what we did for
framing and extensions, and was the only way we actually made any
progress there.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 3 Nov 2010 12:21:01 +1100

> framing and extensions, and was the only way we actually made any

Oh - so this is really a direct connect proposal on dedicated port?
If so, that is a valid option to consider, but it would be clearer to
make that as a firm proposal rather than as X minus Y

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 3 Nov 2010 12:28:57 +1100

2010/11/3 Ian Fette (イアンフェッティ) <[email-masked]>:
> Frankly
> handshake before -04.

Well unfortunately it appears that the process of creating an
alternative proposal has been able to stall reasonable refinement of
the existing draft.

I don't think we should stop trying to improve the known flaws in the
current upgrade approach while all the gremlins are worked out of the
alternative proposal.

> Internal security tests are making me rather

Anything that you can reveal?

Are you testing -76, -03 or the improved upgrade hand shake that has
been proposed?

regards

---

From: John Tamplin <[email-masked]>
Date: Tue, 2 Nov 2010 23:30:42 -0400

> I'm willing to believe that's being pedantic.

I'm not sure what that buys us -- if it is just to avoid some other
server that uses
the same mechanism but happens to be listening on a dedicated WebSocket
port, I would prefer to detect it by a fixed string, either first as
has been suggested
by Scott or in the masked portion (ie, "WebSocket\r\nHost: foo.org\r\n...\r\n").

> I would require clientNonce != serverNonce to prevent trivial server

Sure.

> not-perfectly-implemented WebSocket server.

Can you describe a case where the server has successfully completed the
proposed handshake but would still be vulnerable to attack?  I am assuming that
no non-WebSocket server can complete the handshake, so if you assume that
arbitrary data in the payload can trigger bugs in the WebSocket server, it isn't
clear that the same problems can't be triggered even if the data is masked
(especially as unmasking will happen early in the processing pipeline).

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 03 Nov 2010 10:23:05 +0100

> (especially as unmasking will happen early in the processing pipeline).

This scenario involves a WebSocket server being attacked by a non-WebSocket client (specifically HTTP client code in the browser). You can use cross-site XMLHttpRequest with the HTTP POST method to make something that looks an awful lot like the WebSocket client handshake plus some WebSocket message frames.

Without payload masking, there are many parts of the client handshake that the server does not actually have to check to read message frames from the payload. Thus, it is likely these checks will be missing or buggy, since they are not required for normal operation. Therefore, the server may read and process frames, possibly leading to an integrity vulnerability.

Masking the payload (partly based on content from the server) is a total defense against this attack mode. If the payload is masked based on the handshake exchange, there is no possible way to pre-create a series of message frames that the server will read ahead of time.

Since masking the payload is cheap and makes attacks of this type provably impossible, I think we should do it.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 03 Nov 2010 10:57:50 +0100

On Nov 2, 2010, at 10:34 PM, John Tamplin wrote:

> option by that time).  

The problem here is that the dedicated port removes a lot of the value from the protocol. A lot of users are behind firewalls that don't allow connecting on arbitrary ports. While our best attempts at HTTP-like handshakes still have a dismayingly low success rate, a dedicated port could still be worse.

Using a dedicated port, we do avoid the need to try to look like HTTP at all. However, we still face the risk of cross-protocol attacks, since HTTP and WebSocket both have URI-based addressing and let you specific a port. We'd still need to make sure HTTP can't be exploited using WebSocket and vice versa.

> The problem is the longer we wait to define

That is true. However, even if we go with a dedicated port, we'd have to make sure all browsers remove v76 support to prevent the risk of entrenchment.

Regards,
Maciej

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 3 Nov 2010 11:49:40 +0100

>
>
>
> The problem here is that the dedicated port removes a lot of the value from
> the protocol. A lot of users are behind firewalls that don't allow
> connecting on arbitrary ports. While our best attempts at HTTP-like
> handshakes still have a dismayingly low success rate, a dedicated port could
> still be worse.
>
>

I imagine that the support from the initial group (naming the WHATWG)
wouldn't actually support such a drastic change after so long. I know the
HYBI list is about making a proposal for a bi-directional protocol, which
doesn't have to be WebSockets, but it would probably damaging for everyone
if it wasn't in fact WebSockets. I agree with Greg that there are existing
proposals, it would probably better to work improving and agreeing on those
than bringing an entirely new one to the table.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

---

From: John Tamplin <[email-masked]>
Date: Wed, 3 Nov 2010 08:42:25 -0400

On Wed, Nov 3, 2010 at 5:57 AM, Maciej Stachowiak <[email-masked]> wrote:
> the protocol. A lot of users are behind firewalls that don't allow connecting on
> arbitrary ports. While our best attempts at HTTP-like handshakes still have a
> dismayingly low success rate, a dedicated port could still be worse.

We have been at the stage of agreeing on most everything but the handshake for
several months with seemingly no progress, so I thought i would see if there was
support for getting a useful partial out the door while we continue to
work on an
HTTP-compatible handshake.

People seem equally entrenched on "we have to use GET+Upgrade to use
existing server infrastructure and get through corporate proxies" and
"we have to
use CONNECT and mask everything to avoid attacks", but I guess there is no
support for avoiding the problem either.  Sorry for the distraction.

---

From: Maciej Stachowiak <[email-masked]>
Date: Wed, 03 Nov 2010 16:51:04 +0100

> support for avoiding the problem either.  Sorry for the distraction.

I did not mean to completely shoot your idea down - it is an intriguing way to decouple the issues. I'm just mentioning some of the potential downsides.

Regards,
Maciej

---

From: Scott Ferguson <[email-masked]>
Date: Wed, 03 Nov 2010 12:31:31 -0700

> (which would necessarily be an extension)?
It's for authentication. An extension is fine as long as the 3-packet 
handshake/auth is supported

  C1:
  S2: challenge
  C3: response

Where the challenge/response are managed by the server, not the application.

> traffic, but it is likely to take time and until that time many users

Actually, though, that's an advantage. Long term, you'd really want to 
give administrators the capability to easily manage websockets as part 
of their policy, and allowing/disallowing ports is a straightforward way 
of doing so with an existing infrastructure.

I think the concerns of opening a new port may be overblown because it's 
strictly a short-term issue. If websockets is successful, it's 
straightforward to let the port through, and straightforward to upgrade 
proxies. Long term, having a separate port should be better from a 
management standpoint.

-- Scott

---

From: Zhong Yu <[email-masked]>
Date: Wed, 3 Nov 2010 16:43:34 -0500

> This scenario involves a WebSocket server being attacked by a non-WebSocket client (specifically HTTP client code in the browser). You can use cross-site XMLHttpRequest with the HTTP POST method to…

(I think XMLHttpRequest can only connect to the same domain, there's
no cross-site concern there.)

HTTP POST + script can be used to send data cross-site. However, if
attackers can do that, they usually can directly invoke WebSocket API
too, there is no need for attackers to fake websocket over http post.

Consequently, there is no point for a websocket server to detect fake
connections, because real connections are very accessible to
attackers. No harm will be done if a websocket servers gullibly accept
all connections and parse them loosely.

Payload masking is only helpful to existing servers on "innocent"
protocols, like smtp, so that they will not be accessed by attackers
through newly massively deployed websocket clients.

However, the non-trivial handshake already takes care of that.
Websocket clients will be of no use to attackers if the target server
cannot handshake as websocket. Connection to an "innocent" server will
be dropped immediately. Payload masking is not in play here.

Since masking adds quite some complexity, a stronger justification
should be presented.

Zhong Yu

---

From: Zhong Yu <[email-masked]>
Date: Wed, 3 Nov 2010 17:38:17 -0500

> traffic, but it is likely to take time and until that time many users

It should also be noted that it takes time to design around these problems
and until that time no user would be able to use WebSocket. It probably
takes even longer time to find a way around the proxies than the time it
takes proxies to upgrade.

A simpler websocket protocol without concern of intermediaries would
immediately work for majority of internet users. Of course, if 10% users
cannot reliably access websocket, that would be a huge headache for
huge companies like Google. Smaller/newer companies wouldn't mind
and they are happy to use a technology that can reach 90% users initially.

Zhong Yu

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 4 Nov 2010 09:11:43 +0900

On Thu, Nov 4, 2010 at 6:43 AM, Zhong Yu <[email-masked]> wrote:

> > This scenario involves a WebSocket server being attacked by a
> non-WebSocket client (specifically HTTP client code in the browser). You can
> use cross-site XMLHttpRequest with the HTTP POST method to make something
> that looks an awful lot like the WebSocket client handshake plus some
> WebSocket message frames.
>

http://www.w3.org/TR/cors/

> > Without payload masking, there are many parts of the client handshake
> that the server does not actually have to check to read message frames from
> the payload. Thus, it is likely these checks will be missing or buggy, since
> they are not required for normal operation. Therefore, the server may read
> and process frames, possibly leading to an integrity vulnerability.
> >
> > Masking the payload (partly based on content from the server) is a total
> defense against this attack mode. If the payload is masked based on the
> handshake exchange, there is no possible way to pre-create a series of
> message frames that the server will read ahead of time.
> >
> > Since masking the payload is cheap and makes attacks of this type
> provably impossible, I think we should do it.
> >
> > Regards,
> > Maciej
> >

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 04 Nov 2010 01:18:08 +0100

> no cross-site concern there.)

Not true. See the CORS specification. Or XDomainRequest in IE.

> too, there is no need for attackers to fake websocket over http post.

But you may be able to do things with the HTTP API that you can't do with the WebSocket API. There's a difference - the WebSocket API is guaranteed to check the server part of the handshake. If a server rejects by not allowing the attacker's Origin, the WebSocket API will check that before sending any WebSocket protocol messages, while an HTTP based API with message frames in the post body will not.

> all connections and parse them loosely.

I believe your argument is based on an incorrect premise (that you can do anything with the WebSocket API that could be done with HTTP APIs) and therefore the conclusion does not follow.

> Since masking adds quite some complexity, a stronger justification

AES masking may add some moderate amount of complexity, but XOR masking is trivial.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 4 Nov 2010 14:52:56 +1100

On 3 November 2010 20:23, Maciej Stachowiak <[email-masked]> wrote:
> non-WebSocket client (specifically HTTP client code in the browser).
> You can use cross-site XMLHttpRequest with the HTTP POST method >
> to make something that looks an awful lot like the WebSocket client
> handshake plus some WebSocket message frames.

Maciej,

to paraphrase your concern (please correct me if I'm wrong), the
attack vector you describe is somebody using an XHR Post (or similar)
to a web socket server, that might look something like:

   POST /some/url HTTP/1.1
   Host: the.host.com
   Headers:  normal headers added by browser
   Content-Length: 1234

   text=This is the body of the POST, that is somehow able to contain
something that
   looks like a  bit like a WS handshake
   Upgrade: WebSocket
   Connection: Upgrade
   Sec-WebSocket-Nonce: AE32FBa25CFDE215630A

   Hello Frame (or whatever the handshake needs)
   Nastygram frame
   Nastygram frame

So your fear is that a buggy implementation of the websocket server is
going to do simple string searches for the handshake fields and find
them in the body of the POST.  It will then set it's data pointer at
the CRLF in the post body rather than the first CRLF and start
handling WS messages from there.

This attack is prevented by my latest proposal as the Hello frame must
contain a hash of the client and server nonces.  So the attacker would
not be able to form the hello frame that must be received before any
of the nastygrams are handled.

I also do not see how masking helps this attack.  The attacker would
be able to mask the contents of the post and the server would unmask
and then apply the same buggy pattern matching code to the results.

Finally, it would be possible to create a test suite that would check
if servers had implemented so poorly.  Sending a handshake as the body
of a HTTP request should never result in anything other than a 400 or
some other HTTP return for the POST.  I think this stresses the
importance of being HTTP compliant before the upgrade, so that we can
test how servers handle rubbish HTTP requests like this.

regards

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 06 Nov 2010 19:37:39 +0200

On 11/3/10 12:57 AM, John Tamplin wrote:
> On Tue, Nov 2, 2010 at 6:32 PM, Scott Ferguson<[email-masked]>  wrote:
>> John Tamplin wrote:
>         output[i] = input[i] ^ clientNonce[i&  15]).
>     but with both:  output[i] = input[i] ^ clientNonce[i&  15] ^
> serverNonce[i&  15].
John,

if you want draft a proposal for a new/different handshake
I would recommend to  discuss it in a separate adhoc thread,
as you have done successfully for the framing discussion.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 07 Nov 2010 12:23:51 +0200

On 11/3/10 2:39 AM, Ian Fette (イアンフェッティ) wrote:
> On Wed, Nov 3, 2010 at 9:21 AM, Greg Wilkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 3 November 2010 09:57, John Tamplin <[email-masked]
>     <mailto:[email-masked]>> wrote:
> So long a we're talking process, I believe it is the chairs who 
> declare consensus, not the editor. Feel free to ask the chairs to 
> declare consensus on items and I will happily incorporate them into a 
> -04 draft.
as chair I don't see any clear consensus on neither of the two concrete 
proposals we have at moment

1) GET+Upgrade as emended by Greg in 
http://www.ietf.org/mail-archive/web/hybi/current/msg04534.html

    actually, I haven't seen any discussion on the Greg proposal,
    neither any good and bad aspect, if any, compared to the CONNECT one.

2) CONNECT as proposed by Adam in the draft 
http://tools.ietf.org/id/draft-abarth-websocket-handshake-00.txt
     a new version has been announced in 
http://www.ietf.org/mail-archive/web/hybi/current/msg04600.html

other possible handshake have been proposed, with also some drastic 
change (e.g. use a dedicate port for WebSocket instead of 80/443),
  but not in a clear and complete way

> Frankly though I was hoping we would be able to make some more meaty 
> progress on the handshake before -04. Internal security tests are 
> making me rather despondent about the current handshake, so I'm hoping 
> we will be able to come to an agreement on something better.
Ian: it would be interesting for the community understand if the Greg 
proposal on how improve the current GET+Upgrade handshake
would reduce the security issues you are facing testing the current 
handshake.
and if not why!

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

>     [email-masked] <mailto:[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 7 Nov 2010 11:39:02 +0100

Hi Sal,

>    neither any good and bad aspect, if any, compared to the CONNECT one.

I personally second Greg's proposal. He has proposed that several
times without much feedback while I think it's a good way to proceed for
multiple reasons :
  - it makes use of the GET+Upgrade that's been worked on since the
    first WS drafts, and some developers have improved support for
    this mechanism in their products (for instance, haproxy now
    correctly supports the Upgrade) ;

  - it fixes the non-HTTP compliance issue without changing everything

  - it addresses the issue raised by Adam about the risk that some
    intermediaries process the 101 response as a definitive one and
    would process ongoing data as a second request ;

  - it allows the server to run with low timeouts when it waits for the
    client to ACK the hello, which is an important defensive measure for
    large scale deployments.

> http://www.ietf.org/mail-archive/web/hybi/current/msg04600.html

This one is nice in some aspects but breaks routing via HTTP infrastructure,
and as Mark Nottingham suggested it in a thread on http-bis, it's likely
that some of the components who would not correctly handle the 101 will
not consider the CONNECT as a special method and might very well expect
a second request after it.

>  but not in a clear and complete way

One which was suggested was to use a 100% HTTP compliant health check but
on a different port by default. It would be up to admins to decide whether
they can share their port 80 or not. I think it may be a way to quickly
get rid of non-compliant stacks, because most admins would like to use port
80 for better accessibility, and will probably like to upgrade some of their
components when needed, without that being a requirement for protocol
adoption.

Regards,
Willy

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 07 Nov 2010 18:48:47 +0200

Hi there,

Greg has proposed an emended GET+Upgrade handshake in

he has also proposed it previously several times in other mails without 
much feedback.

It would be interesting understand what people thinks of this proposal
e.g. does it solve
- the issues implementers have discovered and raised (some of them are 
also tracked in the issues tracker)
- the security concerns (e.g. the ease to create cross protocols attacks)
    several people have raised in this mailing list (especially Adam and 
Maciej)
that are present in the current GET+Upgrade handshake present in the 03 
draft ?

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 8 Nov 2010 14:01:48 +1100

> http://www.ietf.org/mail-archive/web/hybi/current/msg04600.html

Sal,

could I ask that at this stage we not consider this as consensus issue
on Upgrade vs CONNECT.

I'd really like us to consider if there is consensus that my proposals
are better that draft-03, so that we can at least incrementally
improve the draft .

It may well be that the CONNECT proposal evolves into something that
is demonstrably  better, but I just do not see why we should hold up
progress while we are waiting for that to be the case?

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 07 Nov 2010 20:35:06 -0800

On Nov 7, 2010, at 8:48 AM, Salvatore Loreto wrote:

> he has also proposed it previously several times in other mails without much feedback.
> 
> - the issues implementers have discovered and raised (some of them are also tracked in the issues tracker)
>   several people have raised in this mailing list (especially Adam and Maciej)
> that are present in the current GET+Upgrade handshake present in the 03 draft ?

My evaluation is that Greg's proposal does not significantly improve security compared to the current 03 draft handshake, but also does not make it significantly worse.

Greg's proposal does add an extra round trip before the server can transmit, so it could have negative performance impact where connection latency is an issue.

I have not commented much on revisions of Greg's proposal as I have concluded this approach does not materially improve security against cross-protocol attacks. It is a "whack-a-mole" approach that tries to plug possible holes as they pop up. The Eric+Adam proposal, by contrast, has provable security properties.

Since Greg's proposal is not a security improvement and is a performance regression, I would rather not go with that approach, even as a temporary step.

Eric and Adam's proposal has three major differences from the current approach - using CONNECT instead of Upgrade, masking routing information, and masking payload data. I think it's worth discussing all three separately in comparison to Greg's proposal.

It would also be helpful for further review if Greg's proposal could be spelled out in full detail as an internet-draft, as has been done for the Adam+Eric proposal.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 8 Nov 2010 16:33:21 +1100

> My evaluation is that Greg's proposal does not significantly improve security compared to the current 03 draft handshake, but also does not make it significantly worse.

The main intent of the proposal is to fix the issues of the handshake
associated with the sending of unframed bytes that breaks HTTP
compliance and has already caused some otherwise-good intermediaries
to break.

With regards to security, the original intent was to do no harm over
what is in the 03 draft, but as a result of feedback some additional
security features have been added to the proposal.

> Greg's proposal does add an extra round trip before the server can transmit, so it could have negative performance impact where connection latency is an issue.

The way the proposal is written, it gives the server the option to
begin sending data before the client Hello is received.  The server
application may chose to wait until the full handshake is complete,
but if the data is not sensitive or if other authorization has already
been satisfied by the handshake (eg by tokens in cookies, headers, or
URL), then the server need not wait for the Hello from the client.

> I have not commented much on revisions of Greg's proposal as I have concluded this approach does not materially improve security against cross-protocol attacks. It is a "whack-a-mole" approach that…

How is it a whack-a-mole approach?   What mole is it whacking other
than the issue that the unframed bytes are causing some intermediaries
to stall?

> Since Greg's proposal is not a security improvement and is a performance regression, I would rather not go with that approach, even as a temporary step.

What about the issue of breaking intermediaries and HTTP compliance?

> It would also be helpful for further review if Greg's proposal could be spelled out in full detail as an internet-draft, as has been done for the Adam+Eric proposal.

I believe the full detail is there as a diff against the existing
draft.   It will significantly slow progress if every change to the
draft has to be first written up as a separate one.

regards

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 8 Nov 2010 07:21:40 +0100

> progress while we are waiting for that to be the case?

Initially I wondered whether we should try to fix the current issues in
the draft or not, but since people are regularly reporting breakage and
we're not making significant progress, fixing the draft would at least
provide the advantage of providing more realistic numbers in success/
failure reports, at least we would not have the noise created by HTTP
compliant intermediaries.

Willy

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 8 Nov 2010 07:04:50 +0000

I also like Greg's proposal. It fixes issues with the handshake as started by the working group (so should be what we focus on, as opposed to entirely new proposals), is aligned with the consensus on HTTP compatibility, and I can't see what security issues are claimed against it.

+1 for Greg's improved Upgrade. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Salvatore Loreto
> Sent: Monday, November 08, 2010 00:49
> To: [email-masked]
> Subject: [hybi] GET+Upgrade as emended by Greg (was Re: handshake status)
> 
> Hi there,
> 
> It would be interesting understand what people thinks of this proposal e.g. does
> it solve
> > times without much feedback while I think it's a good way to proceed
> > for multiple reasons :

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 08 Nov 2010 09:00:38 -0800

+1

It reuses HTTP infrastructure as desired in the requirements document.

It addresses the cross-protocol issues for both client validation and 
server validation.

Lightweight, sensible for implementers, and minimizes round-trips (the 
server can send requests immediately after the hello, and the client was 
already constrained to wait for the server response.)

-- Scott

---

From: Zhong Yu <[email-masked]>
Date: Mon, 8 Nov 2010 16:36:12 -0600

On Mon, Nov 8, 2010 at 11:00 AM, Scott Ferguson <[email-masked]> wrote:
>> I also like Greg's proposal. It fixes issues with the handshake as started
>> by the working group (so should be what we focus on, as opposed to entirely
>> new proposals), is aligned with the consensus on HTTP compatibility, and I
>> can't see what security issues are claimed against it.
>>
> It addresses the cross-protocol issues for both client validation and server
> validation.
>

In Greg's design, the server can write data to client before client is
validated. That is odd if client validation has any value. What's the
argument that this is safe?

- Zhong Yu

---

From: Scott Ferguson <[email-masked]>
Date: Mon, 08 Nov 2010 15:02:41 -0800

> argument that this is safe?

That's a good point, especially since I really want a challenge/response 
auth, and the auth response isn't available to the server until C3 is 
received.

I don't see any way of reducing those packets, though.  The challenge 
has to be issued in S2 and the response in C3 at earliest no matter what 
handshake you use.

-- Scott

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 9 Nov 2010 11:05:27 +1100

> argument that this is safe?

The server has a choice.

If it wishes to send data before the client Hello is validated, then
it should do so only if that data is not sensitive or there has been
some other authentication performed (eg an OAUTH token exists in the
header).

Note that by the time the server has sent it's Hello, the client has
already been substantially validated as it has sent a valid upgrade
request with Sec- headers in it.  So it is not an XHR or some other
tricked browser mechanism.  It is either a real WS client or an
attacker with enough power that they can pretty much perform the
entire handshake anyway, and other authentication will always be
needed to protect sensitive information.

The server may wait until the client has been fully validated.   Also
I would expect application frameworks to be developed client side and
these also might choose to not trust the application to make the right
decision - and thus prevent sends until the client has been fully
validated.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 08 Nov 2010 18:05:24 -0800

On Nov 8, 2010, at 3:02 PM, Scott Ferguson wrote:

> That's a good point, especially since I really want a challenge/response auth, and the auth response isn't available to the server until C3 is received.
> 
> I don't see any way of reducing those packets, though.  The challenge has to be issued in S2 and the response in C3 at earliest no matter what handshake you use.

The CONNECT+masking approach does the job of defending against cross-protocol attacks without introducing extra round trips.

Regards,
Maciej

---

From: Zhong Yu <[email-masked]>
Date: Mon, 8 Nov 2010 22:38:54 -0600

> already been substantially validated as it has sent a valid upgrade

I totally agree here, and my position is that the client HTTP
handshake  is enough for server to validate the client; I'm unable to
come up with a realistic scenario where further client validation
helps improve security. I like the symmetry in your design -
challenge-response are carried out in both directions. However I don't
think the threat is symmetric - client needs to challenge server, far
more than server needs to challenge client.

An exchange of WS frames on the wire is probably still a good idea to
test the connection for WS friendliness. I don't think it violates
HTTP spec if the client sends the HTTP handshake, without waiting
response from server, sends a WS frame immediately. Some intermediary
could withhold the WS frame until the HTTP is responded. I think
that's a short term, not too serious, latency problem

- Zhong

---

From: Zhong Yu <[email-masked]>
Date: Mon, 8 Nov 2010 22:53:53 -0600

> The CONNECT+masking approach does the job of defending against cross-protocol attacks without introducing extra round trips.

Greg's design has an extra challenge from server to client, which is
not present in draft-03 or Adam's design. It may address some threats
that the two other design are vulnerable to. However I don't think
these imagined threats are realistic.

I also think masking is unnecessary. If a non-WS server is vulnerable
to certain texts that attackers can place in plaint WS handshake, the
server is vulnerable to similar injection attack via HTTP clients.
Introducing masking in WS will not protect any non-WS server from such
attack.

A counter argument to that is, if we follow this line of logic, we'll
never improve our security. If we beef up WS handshake regardless, one
day HTTP clients may fade out, then we'll have an overall improved
security.

That is looking too far into the future, while are are standing still
going no where.

- Zhong

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 9 Nov 2010 06:33:47 +0100

> The CONNECT+masking approach does the job of defending against cross-protocol attacks without introducing extra round trips.

It would be nice to ensure there is no confusion of the features :

  - CONNECT is an alternative to Upgrade
  - masking is an alternative to the server hello

We could very well have Upgrade + masking or CONNECT + Hello. What I
take from your suggestion is that we could avoid a round trip by masking
the exchanges, and probably that those two should be compared in a
separate thread.

Regards,
Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Nov 2010 07:28:55 -0800

> these imagined threats are realistic.

I don't think the extra message from the client to the server in Greg's design adds meaningful extra security. The very fact that it is optional to wait for it or check it means it has extremely limited security value, since no one will notice if the check is missing or buggy. Things will still seem to work fine.

> Introducing masking in WS will not protect any non-WS server from such

That's incorrect. In-browser HTTP clients are greatly restricted in what they can send. WebSocket bypasses those restrictions. HTTP servers can be vulnerable to WebSocket clients in ways that cannot come up with in-browser HTTP clients.

Furthermore, WebSocket servers can be vulnerable to in-browser HTTP clients. Masking helps protect against that attack vector as well.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Nov 2010 07:33:13 -0800

> the exchanges, and probably that those two should be compared in a

More specifically, masking is a replacement for the client hello frame that:

(a) Does not require an additional round trip.
(b) Forces the server to check validity of the client, instead of making it optional (because the server will be unable to interpret message frames at all without effectively checking correctness of the client's masking).

We already had a thread about payload masking, and it did not seem at that time that there were strong arguments against it. The strongest argument was about computational cost of streaming AES, which is now addressed by using XOR instead.

Regards,
Maciej

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 09 Nov 2010 08:46:43 -0800

> the exchanges, and probably that those two should be compared in a

Good point.

As long as there's an extension allowing challenge/response by the 
server, as John pointed out earlier, the hello can be replaced with masking.

The reason I'm harping on the challenge/response is because of 
auth-snooping like firesheep. A challenge/response hides the 
authentication credentials from the attacker. (And I'm thinking 
non-browser phone/pad apps, which might authenticate directly, not using 
a cookie from an earlier HTTP request.)

-- Scott

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Nov 2010 09:19:07 -0800

On Nov 9, 2010, at 8:46 AM, Scott Ferguson wrote:

> As long as there's an extension allowing challenge/response by the server, as John pointed out earlier, the hello can be replaced with masking.
> 
> The reason I'm harping on the challenge/response is because of auth-snooping like firesheep. A challenge/response hides the authentication credentials from the attacker. (And I'm thinking non-browser phone/pad apps, which might authenticate directly, not using a cookie from an earlier HTTP request.)

The only really effective projection against Firesheep-like attacks is to use SSL.

Regards,
Maciej

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 09 Nov 2010 10:14:19 -0800

> The only really effective projection against Firesheep-like attacks is to use SSL.

That's not true for the restricted problem of keeping authentication 
credentials secret.

-- Scott

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Nov 2010 10:42:08 -0800

On Nov 9, 2010, at 10:14 AM, Scott Ferguson wrote:

> That's not true for the restricted problem of keeping authentication credentials secret.

Firesheep isn't based on stealing your authentication credentials. It hijacks your session without needing to steal your credentials. Specifically, it works even in cases where your username and password never go over the wire in plaintext.

In any case, the challenge-response aspect of Greg's protocol would not do anything to protect credentials, since the challenge and response only attempt to prove that the party at the other end is a real WebSocket client/server, not that it possesses particular credentials.

Regards,
Maciej

---

From: Zhong Yu <[email-masked]>
Date: Tue, 9 Nov 2010 14:49:44 -0600

>  - masking is an alternative to the server hello

I don't think so. masking is more like an extra challenge initiated
from client. A server needs to be WS savvy to unmask before responding
meaningfully.

That is different from server hello, in which the server initiates an
extra challenge to client.

I think both are addressing some vague threats without realistic
examples. I don't think these extra challenges actually improve
security on what's already in place, that is, WS server parses HTTP
head carefully to make sure the request comes from a WS client; WS
client checks server's response to make sure it's from a WS server.

---

From: John Tamplin <[email-masked]>
Date: Tue, 9 Nov 2010 15:56:34 -0500

> client checks server's response to make sure it's from a WS server.

Masking also protects intermediaries and non-WebSockets endpoints from
interpreting WebSockets content as something else.

---

From: Zhong Yu <[email-masked]>
Date: Tue, 9 Nov 2010 15:11:19 -0600

> interpreting WebSockets content as something else.

Agree. However, if a server serves protocol X, and it parses incoming
stream liberally, so that an unmasked/plain WS request could be
interpreted as a X request, that server will also interpret some HTTP
requests as X requests. An attacker can use an HTTP client to carry
out his attack.

X has to be some old protocol, for example SMTP. It is likely that a
SMTP server has been beefed up so that it will reject any HTTP
connection. I fail to see then how it will not reject a WS connection,
which starts as HTTP connection.

- Zhong

---

From: John Tamplin <[email-masked]>
Date: Tue, 9 Nov 2010 16:20:01 -0500

> requests as X requests. An attacker can use an HTTP client to carry

As has been mentioned several times, WebSockets allows JS code to open
a socket to any machine on any port.  HTTP does not allow that via XHR
(even with CORS you have to pass a preflight request check).

---

From: Zhong Yu <[email-masked]>
Date: Tue, 9 Nov 2010 15:32:01 -0600

On Tue, Nov 9, 2010 at 9:28 AM, Maciej Stachowiak <[email-masked]> wrote:
> That's incorrect. In-browser HTTP clients are greatly restricted in what they can send. WebSocket bypasses those restrictions.

Can you elaborate on that? When an attacker wants to connect to a
non-HTTP/non-WS server from a browser, he can use either HTTP post or
WS(unmasked). In what scenario the attack can succeed with
WS(unmasked), but not with HTTP post?

>HTTP servers can be vulnerable to WebSocket clients in ways that cannot come up with in-browser HTTP clients.

I don't understand. Certainly the WS handshake must fail, a pure http
server cannot respond the ws challenge by accident. Therefore all the
malice content must be included in the client handshake. The attacker
want this WS client handshake to be interpreted as one or more HTTP
request - But why bother? The attacker can issue genuine HTTP requests
from browser.

> Furthermore, WebSocket servers can be vulnerable to in-browser HTTP clients. Masking helps protect against that attack vector as well.

True. Yet if a ws server does basic decent parsing, it will not
confuse HTTP with WS. Most likely, the server treats every connection
as HTTP request at first. If a valid HTTP request is received, it
looks for "Upgrade: WebSocket". If present, the connection is from a
WS client, not an HTTP client. I don't see how can an attacker use a
HTTP client to fake WS client handshake that can fool this server.

- Zhong

---

From: Zhong Yu <[email-masked]>
Date: Tue, 9 Nov 2010 15:41:05 -0600

> As has been mentioned several times, WebSockets allows JS code to open

JS can send HTTP POST request to any machine on any port.
JS can issue WS handshake request to any machine on any port.

So I don't think there's a difference there. The HTTP POST is actually
more powerful to attackers, because you can attack any data in it.
WebSocket handshake is more restrictive; it can carry less
attacker-specified data; connection is immediately terminated if
server isn't WS compliant.

In both cases, attacker cannot read anything from server (which is on
a different origin).

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Nov 2010 14:02:51 -0800

> extra challenge to client.

Not quite. The payload masking proposed by Adam is partly based on a random number sent by the server in its handshake response. Therefore, to mask correctly, the client needs to read and correctly process the server response. Further, to decode message frames from the client, the server is forced to check that the client did this correctly. Thus, effectively the masking is an implicit challenge-response, one that both sides have to do correctly to be able to exchange messages.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 10 Nov 2010 09:12:27 +1100

Guys,

we really need to break this down.

The PRIMARY purpose of my proposal was to fix the problem with
intermediaries poorly handling the unframed bytes.
The SECONDARY purpose of the proposal is to provide a fast fail
mechanism to check that a connection can send/receive WS frames (by
actually sending/receiving WS frames).

The whole security thing is a huge distraction from this.   Not
because it is not important, but because almost all of the security
techniques suggested can be equally applied to both Upgrade and
CONNECT.     However, since the feedback about the proposal has been
overwhelmingly about security, I did include some security features in
it (eg inverting bits, server nonces etc.) - But these are not
intended to be the final sentence on WS security - but just to try to
get past the security feedback so that we can fix the real problems
that the protocol handshake is having now.

Note that EVEN if we use masking in GET+Upgrade to establish either
end is WS, I would still propose a Hello frame exchange so that we can
test that intermediaries are indeed functioning after the upgrade.
In fact with the current handshake, I was opposed to the random bytes
having the mixed function of testing the connection and carrying
security information.      So if somebody wants to propose a masking
solution that works entirely in the GET and 101 response, then we can
take the nonce and hash out of the Hello frames - but I still think we
need them (or at least a ping/pong) to check the connection before
telling the client it is open.

cheers

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 09 Nov 2010 14:54:35 -0800

> Firesheep isn't based on stealing your authentication credentials. It hijacks your session without needing to steal your credentials. Specifically, it works even in cases where your username and pa…

The session cookie is a temporary authentication credential, Maciej.

The basic structure of the attack is:

  1) snoop plaintext authentication
  2) replay the authentication

In the case of firesheep, the stolen auth credential is the cookie.

The websocket protocol is currently vulnerable to a firesheep-style 
attack because its authentication is in plaintext (currently, 
cookie-authentication.)

I just want -- as an extension -- a way for servers with higher security 
needs to authenticate where the credentials are not snoopable.

> In any case, the challenge-response aspect of Greg's protocol would not do anything to protect credentials, since the challenge and response only attempt to prove that the party at the other end is…

That's why I have asked for extension space for an authentication 
extension to piggyback its own challenge/response on Greg's existing 
challenge/response without wasting additional round trips.

-- Scott

---

From: Zhong Yu <[email-masked]>
Date: Tue, 9 Nov 2010 17:23:26 -0600

> Not quite. The payload masking proposed by Adam is partly based on a random number sent by the server in its handshake response. Therefore, to mask correctly, the client needs to read and correctly…

You are correct, it is equivalent to server challenge. (which I think
is unnecessary:)

---

From: Zhong Yu <[email-masked]>
Date: Tue, 9 Nov 2010 17:34:05 -0600

> actually sending/receiving WS frames).

I really like that. (although I think it's ok for client to send a WS
frame first)

- Zhong

---

From: John Tamplin <[email-masked]>
Date: Tue, 9 Nov 2010 18:35:58 -0500

On Tue, Nov 9, 2010 at 5:54 PM, Scott Ferguson <[email-masked]> wrote:
> That's why I have asked for extension space for an authentication extension
> to piggyback its own challenge/response on Greg's existing

I don't believe there would be anything preventing an extension,
advertised in the client request, from adding what you want.  For
example, the client sends:

Sec-WebSocket-Extension: x-my-auth; data="xxx" (or an additional
header if you like)

The client obviously sends any "Hello"-type frame that we decide to
include because it doesn't know if the server will accept the
extension.  The server sees the extension and accepts it, sending back
the extension in the header as well as a challenge (perhaps as a param
to the extension, perhaps as another header, or perhaps as an
additional frame sent right after the handshake data).  The client
sees the extension was accepted, and can respond to the server
challenge as defined by the extension before declaring the WebSocket
open.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 10 Nov 2010 00:48:01 +0100

>request - But why bother? The attacker can issue genuine HTTP requests

The typical setup is that you have one high level component that reads
incoming bytes and decides where a HTTP message begins and where it ends
and a lower level component that takes the message and produces some re-
sponse which it then passes on to the higher level component which then
puts it on the wire. You need to perform the Websocket handshake with
the high level component, or the high level component must ensure that
the low level component cannot perform the Websocket handshake without
its approval.

With typical setups the high level components do not currently do that,
so we have a proposal to make the handshake such that the high level
component has trouble dispatching messages to lower level components
(that's obscuring path and host in the handshake) and a proposal that,
if that is insufficient, minimizes the odds that an attacker can ex-
ploit the high level components failure to ensure that it controls all
aspects of the communication that it needs to control (that's obscuring
the actual websocket frames).

With HTTP POST requests the high level component will stay in control
all the time, it knows where a message begins and where it ends, and
the lower level component cannot persuade the browser to send anything
but more HTTP POST requests. Websocket breaks out of both the normal
HTTP message structure and the HTTP identity model where targets are
identified in the HTTP host header. This isn't a problem if indeed the
high level component makes the decision whether it is willing to deal
with Websocket traffic, but that is hard to ensure.

The simple example for where this is a problem is a shared hosting
scenario where server 1.2.3.4 hosts a.example and b.example. You need
the software controlling all of 1.2.3.4 to be aware it has to expect
Websocket frames on a connection, performing the handshake only with
a.example or b.example may leave the server think it is to expect HTTP
message, while the browser sends Websocket messages, and if an attacker
can control those messages, it can make the browser send HTTP requests
(frames that look like that) it would not otherwise send to 1.2.3.4.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Scott Ferguson <[email-masked]>
Date: Tue, 09 Nov 2010 15:50:33 -0800

> challenge as defined by the extension before declaring the WebSocket

Ok. And if the client doesn't send the extension request, the server 
sends back some kind of "required extension missing, please use 
x-my-auth" response instead of the 101?

that works for me.

-- Scott

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Nov 2010 15:51:05 -0800

> The session cookie is a temporary authentication credential, Maciej.

It's a session token that is often sent in plaintext after exchanging the primary credential envrypted.

> The websocket protocol is currently vulnerable to a firesheep-style attack because its authentication is in plaintext (currently, cookie-authentication.)
> 
> I just want -- as an extension -- a way for servers with higher security needs to authenticate where the credentials are not snoopable.

An attacker on your local network segment (already the threat model for Firesheep) can just hijack your established WebSocket TCP connection. It's only a little less trivial than what Firesheep does currently. You can patch this in various ways, for example, include challenge-response and an HMAC of the payload with every frame, but if you are going to go to such lengths, you may as well just use SSL, and a single challenge-response exchange doesn't help in any case.

> That's why I have asked for extension space for an authentication extension to piggyback its own challenge/response on Greg's existing challenge/response without wasting additional round trips.

You can easily do this in-protocol. Greg's proposal is a solution to this only in that it is already wasting additional round trips.

But really that won't protect you from session hijacking anyway, so just use SSL.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Tue, 9 Nov 2010 19:33:37 -0500

On Tue, Nov 9, 2010 at 6:50 PM, Scott Ferguson <[email-masked]> wrote:
> Ok. And if the client doesn't send the extension request, the server sends
> back some kind of "required extension missing, please use x-my-auth"
> response instead of the 101?
>
> that works for me.

Sure, if the server is unwilling to connect to any client not
implementing the extension.

---

From: Zhong Yu <[email-masked]>
Date: Wed, 10 Nov 2010 19:39:16 -0600

Greg: when thinking about Bjoern Hoehrmann's example regarding a
dispatcher in a virtual host, I realized that such dispatcher can be a
problem in your design where the server sends the first WS frame.

It's very plausible that a virtual host dispatcher passes along any
bytes from server to client verbatim and without delay - it doesn't
care about responses. However non-http bytes from client to server are
parsed - the dispatcher needs to find Host header. Therefore these
bytes can be stalled; they can be maimed when they do pass through.

In your handshake, the WS client may receive the server Hello promptly
and mistakenly think that the connection is well established, yet the
client Hello has problem reaching the server. The client can hold this
mistaken belief for quite a long time, until the server times out an
closes the connection(if the server checks for client Hello)

- Zhong Yu

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 11 Nov 2010 15:01:03 +1100

Zhong,

I think there are always going to be failure modes with any handshake
were this is going to be a problem.  Even with perfectly good
intermediaries, networks may still fail and clients can be left with
the belief that they have a connection when they do not.    There is
no solution that does not eventually need some form of keep alive to
check the connection has not silently failed immediately after the
handshake or at any time after it has been established.

cheers

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 11 Nov 2010 07:36:39 +0100

On Wed, Nov 10, 2010 at 07:39:16PM -0600, Zhong Yu wrote:
> care about responses.

Those are the ones we prefer, they have no risk of mangling our data
nor being smart on anything.

> However non-http bytes from client to server are parsed - the dispatcher
> needs to find Host header.

No, the host header is before any non-http bytes. The dispatcher reads
the client request, find the host header and dispatches it where it
wants, then will let any data flow between the client and the server
without caring at all about them. If it does not find a host header,
it will act as it wants : either considering a default destination,
or rejecting the request. But the host header cannot be looked for in
data.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 11 Nov 2010 07:42:07 +0100

> I really like that. (although I think it's ok for client to send a WS

Yes it is OK for a client to send the WS frame first, however most will
refrain from doing so because if the request fails (eg: authentication),
they have to close the connection because of the already sent data which
have polluted the connection. That's why while in theory, having the WS
client send the frame first avoids one round trip, in practice it will
not because browsers won't use that optimization.

That's the same as with CONNECT through proxies. Browsers are free to
send their HTTPS request just after the CONNECT request to save one
round trip, but in practice they don't and prefer to wait for the 200
response to ensure they can use the connection.

Willy

---

From: Zhong Yu <[email-masked]>
Date: Thu, 11 Nov 2010 13:10:36 -0600

> response to ensure they can use the connection.

The client Hello WS frame I was talking about is part of the handshake
that helps to determine whether the connection is usable for WS. The
WS client should send it in the same packet of the HTTP handshake
stuff.

I am also under the impression that a WS connection is always a new
connection. A previous HTTP connection will never be re-purposed by
browser for WS. A WS connection will never be re-purposed by browser
for HTTP.

- Zhong Yu

---

From: Zhong Yu <[email-masked]>
Date: Thu, 11 Nov 2010 14:00:43 -0600

> handshake or at any time after it has been established.

Still, we can contemplate which is relatively better, Client-Server
hello, or Server-Client hello.

If exchange of hellos is not completed within a time window, say 5
second, connection is aborted in either case. However there are still
significant differences.

In the Client-Server case, the client spends 5 seconds waiting for
completion. UI can display a busy icon so the user knows it is trying
to establish a connection. After 5 seconds, the client closes the
connection (in the TCP sense)

The server simply waits for client Hello. It doesn't need to set a
timeout, the client will close the connection after 5 seconds
anyway(assuming TCP FINs are delivered at light speed). If the server
got the client Hello, it will assume that the connection is
established, which is false. The *server* got the wrong impression. It
may even immediately send some app data to client (none of which will
be delivered to client app), then the connection is closed in 5
seconds. Poor Server.

In the Server-Client case, If the client got the server Hello
immediately, it assumes that the connection is established, which is
false. The *user* got the wrong impression. The app seems working at
first, then stops working in 5 seconds. Poor User.

The server isn't deceived though. It never assumed that the connection
is established. It closes the connection after 5 seconds.

Compare the two cases, I think the first one is better from user's
point of view.

The second case is better for servers, but who cares about servers?
Servers have no feelings.

- Zhong

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 13 Nov 2010 10:46:43 +1100

> browser for WS. A WS connection will never be re-purposed by browser

The current spec is written that way, and I expect that current
browsers are implemented that way.

However, I see this as an unnecessary restriction on the protocol that
will harm performance and will not reduce complexity.

If a browser has a pool of existing HTTP connections to a server, then
it can make a lot of sense to use one of them to upgrade to WS.  This
will prevent another round trip and will likely avoid holding open a
HTTP connection that would otherwise be idle and eventually timeout.

The required extra complexity on the client is zero, as they are not
required to do this.  They can always use a fresh connection if that
is simpler and would only need reuse and idle connection if there were
demonstrable performance gains.

On the server side, it is actually simpler to not enforce that
upgrades are only the first request on a connection.  Currently a HTTP
server just processes requests as they arrive and if one happens to be
a successful upgrade then the server can switch to WS without the need
to check if the request was the first or not.  On a dedicated WS
server, HTTP requests prior to an upgrade will just result in normal
error handling and the connection will be closed.

Thus I believe we should drop all reference to the upgrade being the
first and only request on a HTTP connection.  It saves us no
complexity and prohibits a potential performance improvement.

cheers