Re: [hybi] Masking only Payload/Extension Data

[Willy Tarreau <[e-mail]>]

On Wed, Mar 09, 2011 at 04:08:59PM -0500, Pat McManus @Mozilla wrote:
> On Thu, 2011-03-10 at 07:33 +1100, Greg Wilkins wrote:
> 
> > 
> > So I think masking is a perfect exemplar for the use of a reserve bit.
> 
> It is completely redundant information for any websocket implementation.
> 
> as for wireshark - it gives one more input into a pile of heuristics
> that it already has to use given the lack of a binding between
> websockets and tcp frames. Frankly, I don't see what is so hard about
> guessing whether or not masking is in play without the bit - especially
> with the asymmetric framing. 
> 
> And no matter what you do, anything that has thrown away the TCP state
> will be flat out guessing anyhow. The trivial case is a websocket
> payload which is also valid websocket frame with the payload arranged at
> the start of the TCP packet payload.

As someone playing all the day with network captures, I totally agree with
you on this point. There is no relation between individually captured
network packets and streamed contents if you don't have them from the
start. Some framed protocols such as HTTP which have massive amounts
of headers have their framings more easy to spot, but we managed to
make something very cheap network-wise with WS and I suspect that the
framing will be indiscernable from binary contents.

However, I agree with most of Greg's pros/cons, especially with the
one about the protocol design. Having a protocol whose upper layer
changes the lower layer framing is really hard to extend, and having
two versions of each decoding function in intermediaries is needlessly
expensive to maintain. I'd be much more happy with a protocol where
something in the framing or handshake indicates that the payload is
masked and where the frames are transported in native form.

I also like the analogy with HTTP BTW. It is possible (and common) to
chunk-encode the transfer of gzipped-encoded contents. When doing so,
the HTTP headers are clear-text, the transfer encoding is clear, and
the gzipped contents are inserted in chunks. Fortunately we don't
gzip the chunk size nor the header, nor do we chunk-encode the headers,
otherwise it would become a terrible mess.

So +1 from me for mask in the payload with an indication either in the
handshake or using a reserved bit, but for considerations of protocol
design and longterm extensivity, not just for basic asumptions about
what a sniffer could decode in randomly captured packets.

Regards,
Willy