Subject: [hybi] Major handshake design issues: encrypted traffic

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Oct 2010 07:28:13 -0700

Rather than continue to go back and forth, I'd like to try to break the
discussion down into
specific technical issues.

The proposal that Adam and I made has three main elements:

(1) All user-generated data is encrypted with a key not known to the user so
it
     presents on the wire as random bytes.

(2) The "routing" information in the handshake is encrypted.

(3) CONNECT is used as the method in the handshake.

I think I've listed these roughly in order of increasing controversy.

Most of the discussion has been on #3, but I'd like to try to get consensus
on the
others first, starting with #1.

The major concern that motivates #1 is that the attacker will somehow
arrange for
traffic which they control to break out of the WS "tunnel" and be delivered
to an
unsuspecting endpoint. Encrypting the traffic effectively randomizes this
data,
so even if the attacker breaks out of the tunnel, they dont get to deliver
controlled
traffic, which makes it extremely unlikely that they can generate traffic
that
will match any particular set of PDUs for other protocols. This technique
provides a higher level of security against this form of attack than any
other
technique of which I am aware.

The only concerns I have heard raised about this design is performance, but
as I think Adam Langley's Velocity talk makes clear, the performance cost
of bulk AES encryption is largely irrelevant in systems of this type. (FWIW,
this
is what all the performance analysis of SSL/TLS has shown all the way back
to 2000 or so). Are there any other concerns people have about this
approach?

-Ekr

---

From: "Alakkad, Achuth (GE Healthcare)" <[email-masked]>
Date: Tue, 12 Oct 2010 20:17:33 +0530

So does that mean I can't send a clear text through websockets if we go
with option 1 or 2.
If the message is small and is not critical, then there is no need of
this extra overhead.
Correct me if I am wrong.
 
regards
Achuth

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Rescorla
Sent: Tuesday, October 12, 2010 7:58 PM
To: Server-Initiated HTTP
Subject: [hybi] Major handshake design issues: encrypted traffic

(1) All user-generated data is encrypted with a key not known to the
user so it
presents on the wire as random bytes.

Most of the discussion has been on #3, but I'd like to try to get
consensus on the
others first, starting with #1.

The major concern that motivates #1 is that the attacker will somehow
arrange for
traffic which they control to break out of the WS "tunnel" and be
delivered to an
unsuspecting endpoint. Encrypting the traffic effectively randomizes
this data,
so even if the attacker breaks out of the tunnel, they dont get to
deliver controlled
traffic, which makes it extremely unlikely that they can generate
traffic that
will match any particular set of PDUs for other protocols. This
technique
provides a higher level of security against this form of attack than any
other
technique of which I am aware.

The only concerns I have heard raised about this design is performance,
but
as I think Adam Langley's Velocity talk makes clear, the performance
cost
of bulk AES encryption is largely irrelevant in systems of this type.
(FWIW, this
is what all the performance analysis of SSL/TLS has shown all the way
back
to 2000 or so). Are there any other concerns people have about this
approach?

-Ekr

---

From: John Tamplin <[email-masked]>
Date: Tue, 12 Oct 2010 10:47:40 -0400

> to 2000 or so). Are there any other concerns people have about this

The other concern about #3 that has been mentioned is regards to the
impact always doing such encryption has on existing filtering/logging
infrastructure.  An enterprise that can't use existing tools to
process WebSocket traffic is more likely to just block it rather than
blindly allow it.  Those with commercial tools will likely have to
wait a while and pay extra for the privilege of handling encrypted
WebSocket traffic.  I would also have some concerns over
implementation issues (is AES readily available on all relevant
platforms) and US export issues (I don't know the current status of
AES and export controls).

Other than that, I do like the basic idea -- you could also add a key
exchange step between the unencrypted part and the encrypted part,
using the negotiated key instead of a client-chosen key for the wss
scheme, and the rest of the protocol stays the same (though there is
risk here of basically reinventing TLS).

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Oct 2010 07:56:44 -0700

On Tue, Oct 12, 2010 at 7:47 AM, Alakkad, Achuth (GE Healthcare) <
[email-masked]> wrote:

