Subject: Re: [hybi] Why not just use ssh?

From: "Shelby Moore" <[email-masked]>
Date: Tue, 31 Aug 2010 16:41:01 -0400

>> I think we need to deliver on HTTP Upgrade.
>
> TLS works over any port.  The point of using TLS alone is to block
> cross-protocol attacks.  If we provide both TLS and non-TLS options,
> the attackers will choose the non-TLS option for their attackers
> whereas the folks who actually want to connect to the server more than
> 60-some percent of the time will use the TLS option.  Offering both is
> a lose-lose.

Nothwithstanding that I think cross-protocol attacks are the fault of the
target protocol, do not forget that browsers can allow users to turn off
or opt in to certain features.

I am reminded of my "don't go chasing shadows" post about security:

http://www.ietf.org/mail-archive/web/http-state/current/msg00939.html

Blaming security holes on the messenger instead of on the actual hole
(injection point), or not hardening behind the firewall is analogous to
hardening a castle more by making the walls ever higher and the doors ever
smaller or more difficult to open.

The end result is starvation.

The most security is to break yourself into million parts and distribute
yourself.

So moving the security farther from the center is the answer.

We don't want to lock ourselves inside with the security holes, we expose
the holes so we can be outside and prosper, and so the holes will get
identified and fixed.

It goes back to "more eyeballs = shallower bugs" (Cathedral and Bazaar
model). It is all about maximizing the # of mutations per evolutionary
generation. Wasn't there a math book that said "thou shall go forth and
multiply"?

Conflation (blaming something for something else, or trying to
implementation one thing by implementing multiple things) is worse than
wasteful, it is actually classified as evil in some ancient math books
(Parable of the Talents).

Motto: one post per day, make it count (love you Willy for teaching me).

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Aug 2010 13:55:35 -0700

> or opt in to certain features.

I don't see the relevance of this.

The extant protocols have whatever set of security properties they have.
The browser security model is designed to prevent Web sites from exploiting
them. I don't consider (and as far as I can tell, pretty much nobody else
considers)
shipping a solution that threatens the security of those protocols to be an
option.

As for turning features on or off, I have no idea what you propose there. If
some
feature needs to be turned on to make legitimate sites work, then users will
turn
it on for every site. If it's made too difficult to turn on then sites won't
be able to
count on it and it will go unused. Extensive HCI research indicates that
users
simply can't discriminate effectively in these matters.

Adam: I'm not entirely clear on your point. I agree that if the HTTP version
is more
vulnerable to cross-protocol attacks than attackers will exploit it, but if
the
HTTP and HTTPS versions are equally vulnerable, why would attackers
favor HTTP? What am I missing.
-Ekr

---

From: Adam Barth <[email-masked]>
Date: Tue, 31 Aug 2010 14:18:58 -0700

On Tue, Aug 31, 2010 at 1:55 PM, Eric Rescorla <[email-masked]> wrote:
> is more vulnerable to cross-protocol attacks than attackers will exploit it,
> but if the HTTP and HTTPS versions are equally vulnerable, why would
> attackers favor HTTP? What am I missing.

I'm fairly convinced that the TLS version is free of cross-protocol
vulnerabilities.  However, the same cannot be said for the non-TLS
version.  The security argument for the non-TLS version is pretty
dodgy, IMHO.  So, I don't think the two are equally vulnerable.

Adam

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 1 Sep 2010 00:16:16 +0000

> > Adam: I'm not entirely clear on your point. I agree that if the HTTP
> > version is more vulnerable to cross-protocol attacks than attackers
> > will exploit it, but if the HTTP and HTTPS versions are equally
> > vulnerable, why would attackers favor HTTP? What am I missing.
> 
> I'm fairly convinced that the TLS version is free of cross-protocol vulnerabilities.
> However, the same cannot be said for the non-TLS version.  The security
> argument for the non-TLS version is pretty dodgy, IMHO.  So, I don't think the
> two are equally vulnerable.

I think there's two meanings of "offering both TLS and non-TLS versions".  
1. allow the protocol to use either HTTP or HTTPS (+Upgrade) variants of WebSockets (i.e., either ws: or wss: URLs).
2. *deploy* a given service over both HTTP and HTTPS (+Upgrade) variants of WebSockets (a given service over both ws: and wss:)

One does not imply the other (as we see with many web services today). If your policy does not allow the plain HTTP ws: variant, then the server will not reply with a 101 to the Upgrade request from the client. 

I might have missed that part of the discussion, but, if the server is replying to an Upgrade (perhaps over HTTPS) with a 101, and with a random nonce sent by the client, how is this vulnerable to a cross-protocol attack? 

The NPN mechanism is not a slam-dunk in the TLS working group, judging from the exchanges there, but still you suggest that NPN be the *only* mechanism allowed for Websockets. I'm fine with it being investigated for later use (in line with Alexey and Salvatore's messages to the list, and in line with the created ticket). But I think it would be a bad idea to impose NPN as the one and only available mechanism as you claim. Even within NPN usage you're not free of applying policy, as there is the potential for multiple certs being used for a given WS service, and whenever you have such options there is the possibility of a bidding-down attack (not very different from what is possible #2 above is true). 

