Re: [hybi] Masking only Payload/Extension Data

[John Tamplin <[e-mail]>]

On Thu, Mar 10, 2011 at 10:36 AM, Andy Green <[e-mail]> wrote:

> It is much cleaner protocol-wise to have consistent framing and mask inside
> the extension area and allows server traffic masking to be selected the same
> way.
>

While I agree it is awkward to not be able to have a totally separate layer
where the masking is removed (since you can't know the length of the masked
frames without looking inside the masking), I don't think anyone is going to
implement it that way.  Instead, what will happen is that a flag will be
passed in saying to expect a mask, and it is just as easy to read that mask
before the opcode/length as it is afterwards (whether doing it with blocking
reads or a state machine for processing the next available bytes).  So, I
don't really see how it makes much difference from an implementation point
of view.

Once that's done, if 4-byte recirculating xor with per-frame random key
> isn't enough, and we have been told it is not "enough" before if you recall,
> then it'll be easy to upgrade the protocol to use AES masking or whatever
> without breaking the framing.


I don't see a difference here either -- if in the future a more
sophisticated masking is required, an extension would be negotiated that
will change it.  Browsers could choose to drop connections if the server
didn't accept this extension after some transition period, and then the new
masking algorithm would be applied to what was going on the wire.  If you
wanted to support both, it is easy enough for that boolean flag to become an
enum specifying the type of masking to be applied.

Regarding the negative impact of masking outside the framing, remember it is
only transparent intermediaries we are worried about (which includes packet
sniffers) since they can only observe the handshake but can't participate in
it.  Thus, if an extension is negotiated they don't understand, they can't
do anything with the stream.  I don't see there is much that can be done
about it -- for example, imagine the deflate-stream extension in -06 was not
part of the standard but a later extension.  No intermediary would even be
able to find frame boundaries if they didn't understand the extension.

As for using wireshark/etc to debug it, a simple heuristic like looking at
the port should get 95% of it right, and the user can always force
interpretation as WebSocket-client or WebSocket-server if they don't capture
the handshake.  Other intermediaries that must operate independently (such
as sniffers enforcing policy) are going to have to see the handshake to do
their job, and they have to already distinguish WebSocket traffic from
others in order to do their job, and in the process they will know which
side they are looking at.

So, my position is that I am unconvinced of the benefits of moving the mask
after the opcode/length, but I also think the additional risk exposed by
doing so is minimal, so I don't feel to strongly about it.

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