Subject: [hybi] Negotiating masking doesn't make sense (was Re: Straw-poll on Masking options)

From: Adam Barth <[email-masked]>
Date: Fri, 14 Jan 2011 13:59:11 -0800

Pat,

Having the client and the server negotiate masking doesn't really make
much sense.  The malicious server will just ask for whichever masking
it knows how to break.

Can you explain why you believe option #1 is sufficient for the job at
hand?  Specifically, how does it address the HTTP-to-WebSocket threat
model described by Maciej?

Adam

On Fri, Jan 14, 2011 at 9:50 AM, Pat McManus @Mozilla
<[email-masked]> wrote:
> On Wed, 2011-01-12 at 21:00 +0100, Salvatore Loreto wrote:
>> Joe and I, as HyBi chairs, want to check where the consensus is
>> on the following relevant options that have been discussed (and
>
>> 1. a fixed mask carried entirely in the packet.
>
>> 2. A longish repeated mask computed from the packet.
>
>> 3. A fully generated mask (if so specify also what you would like to use
>> e.g. AES-CTR or HMAC-SHA).
>
> My primary preference is for 1 which is sufficient to the job at hand -
> if we can have consensus that it is good enough I would be content with
> it. If that isn't enough, I can support #2 which is expensive but
> tolerably so.
>
> At this point #3 (AES) would be acceptable as a negotiated option with
> #1 or more likely #2 as a required fallback. That approach would give
> the camp that needs "at least #2" that level of randomness, while
> allowing implementations who wished to deal with the regulations around
> AES the capability of opting into something faster (assuming opted into
> by both ends). Intermediaries not willing to do AES would obviously have
> to participate in the negotiation, which all gets complicated.. so this
> is my least preferred, yet acceptable, route.
>
>
>
>
>
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Patrick McManus <[email-masked]>
Date: Fri, 14 Jan 2011 17:23:41 -0500

> much sense.  The malicious server will just ask for whichever masking

assuming you are negotiating between per message hmac and aes I don't
believe that one is meaningfully weaker the other. Are you concerned
about the server breaking one of those? The negotiation choice in that
case is between speed and regulatory encumberance.

> > #1 or more likely #2 as a required fallback.

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 14 Jan 2011 14:29:23 -0800

> case is between speed and regulatory encumberance.

If we define two masking schemes and require negotiation, then we have the following options:

1) Client required to support both; server can choose which to use.
2) Server required to support both; server can choose which to use.
3) At least one is mandatory for both clients and servers, and the other is only used when both endpoints opt in.
4) Interoperability fail.

I assume #4 is off the table. 1-3 also each seem problematic. In the case of 1 or 2, we're increasing complexity for one side of the transaction for the benefit of the other, and presumably not avoiding whatever the legal concerns are regarding AES. If the answer is 3, then there is little incentive to ever implement the optional masking scheme, since you still face all the security attack surface from the other, so it would be equivalent to choosing only one.

Regards,
Maciej

---

From: Patrick McManus <[email-masked]>
Date: Fri, 14 Jan 2011 17:46:02 -0500

> [..]
>  If the answer is 3, then there is little incentive to ever implement
> the optional masking scheme, since you still face all the security
> attack surface from the other, so it would be equivalent to choosing
> only one.

The idea is #3 with HMAC being mandatory and AES being optional with the
assumption being that HMAC security is sufficient and the incentive to
opt in to AES is better performance if you're comfortable with the
regulation it bundles.

These are security considerations, it is not a security encapsulation
protocol after all.

If you consider the HMAC approach both acceptable (which iirc you did
with a strong preference for AES) then this would be a path to widely
deploying AES while still keeping the standard implementable by folks
with regulatory concerns. It does nothing to address concerns some folks
have with including crypto complexity at all, of course.

