Subject: [hybi] Deployability of NPN (was Re: Handshake was: The WebSocket protocol issues.)

From: Adam Barth <[email-masked]>
Date: Mon, 27 Sep 2010 10:26:14 -0700

On Mon, Sep 27, 2010 at 6:40 AM, Patrick McManus <[email-masked]> wrote:
> On Sun, 2010-09-26 at 23:26 -0700, Adam Barth wrote:
>> On the other hand, we can be reasonably assured that the TLS+NPN
>> handshake resists cross-protocol attacks.
>
> >From a NPN advocate I would like to see a strong argument on the
> deployabiltiy of a NPN based handshake.

NPN is currently being used on a large scale by SPDY (albeit with only
a handful of implementations at this time).  Support has landed / will
soon land in the major client and server TLS libraries.  NPN is
certainly harder to deploy than a Perl script full of regular
expressions, but it's mostly a matter of upgrading your TLS library
and flipping on the right bit.

> >From some weak research that is open to more information:
>
> * I'm concerned that it looks like the TLS working group doesn't have
> consensus support for NPN.

My read of the discussion was a follows:

1) It took a few rounds for folks to understand what problem NPN was
solving, probably because the -00 version of the draft wasn't clear on
this point.  Hopefully the -01 clarifies that issue.

2) Various folks had different opinions about how early in the
handshake should the parties discuss which protocol they wished to
speak next / the set of protocols they are able to speak.  The are
interested trade-offs here that are worth discussing, but whatever the
TLS WG decides will likely be fine for WebSockets.

> * I wonder how settled the draft is? It looks like openssl 1.1.0 has
> patches for draft-00, but the draft-ietf is 01.. are they compatible?

Yes.

> Will there be more drafts?

My understanding is that Adam Langley is open to feedback from this
working group, from the TLS working group, and from the IETF more
generally.  Certainly if/when the TLS working group takes the document
up as an working group item, I would expect there to be more drafts.

> Is it advisable to tie the WS timetable to that uncertainty? (we have uncertainty of our own :()

These concerns are separable.  We can work on framing and the other
parts of the handshake (origins, feature negotiation) in parallel.
Because NPN operates at a lower layer than the rest of what we're
talking about, there aren't very many dependencies between the work.

Of course, final implementations will need to wait for both pieces of
work to be done, but NPN isn't that complicated.  I'd expect it to be
done well before the rest of WebSockets.

> * I'm concerned that TLS stacks on the server side are deployed
> independent of the stacks that will implement websockets and waiting for
> them to make the necessary enabling change would create a very
> substantial barrier to implementation. It isn't hard to imagine it being
> so substantial that -76 would just become the defacto standard even with
> uptake of draft-ietf-ws from browser and server authors.

That depends largely on what browsers ship.  If browsers stop shipping
-76, then it will not become the de facto standard.  If browsers
continue to ship -76, then it will likely become the de facto standard
regardless of what we do.

To address your broader question, the real gating factor for
deployability of WebSockets is adoption by web application frameworks,
such as Ruby-on-Rails.  If Ruby-on-Rails (and similar frameworks) add
support for WebSockets, then many application developers will benefit
from the protocol.  Given that Ruby-on-Rails (and I imagine other
frameworks) already ship custom HTTP servers, I'd expect it's mostly
irrelevant to them whether or not we use NPN.  If we do, they'll just
use a newer version of OpenSSL than they might have otherwise.

Adam

---

From: Patrick McManus <[email-masked]>
Date: Mon, 27 Sep 2010 17:34:54 -0400

> done well before the rest of WebSockets.

Personally, given that NPN isn't a working group document at this time I
have higher hopes for websockets. But let's hope they both move
efficiently!

> such as Ruby-on-Rails.  

Like you, I'm not concerned about the client side as long as reasonable
commodity implementations exist. They will bundle what they need.

But my experience on the server side is different - TLS implementations
don't necessarily live with the application framework. They often live
in concentrator and offload devices.. even on the server WS is expected
to co-exist with HTTP but that certainly doesn't mean the admin is
willing to change the TLS implementation in the existing HTTP stack just
to add a gateway-to-ws shim. More coordination is involved. All of that
seems like a significant barrier.

Is the concept of defining both WS-over-NPN and WS-over-http-upgrade a
reasonable one, or is the mere presence of http-upgrade an unacceptable
security risk in the minds of the working group?

-Patrick

---

From: Simone Bordet <[email-masked]>
Date: Mon, 27 Sep 2010 23:50:00 +0200

Hi,

> use a newer version of OpenSSL than they might have otherwise.

Alas, I would like to share your optimism in the Java world where SSL
is implemented in the JDK.
It does not look like anyone in JDK land is even aware of NPN, and JDK
7 plans are still vague, so it may take quite a while for this to hit
Java (say 2012-2013 with JDK 8).

I share with others the opinion that we should work also on the
non-NPN handshake to hit a larger audience sooner.

Simon
-- 
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: Adam Barth <[email-masked]>
Date: Mon, 27 Sep 2010 16:01:12 -0700

> security risk in the minds of the working group?

Exposing WS-over-http-upgrade to web sites defeats the purpose of
using NPN because the attacker will just select the non-NPN version
for use in attacks.

Adam

---

From: Patrick McManus <[email-masked]>
Date: Mon, 27 Sep 2010 19:16:56 -0400

> using NPN because the attacker will just select the non-NPN version

I figured someone would say that :)

