Subject: [hybi] Is masking required?

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Dec 2010 10:47:58 +0000

I'm going to make a series of statements which I believe to be  
uncontraversial. I'm then going to draw some conclusions from these,  
which seem to be contraversial.

First, the statements:

1) There exist transparent proxies, by which we mean an intermediary  
which the browser and server are both unaware of. (ie, this is  
network transparency and not mere semantic transparency).

2) Some of these transparent proxies can be fooled into rerouting  
requests and caching responses erroneously if the traffic appears to  
be HTTP. This allows an attacker to access data behind a firewall, or  
alternately poison the cache of a proxy.

3) There exists a paper describing an experiment conducted to test  
this hypothesis.

4) The paper also describes a CONNECT request, which causes some  
transparent proxies to cease to treat the remaining data flow as HTTP.

5) The results of this experiment showed that around 1 in every  
10,000 proxies was still trying to find HTTP requests in subseuqent  
data, although no security attacks (point (2)) were found against any  
of the 50,000 or so tested.

6) If masking were deployed, this is believed to prevent any  
transparent proxies from finding HTTP requests in the websocket data  
flow.

7) The attacks in (2) are mountable using Flash and Java.

8) Masking will prevent sendfile()-like interfaces, and in general  
cause dataflow within a device to be routed consistently through the  
CPU, increasing the hardware cost of websockets.

9) AES in particular will have export licensing considerations.

Second, some observations and conclusions:

a) We seem to have decided that we want websockets to be available  
even in environments that have decided to block Java or Flash (or,  
one assumes, other downloadable, non-sandboxed, code). This implies  
we need to be significantly more secure. I don't think this is  
particularly contraversial, but I would offer the suggestion that we  
are unlikely to be able to attain 100% security.

b) We know that a CONNECT request (or pseudo-CONNECT as in my  
proposal) will prevent attacks in some 99.99% of cases, with no cases  
actually found in field testing. This to my mind convinces me that a  
CONNECT is a useful approach. It can be made semantically transparent  
and conformant to existing HTTP specifications quite easily.

c) Whilst I entirely understand that masking prevents some  
theoretical problems, the only experimental data we have suggests  
that such problems are just that - theoretical. This is nothing like  
the kinds of issues we had with open mail relays, where every  
mailserver was, once, affected. This is a handful of transparent  
proxies which might be affected. I think a sense of proportion to our  
response seems sensible. The issues raised in (8) and (9) seem to  
suggest caution.

d) Finally, any proxy affected by the attacks in (2) is also affected  
by Flash or Java (see point 7), so the operators should become aware  
and fix or replace such intermediaries anyway.

My personal conclusion is that the practical benefits of masking  
remain theoretical, and simply do not outweigh the costs, which do  
exist.

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: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 21 Dec 2010 12:39:04 +0100

>CPU, increasing the hardware cost of websockets.

Masking is required primarily from client to server where the attacker
has meaningful control over the content. If you have, say, a video chat
protocol, data from the camera would probably not have to be masked
(instead of "user loads malicious page" the attack would be "user loads
malicious page, grants it permission to access the camera, and then he
somehow produces video input that the video encoder turns into some-
thing that looks like HTTP and that's then intercepted by some utterly
broken intermediary breaking it in a bad way" which is fascinating but
not much of a threat).

So if you are bent on optimizing, you'd mainly do this for things that
already go through the CPU on the client. And on the server, well, what
kind of fascinating things do you do there with the data that avoids
the CPU but cannot be adapted to also have one more decoding step, and
how common is something like that among all the Websocket servers? I
could imagine a file store for instance, where the server just writes
the data to disk, but for that kind of service you should use HTTP and
not Websocket. If you have some examples, please do share them.
-- 
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, 21 Dec 2010 08:04:37 -0800

On Tue, Dec 21, 2010 at 2:47 AM, Dave Cridland <[email-masked]> wrote:

> uncontraversial. I'm then going to draw some conclusions from these, which
> seem to be contraversial.
>
> First, the statements:
>
> 1) There exist transparent proxies, by which we mean an intermediary which
> the browser and server are both unaware of. (ie, this is network
> transparency and not mere semantic transparency).
>
> 2) Some of these transparent proxies can be fooled into rerouting requests
> and caching responses erroneously if the traffic appears to be HTTP. This
> allows an attacker to access data behind a firewall, or alternately poison
> the cache of a proxy.
>
> 3) There exists a paper describing an experiment conducted to test this
> hypothesis.
>
> 5) The results of this experiment showed that around 1 in every 10,000
> proxies was still trying to find HTTP requests in subseuqent data, although
> no security attacks (point (2)) were found against any of the 50,000 or so
> tested.
>
> 6) If masking were deployed, this is believed to prevent any transparent
> proxies from finding HTTP requests in the websocket data flow.
>
> 8) Masking will prevent sendfile()-like interfaces, and in general cause
> dataflow within a device to be routed consistently through the CPU,
> increasing the hardware cost of websockets.
>
>
No.

> 9) AES in particular will have export licensing considerations.
No.

-Ekr

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Dec 2010 17:04:00 +0000

> > increasing the hardware cost of websockets.
No as in you think this statement is incorrect? I don't see how  
masking can't increase the hardware cost, at least unless we end up  
in a situation whereby the masking is itself offloadable to hardware  
(which is obviously a cost in itself). It's very clear that masking  
would prevent a sendfile() interface from working.

> > 9) AES in particular will have export licensing considerations.

I see that your statement in another thread implies that because the  
keys are sent in the clear, then this will exempt us from export  
licensing considerations. I have to admit I don't relish trying to  
prove this one with the DTI in the UK.

But yes, it could be done, but it remains that we're protecting  
against a hypothetical problem that despite experimentation has not  
been seen in the field when CONNECT is used.

I do not argue that masking the data cryptographically will indeed  
prevent these hypothetical proxies from being used as an attack  
surface, but I do argue that experimentally, this has not been proven  
necessary. As such, I don't follow the justification for the cost of  
masking.

Now, my stance would be different if we thought that the attack  
surface was likely to increase, but it doesn't seem likely to me that  
existing transparent proxies will suddenly start to be susceptible to  
the attacks, and it seems more likely to me that proxies will become  
websocket-aware and therefore have no attacks of this nature.

So we are, with masking, optimizing for a failure case which --  
despite experimental testing -- has not been seen in the wild, and  
moreover the likelyhood of which is most likely to decrease.

Dave.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Dec 2010 09:22:07 -0800

On Tue, Dec 21, 2010 at 9:04 AM, Dave Cridland <[email-masked]> wrote:

>>  No as in you think this statement is incorrect?

Yes.

> I don't see how masking can't increase the hardware cost, at least unless
> we end up in a situation whereby the masking is itself offloadable to
> hardware (which is obviously a cost in itself). It's very clear that masking

Since masking is only required in the client->server direction and
websockets does not export a sendfile() style
interface, I don't see that that's an issue. As for the performance cost,
given that in most cases this data is
being processed through a JavaScript VM, I don't find this overly
concerning.

> I see that your statement in another thread implies that because the keys
> are sent in the clear, then this will exempt us from export licensing
> considerations. I have to admit I don't relish trying to prove this one with
> the DTI in the UK.
>
>
I don't see a problem v-a-v US export licensing, especially seeing as the
vast majority of the relevant implementations
will already have crypto.

> But yes, it could be done, but it remains that we're protecting against a
> hypothetical problem that despite experimentation has not been seen in the
> field when CONNECT is used.

Sure, and if you're willing to use the precise CONNECT handshake we tested,
I would be willing to settle for some
weaker masking, e.g., XOR with a fixed per-packet mask but no AES, though
it's less than optimal. But as long
as we are discussing the handshakes which our experiments have already shown
to be potentially weak, I
think stronger masking is merited.

-Ekr