But its all rather complicated if we could simply live with xor. (Sal's
#1). I'd appreciate it if you could again explain in detail if the
http-to-websockets attack depends on bugs in the websocket js client or
server implementation. Perhaps I misunderstood it the first time around,
its been a busy week. Thanks.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 16 Jan 2011 01:06:41 +0100

>its been a busy week. Thanks.

That is about using something like a form submission to interact with a
Websocket server, and raised essentially just because the poll option #1
"a fixed mask carried entirely in the packet" obviously does not include
something like the server nonce in the unmasking process, but option #2,
"A longish repeated mask computed from the packet", obviously does.

This is basically "Well, there are very few options to even think about
making such an attack work, for instance, you'd have to make the request
across origins." ~ "More!" "The handshake requires proof that the server
is a Websocket server, which in some proposals is based on reading a key
in the request and mixing that with something else; if done correctly
such an attack would fail." ~ "More!" "There are other properties of the
handshake that make this difficult, for instance, if a WEBSOCKET method
was required, that's easy to check for and necessary in many cases." ~
"More!"

"The Upgrade header?" ~ "More!" "So, the Websocket sever here does not
cooperate with the attacker, so it would not send a normal response just
after the 101 response; if the client does not properly recognize that,
it would wait for the next response before pipelining another request on
the connection, or it would read the response as being delimited by clo-
sing the connection and would thus not send another request either."
"More!" "If the server starts sending data without the client pushing
out another request, that should generally also trash the connection. ~
"More!"

"Well, even if you have cross-origin writes, you are not supposed to
have cross-origin reads without server consent, and there isn't much
reason for the Websocket server to employ any means to express consent,
so your level of interaction with the server would be very limited in
any case." ~ "More!"

"It's not exactly easy to fiddle the very few things you could hope to
control in the HTTP request just right into position so that you'd get
a spoofed mask on the wire and the right bits so the server would un-
mask anything resembling the protocol it understands." ~ "More!"

"There are also handshake proposals that identify where the code that
establishes the handshake is running on, and they are supposed to be
hard to spoof. A server that is somehow valuable to interact with and
not available to just about everyone would check for that at least." ~
"More!"

And so on.

So in any kind of reasonable setup there are any number of things that
can and should go wrong here on both sides of the connection -- and if
the Websocket server uses a fixed server nonce, or if the attacker can
read, or otherwise predict or brute force the server nonce, and that a
Websocket server uses an easily predictable PRNG wouldn't shock me at
all (just this week I found out that the version of Perl I've been
using for many years has only 15 bits of randomness in the default
generator), then all the proposals are equally vulnerable.

Throwing in yet another thing that maybe could help with some very hy-
pothetical scenario is something we could talk about, but the way in
which the people seemingly interested in this are presenting the issue
makes it hard to regard this as anything but theater.
-- 
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: Greg Wilkins <[email-masked]>
Date: Mon, 24 Jan 2011 11:13:34 +1100

> much sense.  The malicious server will just ask for whichever masking

and the well intentioned browser will reject any connections that
don't support masking extensions that the browser implementers believe
are secure.

If the browser implementers can maintain disciplines like not sending
secure cookies over HTTP connections, then surely you can exercise
enough self control to insist on masking extensions that you believe
are secure.   This smacks of the naive programmer arguments, which we
have dismissed.

---

From: Adam Barth <[email-masked]>
Date: Mon, 24 Jan 2011 15:26:36 -0800

> are secure.   This smacks of the naive programmer arguments, which we

IMHO, it would be shame for browsers to all agree to speak one variant
of the protocol and have other folks speak another variant.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 25 Jan 2011 12:10:39 +1100

> of the protocol and have other folks speak another variant.

Why?    One-size-fits-all approaches seldom work and you end up with
one-size-fits-nobody-perfectly.

Specifically in this case some want strong masking, but many will not
accept crypto masking unless it is agile.  So since there is an
insistence of non negotiation of masking, we've settled on a
compromise of XOR - which makes the advocates of strong masking
unhappy because it's too weak and makes the advocates of no-masking
unhappy because they think it is a waste of cycles.    But it is the
consensus because it addresses some of the concerns of both camps.

If you want strong masking, then you have to make some concessions to
those that are strongly opposed to it. If masking was a negotiated
extension, then there appears to be less objections to using stronger
masking, because it can be turned off or replaced with something else.
    We could have XOR masking as the default extension, but a standard
aes-mask extension defined that could be used by browsers. We could
also have no-mask extension that could be used in environments known
to be safe.    The servers have to implement everything (but then we
always do and I expect it will be a while before I can drop even -76
support).

Variation is natural and a good thing.  Obviously we don't want
rampant featurism in required extensions, but we can control the non
x- extensions and make sure they stay at a sane level.

Note that it makes sense for masking to not be used with wss
connections and for server->client, so we are already talking about
making masking optional.  Using the standardized extension mechanism
just regulates this optional behaviour into something sane and
manageable.

regards

---

From: Adam Barth <[email-masked]>
Date: Mon, 24 Jan 2011 17:17:09 -0800

> one-size-fits-nobody-perfectly.

Greg, I'm tired of discussing this topic with you.  You're not
listening.  Please see my earlier messages on this topic.

Adam

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 25 Jan 2011 12:36:10 +1100

On 25 January 2011 12:17, Adam Barth <[email-masked]> wrote:

> Greg, I'm tired of discussing this topic with you.

Nobody is compelling you to take part in this WG.   If you are tired,
I suggest a vacation.

> You're not  listening.  Please see my earlier messages on this topic.

Your messages on this topic have contained little more than one line sentiments:

 "... doesn't really make much sense."
 "it would be shame for ..."

The only justification you give for these sentiments is the
many-times-rebutted falsehood that malicious servers could dictate a
breakable masking extension.

I have asked you for more information about why you think variations
would be a shame, plus given my reasoning why I think some controlled
amount of variation is good.    But you have declined to give your
reasoning and have chosen instead to give another of your one line
dismissals, that I have seen several others complain about.

If you have nothing to say, then please say nothing.

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 24 Jan 2011 22:47:07 -0800

> consensus because it addresses some of the concerns of both camps.

If you're building a server that needs to talk to browsers, and browsers require strong masking, then the fact that weak masking or no masking is available doesn't save you any cycles. Conversely, having a weaker and a stronger approach gives you the effective security of the weakest link. That's particularly so in threat models where the attacker is not using a WebSocket client. In that case, the fact that browser-hosted WebSocket clients insist on stronger masking does nothing to help if servers do not insist on it. As I understand it, CPU usage concerns are in large part about decoding incoming traffic from the Web, not just datacenter-internal routing.

So as I see it, having both ways to do it, of which browsers always require one, defeats the goals of both camps.

Much as I would like to see a more effective masking alogorithm, I don't think switchability gives a net benefit over weak masking.

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 25 Jan 2011 18:19:06 +1100

On 25 January 2011 17:47, Maciej Stachowiak <[email-masked]> wrote:
>
> If you're building a server that needs to talk to browsers, and browsers require strong masking, then the fact that weak masking or no masking is available doesn't save you any cycles.

It does if you can offload the masking from your app servers to a
dedicated WS terminator/aggregator.

> Conversely, having a weaker and a stronger approach gives you the effective security of the weakest link.

Not at all.  Nobody says that SSL offloaders invalidate the security
of SSL because they have a weak link within the data centre. They do
increase the required security concerns of data centres, but obviously
not prohibitively so.     In the case of WS, the data centre security
is less of an issue because it is unlikely that a malicious attacker
will be able to physically install a vulnerable caching intermediary.

> As I understand it, CPU usage concerns are in large part about decoding incoming traffic from the Web,
> not just datacenter-internal routing.

Sure, there are multiple concerns about the CPU usage that masking
requires, both on app servers and on intermediaries. I think this
concern was central to the forming of the consensus around a simple
masking algorithm.

> Much as I would like to see a more effective masking algorithm, I don't think switchability gives a net benefit over
> weak masking.

So your preference is for mandatory weak masking over negotiated
strong masking.  Which is fine as that is what Sal has called as the
consensus and is probably what we will go forward with.

My preference is for mandatory weak masking over mandatory strong
masking, so I can live with the consensus as well.

I just think that if we could somehow mitigate your concerns about
negotiated masking, then there is a solution where all can be a little
be more satisfied than they are currently.   Again citing SSL as an
example, it has negotiated algorithms, offloaders and null ciphers,
yet this does not invalidate SSL security - so I don't see why we are
holding websockets to a higher standard.

regards

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 24 Jan 2011 23:49:18 -0800

> dedicated WS terminator/aggregator.

One exhaustively debated posited use case was for a WebSocket terminator that accepts outside traffic and reroutes it to private servers. So the cost of offloading this masking is precisely the concern of many.

> will be able to physically install a vulnerable caching intermediary.

That's not what I meant. If a protocol offers a choice of A or B, then it is generally vulnerable to attacks on either A or B.

> concern was central to the forming of the consensus around a simple

Willy's specific test case was meant to model a WebSocket multiplexing terminator that accepts lots of connections from the public Internet. I think you are wrong.

But if you can demonstrate consensus among those who expressed CPU concerns that they only care about CPU usage on private internal connections, I'm sure the chairs will take that into account.

> holding websockets to a higher standard.

I expect instead that many will be less satisfied (apparently excluding you). 

Regards,
Maciej

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 25 Jan 2011 19:07:07 +1100

> That's not what I meant. If a protocol offers a choice of A or B, then it is generally vulnerable to attacks on either A or B.

What I'm suggesting is that the protocol, as implemented for browsers
does not offer A or B, it only offers B - so if A is vulnerable to
attacks, this is not a concern for the browsers.

I understand that you are also concerned about non-WS clients being
tricked into talking to a server that supports option A or B and thus
being able to pick the most vulnerable. But if the a non-ws client can
send a fake WS handshake (which I don't think it can) and if it can
send a fake WS frame, then it can set the XOR mask to whatever it
likes and send whatever clear text it likes anyway.    Thus I don't
think you have substantiated your concerns about this attack vector in
regards to servers offering A or B to non-WS clients.

but whatever... the consensus is for mandatory XOR - I'll stop
advocating negotiated masking if others drop the advocacy for strong
masking (  or  support  negotiated masking and I'll put my hand up in
support of an AES mask extension ).

regards

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Jan 2011 08:20:03 +0000

On Tue Jan 25 08:07:07 2011, Greg Wilkins wrote:
> > That's not what I meant. If a protocol offers a choice of A or B,  
> then it is generally vulnerable to attacks on either A or B.
> 
That doesn't satisfy me at all. My concern is partly the wasted clock  
cycles, but also the quasi-legal implications of using cryptographic  
algorithms. (And yes, I do know it's not really cryptography, but the  
wording on the EU dual-use export control document, taken at face  
value, still seems to apply).

On top of that, there are some environments we deploy in where  
cryptographic usage is carefully controlled. I think we probably  
could get around these cases, mind, but it's friction I could happily  
do without.

Since I need to have my server interop with browsers, then if the  
browsers always negotiate a masking I may not be able to provide, I'm  
well and truly screwed.

It's bad enough living with masking - it's already a horrendous waste  
of CPU and bandwidth, IMHO, but making it negotiated won't change  
anything in practical cases, and it may actually make things worse.

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: Bruce Atherton <[email-masked]>
Date: Tue, 25 Jan 2011 11:11:01 -0800

On 25/01/2011 12:07 AM, Greg Wilkins wrote:
> On 25 January 2011 18:49, Maciej Stachowiak<[email-masked]>  wrote:

I agree with you, and that is how I voted in the straw poll. However at 
this stage I'm inclined to let that go.

So far there have been 4 uses that I've noticed for negotiated masking 
beyond the random XOR:

   1) gzip
   2) no masking
   3) AES-CTR
   4) future masking options