> If the message is small and is not critical, then there is no need of this
> extra overhead.

(1) These aren't mutually exclusive options. #2 is an extension in some
sense of #1.
(2) The encryption isn't for confidentiality. An attacker who can observe
the traffic
      can decrypt it. It is purely in the interest of randomizing the data.
(3) Yes, you would not be able to send *any* cleartext, because allowing the
JS to do
      so would open an attack vector.

-Ekr

---

From: "Alakkad, Achuth (GE Healthcare)" <[email-masked]>
Date: Tue, 12 Oct 2010 20:37:19 +0530

So in that case what would be the difference between ws and wss ? There
won't be any right.
 
regards
Achuth

From: Eric Rescorla [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2010 8:27 PM
To: Alakkad, Achuth (GE Healthcare)
Cc: Server-Initiated HTTP
Subject: Re: [hybi] Major handshake design issues: encrypted traffic

On Tue, Oct 12, 2010 at 7:47 AM, Alakkad, Achuth (GE Healthcare)
<[email-masked]> wrote:

	So does that mean I can't send a clear text through websockets
if we go with option 1 or 2.
	If the message is small and is not critical, then there is no
need of this extra overhead.
	Correct me if I am wrong.

(1) These aren't mutually exclusive options. #2 is an extension in some
sense of #1.
(2) The encryption isn't for confidentiality. An attacker who can
observe the traffic
      can decrypt it. It is purely in the interest of randomizing the
data.
(3) Yes, you would not be able to send *any* cleartext, because allowing
the JS to do
      so would open an attack vector.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Oct 2010 08:08:20 -0700

wss will be over TLS (and maybe will use NPN). Again, this encryption is
purely for the purposes
of traffic randomization and offers no confidentiality.

-Ekr

On Tue, Oct 12, 2010 at 8:07 AM, Alakkad, Achuth (GE Healthcare) <
[email-masked]> wrote:

>  So in that case what would be the difference between *ws* and *wss *? There
> won't be any right.
>
> regards
> Achuth
>  ------------------------------
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Tuesday, October 12, 2010 8:27 PM
> *To:* Alakkad, Achuth (GE Healthcare)
> *Cc:* Server-Initiated HTTP
> *Subject:* Re: [hybi] Major handshake design issues: encrypted traffic
>
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 Oct 2010 20:22:10 +0200

> to 2000 or so). Are there any other concerns people have about this

