Subject: [hybi] Computation requirement in the handshake

From: Silvio Ventres <[email-masked]>
Date: Thu, 24 Feb 2011 19:52:34 +0200

Hello, Ian.

You noted handshake includes the computation step to "prove that
server actually parsed the header".

Counter-argument: author that doesn't _want_ to parse the header will
find a way to _not_ parse the header,
for example, by using an external tool/library to complete the handshake.

Please let know if there are any other reasons for the computation in
the handshake.
If there are none, please remove the feature, as it serves no actual
purpose and impacts
the complexity of the protocol.

--
 silvio

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 24 Feb 2011 09:58:03 -0800

An external tool/library to parse the WS handshake indicates that the
handshake was actually parsed by something that has an understanding of
websockets, and not just some non-WS endpoint that was tricked into replying
to a WS handshake, so this does not seem like a problem and seems like it
would be in-line with the goals.

-Ian

---

From: Silvio Ventres <[email-masked]>
Date: Thu, 24 Feb 2011 20:05:26 +0200

> would be in-line with the goals.

How do you see a non-WS endpoint can be tricked into replying to a
magic string and
echo based handshake ?

Do you expect a non-WS endpoint to be able to answer the WS request
with a WS-specific MAGIC STRING,
such as: "101 WebSocket-MagicString" and an echo of the relevant field ?

The computation part of the handshake could be reasoned to prevent
implementation
of buggy endpoints that want to seem WS-compliant but aren't, but it
seems you don't
insist on that reason.

--
 silvio

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 24 Feb 2011 19:33:40 +0100

>for example, by using an external tool/library to complete the handshake.

The goal is that if a Websocket client attempts to connect to a server
that is not a Websocket server, then the handshake fails. That requires
that the server does something that is unique to the Websocket protocol,
something that an attacker cannot make a non-Websocket server do.

We know that you can make servers echo data that is sent to it, so the
server is required to transform the data in a manner that is unique to
the Websocket protocol. That way the server would only generate a right
response by random chance.

It is likely that there is actually no way to make deployed servers get
other aspects of the handshake right, like sending the right status code
and the right Upgrade header, but the unique process is cheap, so it's
used instead of contemplating how robust the protocol is without it.

If this is not clear from the current draft, suggestions how and where
to explain this better are most welcome.

Thanks for raising this issue in a separate thread.
-- 
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: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Thu, 24 Feb 2011 10:45:12 -0800

One of the assumptions made as part of the security model is that there are
non-WS endpoints that you can get to echo things. As such, if you (attacker
JS) send that "magic string" as part of your attack, you could potentially
get the attacked-server to echo that. By having the browser send something
outside of JavaScript control, and having the server perform computation on
that something, we have more robustness.

Also, it's cheap and easy to reason about, and prevents a larger class of
attacks than you are focused on.

I really don't see much point in reopening this discussion. This is not
adding anything.

---

From: Silvio Ventres <[email-masked]>
Date: Fri, 25 Feb 2011 17:32:11 +0200

> get the attacked-server to echo that.

The original "magic-string" and "echo" solutions focused on the
requirement to make sure
the WS clients don't _inadvertently_ , by chance, stumble upon an HTTP
server and try to
communicate with it as if it was WS-compliant.

If you think that there is an attack vector in making an HTTP server
seem WS-compliant,
please elaborate on what you perceive as a likely attack scenario.

--
 silvio

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Feb 2011 15:35:00 +0000

> communicate with it as if it was WS-compliant.

That's the attack.

The idea is that an attacker uses websockets to communicate with a  
pure-HTTP server, and manages to mount a cross-protocol attack  
against it.

This mechanism prevents that attack by forcing the attacker's target  
to understand at least this much of the WS handshake.

Dave
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Silvio Ventres <[email-masked]>
Date: Fri, 25 Feb 2011 17:53:27 +0200

>> communicate with it as if it was WS-compliant.

Dave, where is the attack here ?
The HTTP server would've provided the data anyway, so there is no
problem getting it by WS.
The JS writer already has the control of the JS execution, so he gets
no additional benefit from
the server response.

If an HTTP server, which sends data by HTTP normally, is made by some
smart web developer
to provide data in a compliant way to a WS client without changing the
HTTP server binary, that's
an ingenious solution that should be applauded.

What is the probable attack _scenario_ that you envision if the
computation part is removed?

--
 silvio

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Feb 2011 16:00:49 +0000

> computation part is removed?

The attack is a naïve HTTP server being deliberately confused by the  
(mis)use of the websocket API in the browser.

If you search through the archives for discussions concerning  
cross-protocol attacks, you should find the original discussion -  
you'll note that this was rehashed in entirety shortly after the IETF  
adopted the protocol, and so has gone through two sets of scruitiny  
and survived.

I'm highly skeptical about most of the security complexity added to  
this protocol, but the original arguments on this convinced me - I  
recommend you find them.

Dave.

---

From: Silvio Ventres <[email-masked]>
Date: Fri, 25 Feb 2011 18:06:01 +0200

> (mis)use of the websocket API in the browser.

Why did you respond to this request if you don't remember or don't want to
quote the attack _scenario_ ?

> I'm highly skeptical about most of the security complexity added to this
> protocol, but the original arguments on this convinced me - I recommend you
> find them.

If the attacks were actually probable and convincing, you should have remembered
and quoted them, instead of pulling the "go read archives" card again.

--
 silvio

---

From: Brian McKelvey <[email-masked]>
Date: Fri, 25 Feb 2011 08:07:30 -0800

Also, websockets significantly relaxes the same-origin policy that binds xhr.  If you *could* gain access to data from another non-consenting domain via a cross-protocol attack against http, that represents a cross-site-scripting vulnerability as well.

That said, I think this scenario highly unlikely.  The handshake we have in place now is simple enough and at the same time categorically protects against this kind of attack. It's a good compromise.

Brian

Sent from my iPhone

On Feb 25, 2011, at 8:00 AM, Dave Cridland <[email-masked]> wrote:

> The attack is a naïve HTTP server being deliberately confused by the (mis)use of the websocket API in the browser.
> 
> If you search through the archives for discussions concerning cross-protocol attacks, you should find the original discussion - you'll note that this was rehashed in entirety shortly after the IETF adopted the protocol, and so has gone through two sets of scruitiny and survived.
> 
> I'm highly skeptical about most of the security complexity added to this protocol, but the original arguments on this convinced me - I recommend you find them.
> 
> Dave.
> -- 
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Feb 2011 16:21:28 +0000

> quote the attack _scenario_ ?
But I did. There isn't a detailed exploit documented for a number of  
reasons - not least because the framing was still up in the air at  
that point. It may not even be possible, but it's a terribly simple,  
and one-off, bit of code.

It might be true that masking also protects against this particular  
pattern, mind, but I'm choosing to remain optimistic we'll eventually  
be able to discard masking, so having this protected against  
separately seems beneficial to me.

> and quoted them, instead of pulling the "go read archives" card  

Nope, because it was discussed over a period of several weeks around  
a year ago, and I've long-since put it out of my mind. I can barely  
recall the people involved in the thread, I'm afraid. I do remember  
enough to summarize the essentials, though, which I did for you. If  
you care about the original discussions, please do the digging  
yourself.

Besdies which, whether I've forgotten something has no bearing on its  
importance, otherwise my wife's birthday would rank equivalent with  
whether I've fed the cats this morning. ;-)

Dave.