I've left off Base64 since it seemed like everyone who supported that 
was just as happy with XOR.

The first, gzip, will be dealt with as a separate option from masking. 
Option 2, no masking, will follow if the per-frame XOR mask is 0. I have 
nothing concrete to offer about why future masking options should be 
considered other than the general guideline that flexibility is a good 
thing if it doesn't come with too many costs or risks.

That leaves AES-CTR as the main use for negotiated masking. Two of the 
biggest boosters of that scheme, Adam and Maciej, have indicated here 
they would rather have XOR than the ability to negotiate AES-CTR. I 
don't understand their objections to negotiation of masking, but given 
how passionately they argued for AES-CTR then if they want to give that 
up in order to avoid negotiation, I'll give up on the flexibility of 
future masking choices.

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 25 Jan 2011 13:28:21 -0800

On Jan 25, 2011, at 11:11 AM, Bruce Atherton wrote:

> I agree with you, and that is how I voted in the straw poll. However at this stage I'm inclined to let that go.
> 
> So far there have been 4 uses that I've noticed for negotiated masking beyond the random XOR:
> 
>  1) gzip
>  2) no masking
>  3) AES-CTR
> I've left off Base64 since it seemed like everyone who supported that was just as happy with XOR.
> 
> The first, gzip, will be dealt with as a separate option from masking. Option 2, no masking, will follow if the per-frame XOR mask is 0. I have nothing concrete to offer about why future masking options should be considered other than the general guideline that flexibility is a good thing if it doesn't come with too many costs or risks.
> 
> That leaves AES-CTR as the main use for negotiated masking. Two of the biggest boosters of that scheme, Adam and Maciej, have indicated here they would rather have XOR than the ability to negotiate AES-CTR. I don't understand their objections to negotiation of masking, but given how passionately they argued for AES-CTR then if they want to give that up in order to avoid negotiation, I'll give up on the flexibility of future masking choices.

