Subject: Re: [hybi] Mandatory vs Optional masking. was: Straw Poll: is Upgrade with client->sever XOR mask acceptable?

From: Jamie Lokier <[email-masked]>
Date: Sun, 2 Jan 2011 12:38:03 +0000

Bruce Atherton wrote:
> You are right, that is another cost to having the added security of 
> per-channel keys, beyond the few bytes. I see this as being the same as 
> removing the ability to provide a payload from the client in the initial 
> handshake when a connection is first created. Well worth the price for 
> the security provided.
> 
> To me, opening a communications channel should have the same level of 
> security whether it shares a socket or not.

It depends what you mean by a "channel".

Round-tripless setup means you can create and destroy channels so fast
that it's efficient to use unique channels for every HTTP-like
request/response pair (i.e. RPC) over the WebSocket.

It means there is no motivation for app designers to avoid using it
and roll their own.

Then the browser & server implementations are responsible for keeping
those channels semantically separate.  (Framing, etc.)

Arguably that would be *more* secure than the current plan, where we
expect sites to smoosh together independent WebSocket-using components
on the site into a single WebWorker-driven connection using
*application*-designed framing & muxing (overlaid), to the extent it's
technically feasible.  Possibly by replacing the browser's
window.WebSocket object site-wide with a Javascript version.
Precisely because of that round trip overhead (and other overheads).

Pushing framing & muxing towards application designers and
app-specific protocols is totally in keeping with the original
WebSocket philosophy, but it's not a great security recipe.

-- Jamie

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 2 Jan 2011 16:15:02 +0100

On 28 December 2010 05:25, John Tamplin <[email-masked]> wrote:
> We could certainly define one, but unless it goes into the base frame
> (I would object to that) or there is some flag to indicate that
> extension data is present and therefore the length is the first thing
> in the extension data, then I don't see how it helps.

John,

but the proposal to send the key and then mask the framing makes the
key part of the base framing.
It will be impossible to interpret the framing without handling
masking and effectively we have defined a new framing field before the
existing ones that  is the masking key.

So whatever reasons you have for objecting to a masking key in the
base framing, surely they apply to sending
key+masked-frame-header+masked-payload.

---

From: Bruce Atherton <[email-masked]>
Date: Sun, 02 Jan 2011 11:08:09 -0800

> request/response pair (i.e. RPC) over the WebSocket.

That describes Websocket messages. There is no need to introduce muxable 
channels in that scenario. I think we are talking about different things.

> Then the browser&  server implementations are responsible for keeping
> *application*-designed framing&  muxing (overlaid), to the extent it's
> Pushing framing&  muxing towards application designers and

It sounds to me like you are arguing against client-side muxing. Note 
that that is a different argument. Maciej was saying that there didn't 
seem to be a point to introducing some overhead to client-side muxing 
(assuming that it exists), and I was disagreeing that the overhead 
wasn't worthwhile.

I have to admit I really don't get what you are saying about why you 
wouldn't want the ability to separate channels. One can imagine a web 
page with a channel for a chat client for CRM and another for 
server-side form validation. If the CRM app is supplied by a third 
party, the server for it may well run in a sandboxed environment with 
the primary Websocket server distributing Websocket messages to it. You 
really don't want the chat app to be able to start mucking around with 
the form data. You may be able to protect against this in other ways, 
but why not allow the people deploying these apps to treat them as 
completely separate "virtual sockets" without all the socket overhead 
and without having to reinvent the wheel?

That's my perspective, anyway. But this thread was really about whether 
or not framing should be masked, and this portion focused specifically 
on whether there was an example of an appliance that didn't need to 
unmask and remask. I think it is clear that there well could be, but we 
seem to have strayed a long way from that topic.

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 2 Jan 2011 23:16:48 +0100

On 29 December 2010 00:31, Maciej Stachowiak <[email-masked]> wrote:
> Yes. In masking as currently proposed, the actual mask applied is based on a combination of the per-frame
> key and a per-connection key, derived from the server and client nonces.

I think that having a per-connection key has cons that greatly
outweigh any pros.

A per-frame key is sufficient to prevent clear text and a
per-connection key will make frames non-self describing. This will
make it more difficult to create tools such as wireshark plugins to
analyse ws streams.