In that case is there, in your opinion, something in particular about
websockets as opposed to every other application level protocol which
makes this a problem that cannot be mitigated down to a similar level of
exposure using some variation of the handshake hashes as proposed?

I say that because if NPN simply represents a security step forward
rather than mitigation of particular WS deficiency I don't feel it is
necessary, expeditious, or reasonable to tie the burdens of NPN
deployment onto Websockets. If NPN were already deployed it would be
different.

---

From: Adam Barth <[email-masked]>
Date: Mon, 27 Sep 2010 16:56:39 -0700

> exposure using some variation of the handshake hashes as proposed?

We're not talking about exposing other network protocols to untrusted
content in the browser.  We expose HTTP to untrusted content, and
that's been a big enough security problem for the last decade.
Exposing another protocol requires great care.

Adam

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 28 Sep 2010 10:54:59 +0900

On 2010/09/28 8:01, Adam Barth wrote:
> On Mon, Sep 27, 2010 at 2:34 PM, Patrick McManus<[email-masked]>  wrote:

As it looks, deploying NPN on the browser side may be easier than on the 
server side. That would mean that the servers that want to be protected 
can deploy NPN (and not allow non-NPN), and those that don't care will 
stay with non-NPN. That may still leave clients less protected than 
desirable, though.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 27 Sep 2010 22:48:44 -0700

On Sep 27, 2010, at 6:54 PM, Martin J. Dürst wrote:

> As it looks, deploying NPN on the browser side may be easier than on the server side. That would mean that the servers that want to be protected can deploy NPN (and not allow non-NPN), and those that don't care will stay with non-NPN. That may still leave clients less protected than desirable, though.

In addition to the downside for clients you mention, this would create more risk for existing HTTP servers that have not been altered in any way to work with WebSocket. That's part of the set of servers we have to secure. Such servers do not get a choice of which handshake is used to attack them; the attacker will choose whichever is easier to use to do something nefarious.

Now, I think WebSocket-vs-HTTP attacks are handled reasonably well in the various proposed handshakes, more so than HTTP-vs-WebSocket; but it's still more risky to have two different handshakes, and the non-NPN proposals seem weaker than NPN.

Regards,
Maciej

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 28 Sep 2010 08:12:31 +0200

> Now, I think WebSocket-vs-HTTP attacks are handled reasonably well in the various proposed handshakes, more so than HTTP-vs-WebSocket; but it's still more risky to have two different handshakes, an…

Perhaps, but we must keep in mind that NPN and HTTP don't achieve the
same goals. The initial request was to have HTTP because it makes use
of the installed infrastructures. NPN can be nice but won't support
many of the already installed mechanisms such as virtual hosting nor
cookie-based persistence which are widely used.

We should keep in mind that if the client says "I want a car that
runs fast with little gazoline and that I can park everywhere", we
must not respond with "I can propose you this truck. It's slow, needs
massive amounts of gazoline, and you can't park it in underground
parkings in town, but it's solid steel, you won't get injured in any
accident". We should respond "I have this car, which has some downsides,
and I also have this truck in case you can afford both".

For this reason, I think we should really work on the HTTP handshake
first, relying as little as possible on HTTP and moving to the WS part
everything which would have to be reused for another type of handshake.
Then once we have HTTP working, let's check what we can do with NPN. It
sure will have its uses, but they're not always the same.

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 28 Sep 2010 16:25:28 +1000

> Now, I think WebSocket-vs-HTTP attacks are handled reasonably well in the various proposed handshakes, more so than HTTP-vs-WebSocket; but it's still more risky to have two different handshakes, an…

But this is not an issue about finding the MOST secure handshake.   We
need to find adequate security.

As you have previously pointed out, we are only as secure as our
weakest link.  Thus we need do no more than be as secure as existing
browsers.  If we do not enable any additional attack vectors that are
not already available via normal HTTP mechanisms within a browser,
then we will have sufficient security.

The concern with websockets, is that with such minimal framing around
application data, that sending raw websockets to some server may
result in a compromise.  Hence we want to have a handshake that gives
us a high level of confidence that we are talking ws to ws.

Having a lightweight TLS handshake without that same confidence may
simply result in websocket frames being used to attack other TLS
servers that know nothing about NPN.

---

From: Adam Barth <[email-masked]>
Date: Mon, 27 Sep 2010 23:39:18 -0700

> servers that know nothing about NPN.

NPN is designed to prevent precisely that attack.  The way TLS works,
both the client and the server negotiate which extensions they
understand.  For the handshake to complete, both client and server
must understand NPN.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 28 Sep 2010 17:25:44 +1000

> understand.  For the handshake to complete, both client and server

and the same can be said for the HTTP upgrade handshakes that have
been proposed.
Unless the handshake is successful, then clients will not be able to
send websocket packets to unsuspecting servers.

The handshake is sufficiently complex that there is no realistic risk
of an injectable server being tricked into generating the server side
of the handshake,   Even if such an injectable server existed, then
the attacker cannot know the nonce.

Unless you can highlight a flaw in this analysis, then simply
suggesting that it might be exploitable is about as valid as me
speculating that TLS/NPN might compromise non NPN servers.

---

From: Brian McKelvey <[email-masked]>
Date: Tue, 28 Sep 2010 17:56:34 -0700

+1 against FUD.

Brian

Sent from my iPhone