Now, my stance would be different if we thought that the attack surface was
> likely to increase, but it doesn't seem likely to me that existing
> transparent proxies will suddenly start to be susceptible to the attacks,
> and it seems more likely to me that proxies will become websocket-aware and
> therefore have no attacks of this nature.
>
> So we are, with masking, optimizing for a failure case which -- despite
> experimental testing -- has not been seen in the wild, and moreover the
> likelyhood of which is most likely to decrease.
>
>

---

From: John Tamplin <[email-masked]>
Date: Tue, 21 Dec 2010 12:27:54 -0500

On Tue, Dec 21, 2010 at 12:04 PM, Dave Cridland <[email-masked]> wrote:

> No as in you think this statement is incorrect? I don't see how masking
> can't increase the hardware cost, at least unless we end up in a situation
> whereby the masking is itself offloadable to hardware (which is obviously a
> cost in itself). It's very clear that masking would prevent a sendfile()
> interface from working.
>

It has been suggested that masking is only needed in the client->server
direction.  We already assume the attacker has complete control over what
the server responds with anyway, so masking doesn't help there since they
could just choose the mask to get the text they want on the wire.

I do not argue that masking the data cryptographically will indeed prevent
> these hypothetical proxies from being used as an attack surface, but I do
> argue that experimentally, this has not been proven necessary. As such, I
> don't follow the justification for the cost of masking.
>

I think it is going to be hard for us to achieve consensus on something
weaker.  Also, padding LF/CR means you have to make a pass through the data
to count the length that is sent on the wire, and you have to inspect
everything a byte at a time to de-pad.  Base64-encoding everything means a
25% increase in size, so I would rather just pay a 4-byte fixed cost per
frame rather than that.

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

---

From: John Tamplin <[email-masked]>
Date: Tue, 21 Dec 2010 12:35:06 -0500

On Tue, Dec 21, 2010 at 12:22 PM, Eric Rescorla <[email-masked]> wrote:

> weaker masking, e.g., XOR with a fixed per-packet mas.  k but no AES,
> though it's less than optimal. But as long
> as we are discussing the handshakes which our experiments have already
> shown to be potentially weak, I

It isn't clear to me that AES-CTR is any stronger than XOR by itself a
proposed here.  Assuming a frame consists of [key maskedFrame], for the
attacker to get his chosen bytes on the wire in the maskedFrame, he must try
all possible values of key (assuming it really is unpredictable, if not he
can use the server to guess the next key in sequence and relay that
information to his client out-of-band).  Since for each given key, the
attacker can produce plaintext that encrypts to chosen bytes [by
pt=decrypt(K, chosenCipherText)], it seems that AES-CTR does not add any
extra protection in this case.

Maybe you could fix that by including another random value in the frame
before encyrpting which is simply ignored, but that seems equivalent to just
making the key longer.  So, I think the defense against this attack is
simply to have a large enough keyspace so that masking payload bytes with
each possible key is impractical.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Dec 2010 09:45:21 -0800

On Tue, Dec 21, 2010 at 9:35 AM, John Tamplin <[email-masked]> wrote:

>> Sure, and if you're willing to use the precise CONNECT handshake we
>> tested, I would be willing to settle for some
So I don't think this is *quite* true. The issue is that any sliding mask
allows an attacker to know about correlations between
the XOR value at byte i and byte i + masklen. I have no idea how to exploit
this, it's true, but it's not indistinguishable from
random, which is the weakest property I know to be sufficient (though there
probably are weaker ones I just can't prove).
-Ekr

---

From: John Tamplin <[email-masked]>
Date: Tue, 21 Dec 2010 12:49:03 -0500

> probably are weaker ones I just can't prove).

My point is that the attacker can already choose the payload byte at [i +
masklen] with AES-CTR, so it doesn't give him any advantage.  Conceivably,
an attacker might be able to avoid some of the duplication by taking
advantage of that correlation, but that just reduces the payload size
required not the keyspace.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Dec 2010 18:20:06 +0000

On Tue Dec 21 17:27:54 2010, John Tamplin wrote:
> masking
Right, but what I'm saying is that experimentally, it's been shown  
that a CONNECT request on the wire prevents a sufficiently large  
number of proxies from being susceptible to the attack that none were  
found in a sample size of 50,000.

> prevent
I'm not suggesting a weaker masking, I'm suggesting no masking at all.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Dec 2010 18:31:16 +0000

> being processed through a JavaScript VM, I don't find this overly
Then you're not disputing my statement, you're saying you think the  
increase is not significant in the browser case. I can certainly  
understand that viewpoint, although I'm not convinced by it - on the  
desktop it's a non-issue, for sure, but I'm not so sure it would be  
on mobile handsets and other similar systems.

> will already have crypto.
In our case -- with my Isode hat on, we would be implementing a  
websocket server for XMPP purposes -- we would certainly need to take  
legal advice, and probably invest significant time in discussing with  
government. I don't doubt that it's possible we might sail through  
without issues.

> against a

Right, we *certainly* need a CONNECT in the flow. I think we can get  
away with placing it after an Upgrade as I suggest, which eliminates  
it from being a "real" HTTP request per-se, and therefore makes it  
even simpler to inject rather bizarre pseudo-HTTP to confuse or  
paralyze misbehaving proxies further.

As for the GET+Upgrade request itself, it is a real request, and as  
such it does no harm to have the attacker control bytes on the wire.

Dave.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Dec 2010 10:35:50 -0800

On Tue, Dec 21, 2010 at 10:31 AM, Dave Cridland <[email-masked]> wrote:

>> cause
> increase is not significant in the browser case. I can certainly understand
> that viewpoint, although I'm not convinced by it - on the desktop it's a
> non-issue, for sure, but I'm not so sure it would be on mobile handsets and
> other similar systems

 No, I'm saying that sendfile() is irrelevant and that the data already goes
through the CPU, contra your original
statement.

>>  In our case -- with my Isode hat on, we would be implementing a websocket
> server for XMPP purposes -- we would certainly need to take legal advice,
> and probably invest significant time in discussing with government. I don't
> doubt that it's possible we might sail through without issues.
>
>
Your XMPP server doesn't do TLS?

-Ekr

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Dec 2010 20:15:46 +0000

> through the CPU, contra your original
No, my original statement was that masking would prevent sendfile()  
and force the data to go via the CPU. You're disputing whether that  
particular overhead is relevant on the basis that current  
implementations force the data through the CPU anyway, fine, but you  
cannot possibly argue that masking incurs no overhead at all.

> Your XMPP server doesn't do TLS?

Yes, of course it does, and we're required to license "high grade  
encryption" both in TLS and in other cases (SASL security layers,  
X.509 strong authentication, etc) on a case-by-case basis, as a  
result of the existing legislation covering cryptography exports.  
Whether or not you think we're required to do that is irrelevant, as  
our legal advice is that we are. I find it ridiculous given the  
cryptography involved is so easily available, but still.

For the specific case of whether this usage of AES would require the  
same treatment or not, I have no definitive answer, but I doubt it's  
trivial to find out. Given the nature of government departments, I  
have little faith it'll be a favourable outcome, anyway.

And I reiterate, experimental data shows that with a sample size of  
50,000, no vulnerable proxies were found -- these giants look  
suspiciously like windmills from this angle.

Dave.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 21 Dec 2010 22:29:25 +0100

>moreover the likelyhood of which is most likely to decrease.

With masking we would be trading some performance in exchange for a
protcol where it's easy to explain why it's robust; with your pro-
posal we would be trading some, presumably miniscule, amount of ro-
bustness and simplicity for better performance. So if someone said,
there is no evidence that the performance cost is something wo worry
about, and if someone else said, there is no evidence that the ro-
bustness and simplicity issues are something to worry about, then
there is no much to go on to decide which approach is better, short
of either one providing some evidence. Like I said, a couple of ex-
ample applications that illustrate the performance issues would help.
-- 
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/