I understand that the concern is that a pre-recorded frame might be
able to be used in an attack, but such an attack relies on the ability
to send arbitrary bytes, and we already know from Adam's/Erics
experiment that if you can send arbitrary bytes, you can attack
vulnerable intermediaries.

regards

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Jan 2011 14:20:12 -0800

> make it more difficult to create tools such as wireshark plugins to

I've built several passive analysis systems of this type and in my
experience this
just isn't correct.

You already need to maintain a fair amount of per-connection state to deal
with
the fact that the TCP segment boundaries don't line up with the frame
boundaries.
Maintaining a per-connection key is much easier.

-Ekr

---

From: Brian McKelvey <[email-masked]>
Date: Sun, 2 Jan 2011 14:49:40 -0800

It also means that you wouldn't be able to analyze the transmission at all if you started listening on the wire after the connection had already been established..  I'd be happy to live with that though.

Brian

Sent from my iPhone

On Jan 2, 2011, at 2:20 PM, Eric Rescorla <[email-masked]> wrote:

> I've built several passive analysis systems of this type and in my experience this 
> just isn't correct.
> 
> You already need to maintain a fair amount of per-connection state to deal with
> the fact that the TCP segment boundaries don't line up with the frame boundaries.
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: John Tamplin <[email-masked]>
Date: Sun, 2 Jan 2011 18:13:04 -0500

> key+masked-frame-header+masked-payload.

My objection is trying to renegotiate the existing framing mechanism,
rather than simply adding a layer above it where it remains the same
in both directions, with the only difference being adding an outer
layer on client->server.

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

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 3 Jan 2011 01:03:47 +0100

John,

Wrapping the existing framing in a new masking frame is renegotiating
the framing and that is why am strongly opposed to it.

We can avoid renegotiating the current framing by  putting the key
either in the already negotiated extension data or in the payload
itself.

regards

---

From: John Tamplin <[email-masked]>
Date: Sun, 2 Jan 2011 22:48:54 -0500

> the framing and that is why am strongly opposed to it.

I disagree -- is carrying the defined WebSocket frames inside an SSL session
redefining the WebSocket framing?  In the same way, adding an extra framing
outside of the existing WebSocket framing, which does nothing but add
masking, seems exactly analogous to SSL.

> either in the already negotiated extension data or in the payload

The problem is that the framing as specified now, says that the reserved
bits will be zero and the extension data area will be empty.  We could
certainly change that, but again that is going back into defining the
framing that we have already agreed upon at a significant cost.

I previously wrote up what I thought it would take to make the masking an
extension that would fit into what we already defined.  However, there is a
lot of things that we deferred that would have to be defined in order to do
that, and there were significant objections to making it optional.  I
suppose we could define all that and then define that all implementations,
barring connections that never transit outside a trusted network, must
request the extension and fail the connection if it isn't accepted.
 However, that seems to me to really be raising the minimum bar for simple
implementations, compared to just adding a masking layer around all of
WebSockets (not to mention it seems like it will be a lot harder to get
agreement on all those details).

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 3 Jan 2011 09:42:14 +0100

On 3 January 2011 04:48, John Tamplin <[email-masked]> wrote:

> I disagree -- is carrying the defined WebSocket frames inside an SSL session redefining the WebSocket
> framing?  In the same way, adding an extra framing outside of the existing WebSocket framing, which does > nothing but add masking, seems exactly analogous to SSL.

John,
It is one thing to propose wrapping WS framing in an existing standard
and an entirely different thing to propose a new masking mechanism to
wrap WS framing.

Besides, looking at SSL as an example, it has well defined framing
that is sent in the clear, so that intermediaries can analyse and
correctly handle SSL, without actually having to decrypt the payload.

> bits will be zero and the extension data area will be empty. ...
> that,

If the extension mechanism as defined can't cope with something as
simple as masking, then we have further work to do.  If we deferr
consideration of working extensions, then we will just end up with an
unusable extension mechanism.

But is there really a lot of things to change?  we could use a
reserved bit to indicate masking and that would stay within the
current draft.   Or we could change one section in the draft to allow
extensions to use extension data without using reserve bits (which I
think is sensible else we limit the number of extensions possible).

> and there were significant objections to making it optional.

This is not about making it optional, it is about making it agile so
that there is the option of making it optional and/or replaceable
either now or in the distant future.