Is the argument that NPN saves on round-trips? That is very important, particularly for certain applications, like search, but does the data shown, say, at the Velocity conference apply equally to long-lived sessions (such as a web chat)?

---

From: Adam Barth <[email-masked]>
Date: Tue, 31 Aug 2010 17:26:25 -0700

> One does not imply the other (as we see with many web services today). If your policy does not allow the plain HTTP ws: variant, then the server will not reply with a 101 to the Upgrade request fro…

Right.  We're talking about what APIs a browser exposes to arbitrary
web content.  I don't want to expose the non-TLS version as an API
inside a web browser because I'm not convinced it can't be used by
attacker.com to mount a cross-protocol attack.

> I might have missed that part of the discussion, but, if the server is replying to an Upgrade (perhaps over HTTPS) with a 101, and with a random nonce sent by the client, how is this vulnerable to…

Cross-protocol attacks are quite subtle and generally take years to
uncover.  Your statement is roughly equivalent to "protocol XYZ uses
encryption, it might be secure against man-in-the-middle attacks,
right?"

> The NPN mechanism is not a slam-dunk in the TLS working group, judging from the exchanges there, but still you suggest that NPN be the *only* mechanism allowed for Websockets.

That's correct.

> I'm fine with it being investigated for later use (in line with Alexey and Salvatore's messages to the list, and in line with the created ticket). But I think it would be a bad idea to impose NPN as the one and only available mechanism as you claim.

Why?  There are a number of compelling technical reasons to prefer the
TLS-based handshake.  The counter arguments appear to be entirely
non-technical.

> Even within NPN usage you're not free of applying policy, as there is the potential for multiple certs being used for a given WS service, and whenever you have such options there is the possibility of a bidding-down attack (not very different from what is possible #2 above is true).

I didn't follow.  If you mean that we'd still want to distinguish
between ws and wss, then yes, that's correct.  However, that's an
issue of how much protection we want from active network attackers.
The motivation for using TLS here as nothing to do with active network
attackers and everything to do with cross-protocol attacks.

> Is the argument that NPN saves on round-trips?

No.  Please read my and Eric's earlier messages for the reasons the
TLS-based handshake is technically superior to the non-TLS version.

Adam

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 31 Aug 2010 17:39:40 -0700

On Tue, Aug 31, 2010 at 5:16 PM, Gabriel Montenegro <[email-masked]>wrote:

> The NPN mechanism is not a slam-dunk in the TLS working group, judging from
> the exchanges there,
>

Responding just to this point...

I think that's a fair assessment of the state of the TLS discussion.

To expand on it a little bit, there are three barriers to NPN proceeding in
TLS:

(1) Concerns about the architectural choices embodied in it.
(2) Concerns about the precise technical details.
(3) A general lack of momentum.

My impression is that (2) isn't that big a deal, i.e., that the authors are
flexible about
the details. (3) is an issue (like any piece of work) but OTOH this WG
deciding that
they really needed something NPNish and asking TLS to do it would have a big
impact
on momentum, I think. That leaves the architectural issues. I think we'd
need
more discussion in TLS-WG before we have a clear answer to that.

-Ekr

---

From: John Tamplin <[email-masked]>
Date: Tue, 31 Aug 2010 20:40:45 -0400

> TLS-based handshake.  The counter arguments appear to be entirely

I don't know -- does changing the typical total frame header size
after RoHC from 7 bytes to 22 count as a technical argument?  With a
large number of frames likely being a few dozen bytes after
compression, that seems significant.  The requirement for any
implementation to include TLS libraries also seems to be a technical
argument.

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

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Sep 2010 07:49:06 +0200

> implementation to include TLS libraries also seems to be a technical

I'd like to add that the WG's goal is to achieve interoperability, and
that's not only based on technical arguments. With TLS, an administrator
can't analyze traffic. That's very important in schools for example, and
some large enterprises, where the policy is simple : either you can
analyze and filter, or you block. While I'm very favorable to a TLS
version, I'd really like to have an HTTP one too. For this reason, I
think we should ensure the handshake is simple enough to limit misuses,
and looks a lot like HTTP so that it does not create a new attack
vector. After all, the WS clients will be the browsers. They already
have access to the net (direct or via proxies), and what we should be
concerned about is that we can't do with WS what we can't already do
with HTTP.

So in my opinion, trying to stop protocol attacks before the handshake
is complete is a waste of time since the HTTP vector is still available,
however we have to ensure we won't complete the handshake on a non-WS
server. For that use, I think that the nonce, whatever its form (possibly
a WS ping+pong) is very important.

Willy

---

From: Adam Barth <[email-masked]>
Date: Tue, 31 Aug 2010 22:53:31 -0700

> a WS ping+pong) is very important.

We're just going in circles.  You've made all these points before.

Adam