There's two ways in which the AES-CTR scheme can provide security benefits over the simple XOR mask (with the full mask in the frame):

(1) If all browsers consistently only use AES-CTR masking when sending with WebSocket, then there is less risk of endangering intermediaries.
(2) If all WebSocket servers only accept a masking (such as the proposed AES-CTR scheme) that requires a server nonce, then WebSocket servers are better defended against attacks using HTTP.

The negotiated proposal seems like it would mostly deliver on (1), if browser-hosted clients always require the stronger masking. It would not be quite as good as always having the stronger masking, since there is some extra fragility imposed by the negotiation. Also it forks the protocol between browser and non-browser use cases. It doesn't address (2) at all. It also seems like it imposes the CPU costs and legal considerations that were the main arguments presented against the AES-CTR scheme.

Regards,
Maciej

---

From: Bruce Atherton <[email-masked]>
Date: Tue, 25 Jan 2011 15:24:09 -0800

> The negotiated proposal seems like it would mostly deliver on (1), if browser-hosted clients always require the stronger masking. It would not be quite as good as always having the stronger masking…

Well, nothing says that servers can't choose to implement only AES-CTR 
masking and to refuse Websocket connections that are not so masked. Just 
as, had AES-CTR masking been chosen in the straw poll, nothing would 
have prevented servers from implementing alternate schemes with a 
protocol that look like Websockets minus the required masking, say a 
LightSockets specification.

As far as the legal and CPU costs, it is true those would remain so long 
as the browser vendors felt there was a security risk with simpler or no 
masking. However, over time it is possible that enough trust could be 
developed in XOR masking that they might be willing to relax the 
requirement for AES-CTR masking (perhaps as a configurable option), and 
with negotiated masking they could choose to do that if they wanted.

Basically, making it negotiable takes the decision out of the hands of 
the protocol specification designers and puts it into the hands of the 
browser vendors, at least as far as browser implementations is concerned.