Well, if the Host header is considered "user-generated data", then my
problems are not simply performance, but rather a means to extract it
from an HTTP-compliant intermediary for routing/filtering decisions
(which then falls back to #2).

Also, we're suggesting to encrypt all user-generated data so that the
user cannot control those data. Why not adopt what already exists and
works ? Plain HTTP already supports shared environments on a same IP
address, even multiple hosts on a same TCP connection, and there this
is not an issue. Most likely we're seeing a possible issue on WebSocket
because we did not take enough time to check how existing infrastructures
work and why they work, so we're blindly painting a lot of layers of
security on top of a possibly weak solution, hoping that the paint will
not crack.

I persist in thinking that the most compliant we will be to the protocol
we want to protect, the best protection we'll offer. Most of the new
tricks we'll invent in a small group will open vulnerabilities in some
environments that none of us has thought about.

Regards,
Willy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Oct 2010 11:36:08 -0700

On Tue, Oct 12, 2010 at 11:22 AM, Willy Tarreau <[email-masked]> wrote:

> consensus
> delivered
> deliver
> (FWIW,

I'm classing the host header as "routing information". It falls under #2.

> works ?

Because what already works *also* involves the same origin policy and
limited control by the JS over what the browser can generate. It's relaxing
those constraints that creates the vulnerability.

> Plain HTTP already supports shared environments on a same IP

On the contrary. The entire point of the encryption solution is to build a
system with assured security properties that does not depend to any
significant extent on how the existing infrastructure works.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 Oct 2010 20:44:25 +0200

> those constraints that creates the vulnerability.

I'm not speaking about relaxing anything, I'm speaking about using HTTP
how it already works everywhere.

> significant extent on how the existing infrastructure works.

Its security does not depend on that, but its working does. It's nice to
claim a solution to be secure, but it has to first work. Removing the
wheels on my car will surely save me from a car crash, but probably it's
not the solution I'm looking for.

Willy

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 12 Oct 2010 20:53:02 +0200

>security on top of a possibly weak solution, hoping that the paint will

If everyone on the line agrees that the Websocket protocol is and should
be spoken on the line then it pretty much does not matter what bytes are
exchanged in speaking the Websocket protocol. Combining those bytes with
a reasonably random value unknown to the attacker seeks to eliminate any
problems that may result from someone on the line being an unwilling or
unaware participant in a Websocket communication, in other words, if the
handshake is insufficient to ensure everyone speaks Websocket willingly.
Plain HTTP does not play into this as the protocol is no longer HTTP if
the handshake succeeds from the perspective of the client.
-- 
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: Eric Rescorla <[email-masked]>
Date: Tue, 12 Oct 2010 11:53:20 -0700

> how it already works everywhere.

Huh?

The way it already works everywhere is that when a browser downloads JS
from site A, that JS can't communicate with site B except under very limited
conditions. This is a security restriction enforced by the browser. WS is
designed to relax that restriction, which creates a whole bunch of security
risks.

> not the solution I'm looking for.
I have yet to see you present any meaningful argument that encrypting the
user provided payload presents a significant functional issue. Given that
the
major purpose of the exercise is to allow the browser to transmit arbitrary
data to the server once the tunnel is established, it's unclear what such a
functional issue would even look like.

As I said in the message that introduced this thread, I'm solely talking
here
about encrypting the data being sent after the tunnel is established
(including
whatever routing information such as host headers having already been
exchanged.) In what respect do you believe this will not work?

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 Oct 2010 21:13:26 +0200

> designed to relax that restriction, which creates a whole bunch of security

What I mean is that we're trying to address HTTP messaging semantics that
are not an issue when HTTP components are facing HTTP protocol and which
suddenly become one when they're facing WS protocol. So in short, let's
make the protocol closer to HTTP and use HTTP's messaging. If we all agree
that CONNECT+200 means that no new request can be sent after the 200, then
we don't have to worry about the risks of some client data being
misinterpreted as a second HTTP request forwarded to another host.

> functional issue would even look like.

I already provided an example here :

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

In short, if no HTTP-compatible routing information is sent along with
the handshake, existing HTTP infrastructures (load balancers, reverse
proxies, SSL accelerators, ...) will have to be replaced to support our
new WS protocol, which is contrary to the main principle of HTTP
compliance.

> exchanged.) In what respect do you believe this will not work?

Existing HTTP components already need that info in order to forward
the request to the proper server, proper customer, proper site, etc...

The 3 main info that are commonly needed are :

  - URI (though probably here we might be able to work without it)
  - Host header (determines the customer in a shared environment)
  - Cookies (determines the server within a farm)

Some infrastructures also make use of the User-Agent in order to direct
requests to the proper server farm when they have to deal with many
types of mobile phones which are handled by different products.

Willy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Oct 2010 12:19:02 -0700

> misinterpreted as a second HTTP request forwarded to another host.

I am not sufficiently confident that this is a universal invariant that I
don't think
masking (I'm going to use this term from now on to distinguish from real
encryption,
which isn't necessary here) is a good idea.

> types of mobile phones which are handled by different products.

Yes, I understand that this is your view, but that's not the question I'm
asking.

Let's say for the sake of argument that the URI, Host, and Cookies are all
transmitted in the clear and then *only* the data sent as WS (i.e., the WS
frames) are encrypted. What interoperability problem do you believe this
creates?

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 Oct 2010 21:34:11 +0200

> which isn't necessary here) is a good idea.

I respect your fears, but if we're so much afraid of having a user-controlled
data sent *after* the connect+200, then let's just send impossible HTTP data
after both messages (eg: 0x00 0xFF as I proposed, but something better might
be desired) and you're done with that issue.

Here we're talking about removing some commonly used headers from the request
just in case they would be misued by a server that needs them for all other
requests it processes. I still fail to see what that could bring except
issues.

> Yes, I understand that this is your view, but that's not the question I'm

But that's what I'm saying. You were asking if doing so could make it
unusable, I'm claiming so with a valid example.

> frames) are encrypted. What interoperability problem do you believe this

If that's like this (with URI, Host and Cookies at their proper locations,
i.e. inside the handshake, not after), then I'm perfectly fine with it ! All
HTTP components involved in the long chain will have the data they need to
route the request, that will be OK from my point of view, I see no remaining
issues as-is.

Thanks,
Willy

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 12 Oct 2010 13:27:47 -0700

> route the request, that will be OK from my point of view, I see no remaining

I think this is Eric's intent in breaking down the proposal into three components. Component #1 is solely about "payload" data, primarily the message stream but perhaps also some WebSocket-specific headers, and not routing information.

I suppose the line of what counts as routing information can be fuzzy, but URI and Host would definitely count as routing info, and I can also see the argument for Cookie. However, we should keep in mind that allowing Cookie is a wide open vector for an attacker to put content in the request. Cookies give no integrity guarantees and in practice are not limited to ASCII.

This is probably an issue for component #2 (encrypting routing info) however.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Tue, 12 Oct 2010 16:32:40 -0400

On Tue, Oct 12, 2010 at 4:27 PM, Maciej Stachowiak <[email-masked]> wrote:

> I suppose the line of what counts as routing information can be fuzzy, but
> URI and Host would definitely count as routing info, and I can also see the
> argument for Cookie. However, we should keep in mind that allowing Cookie is
> a wide open vector for an attacker to put content in the request. Cookies
> give no integrity guarantees and in practice are not limited to ASCII.
>

We could certainly impose additional constraints on cookies which are sent
in a WebSocket request -- any cookie which doesn't meet those constraints is
ignored.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Oct 2010 14:00:58 -0700

On Tue, Oct 12, 2010 at 1:27 PM, Maciej Stachowiak <[email-masked]> wrote:

> I think this is Eric's intent in breaking down the proposal into three
> components. Component #1 is solely about "payload" data, primarily the
> message stream but perhaps also some WebSocket-specific headers, and not
> routing information.
>

Yes. This is the breakdown I had in mind.

So, with that understanding, is there anyone who objects to masking of the
payload data, as in #3.

If not, perhaps we can declare that issue at least partly closed (with the
understanding that there is some
debate about whether encryption is required here or we can just XOR with a
random string).

Best,
-Ekr

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 12 Oct 2010 16:14:35 -0700

On Oct 12, 2010, at 1:32 PM, John Tamplin wrote:

> We could certainly impose additional constraints on cookies which are sent in a WebSocket request -- any cookie which doesn't meet those constraints is ignored.

Some thoughts:

- You'd need the restriction to be on sending, not receiving (I'm not sure which you meant by "is ignored").
- This may not be compatible with sites that use non-ASCII cookies currently - I'm not sure how common that is. Having to change the way you handle cookies to use WebSocket could be a deployment hurdle.
- This doesn't solve the underlying integrity problem, i.e. the fact that a third party rewrite your cookies at any time, even if they cannot read them. This is a fundamental problem with cookies, but somewhat worse in this case since it gives more parties the opportunity to inject possibly confusing content in the request.

Regards,
Maciej

---

From: John Tamplin <[email-masked]>
Date: Tue, 12 Oct 2010 19:18:27 -0400

> which you meant by "is ignored").

I meant that they wouldn't be sent to the server on a WebSockets
request.  Just like cookies marked as secure aren't sent on a
non-secure connection.

> - This may not be compatible with sites that use non-ASCII cookies currently

Those sites aren't using cookies for WebSockets, so it can't break
compatibility.  If they are using cookies with non-ASCII characters
and they want them to be sent on a WebSocket connection they would
have to change them.

> - I'm not sure how common that is. Having to change the way you handle
> cookies to use WebSocket could be a deployment hurdle.

Right now cookies aren't sent at all, which might also be a deployment hurdle.

> - This doesn't solve the underlying integrity problem, i.e. the fact that a
> third party rewrite your cookies at any time, even if they cannot read them.
> This is a fundamental problem with cookies, but somewhat worse in this case
> since it gives more parties the opportunity to inject possibly confusing
> content in the request.

If we assume an intermediary making arbitrary changes to the data sent
from the browser, I don't know how we can fix that -- they might
decide to send random bytes instead of what the browser sent.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 Oct 2010 05:36:17 +0200

> decide to send random bytes instead of what the browser sent.

I think that your proposal of restricting what cookies are sent based on
their ASCII-compliance fits the goal. Even if an intermediary rewrites
them with non-ascii data, that's not an issue because that data is not
decided by the browser. That said, I've never encountered components
making use of non-ascii cookies as routing information, this would be
very dangerous given the risk of getting them wrongly encoded by some
UAs.

Regards,
Willy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 14 Oct 2010 14:06:12 +0900

> to 2000 or so). Are there any other concerns people have about this

There's another important concern here that hasn't been mentioned, at 
least not in this thread. Using 'masking' means that debugging and 
education about the protocol will be much more difficult. This is highly 
relevant in general for IETF application protocols, but also in 
particular for WebSockets, because one of the ideas of WebSockets is 
that it should be easy for people with interesting ideas for new 
applications to write such applications. Also, while libraries will 
absorb the first layer of a WebSockets communication (framing,...), the 
data exchanged is defined by a 'subprotocol', which will need some good 
debugging facilities.

Of course if you can tell me that it's a piece of cake to add something 
to wireshark and tcpdump so that they show the packet contents in the 
clear, and you'll actually make sure the necessary implementation 
happens, then there's less of an issue.

Regards,   Martin.

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

---

From: John Tamplin <[email-masked]>
Date: Thu, 14 Oct 2010 01:45:43 -0400

On Thu, Oct 14, 2010 at 1:06 AM, "Martin J. Dürst"
<[email-masked]>wrote:

> Of course if you can tell me that it's a piece of cake to add something to
> wireshark and tcpdump so that they show the packet contents in the clear,
> and you'll actually make sure the necessary implementation happens, then
> there's less of an issue.
>

Having written a wireshark protocol dissector, I wouldn't say it would be a
piece of cake (mostly because all the facilities just point to positions
into the frame, and I am not aware of any sort of decryption support) -- but
it should be possible.

I don't know that I am in a position to committing to do that myself yet
though, but the first step to getting protocol dissectors written is to
actually define the protocol :).

---

From: Patrick McManus <[email-masked]>
Date: Thu, 14 Oct 2010 08:56:41 -0400

On Thu, 2010-10-14 at 14:06 +0900, "Martin J. Dürst" wrote:

> education about the protocol will be much more difficult. 

To me, that's a good argument for XOR instead of AES - building tooling
to unmask is easier and less dependent on the availability of libraries
etc.. while XOR still accomplishes the masking requirement.

Whether or not to mask at all is dependent on whether we think security
(cross protocol attacks in this case) requires it. If the answer is yes,
then "ease of use" cannot outweigh that. 

I've come to believe we should mask everything.

-Patrick

---

From: John Tamplin <[email-masked]>
Date: Thu, 14 Oct 2010 09:12:29 -0400

> etc.. while XOR still accomplishes the masking requirement.

+1

> I've come to believe we should mask everything.

Can you clarify what you mean by "everything"?  Clearly some parts must not
be masked, including the key used for masking and the HTTP-compatible
parts.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 14 Oct 2010 09:17:30 -0400

On Thu, 2010-10-14 at 09:12 -0400, John Tamplin wrote:
> On Thu, Oct 14, 2010 at 8:56 AM, Patrick McManus
> <[email-masked]> wrote:

> Can you clarify what you mean by "everything"?  Clearly some parts
> must not be masked, including the key used for masking and the
> HTTP-compatible parts. 

My language was sloppy, sorry. I just mean I agree that the full masking
tunnel as proposed is necessary.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Oct 2010 07:32:37 -0700

I don't know much about wireshark, but I've written passive protocol
analysis tools and this
isn't the hard part :)

-Ekr

On Wed, Oct 13, 2010 at 10:45 PM, John Tamplin <[email-masked]> wrote:

> On Thu, Oct 14, 2010 at 1:06 AM, "Martin J. Dürst" <[email-masked]
> > wrote:
>