Re: [hybi] Masking only Payload/Extension Data

[Greg Wilkins <[e-mail]>]

I'm +1 on the proposal.

2011/3/9 Ian Fette (イアンフェッティ) <[e-mail]>:
> Can someone please explain to me why this matters?


modified from the earlier thread on this:

Masked Frames PROS:
 + all bytes other than the key are masked.  This prevents an attacker
from using frame fields like the length to send "clear text"

Masked Frame CONS:
 - Masking is not independent of framing - poor layered protocol design.
ie this is the same reason that gzip in HTTP does not change the framing
of HTTP messages.
 - all WS handling that needs to be aware of frame boundaries will
need to implement masking.  This will mean that more infrastructure
will have masking hard coded into it, thus it will soon become very
difficult, if not impossible to change framing as it will be baked
into WS aware intermediaries.
 - Intermediaries that do not care about content will still need to
unmask and remask the frames.
 - the parser/generator code for WS becomes more complex and
asymmetric because it must implement masking for some WS streams but
not for others.
 - unmasking cannot be done as single optimised pass over the data,
but must be done on-the-fly in the parsing code.
 - the options for masking algorithms is limited.  For example session
based keys could not be used in a MUX environment as the session key
would need to be known to access the extension data to know the stream
ID, so the session ID could be known so you can't know the session
key.   While session based masking may not be desirable for other
reasons, this limitation indicates a fundamental limitation of the
masked frame approach.



Mask in Frame PROS:
 + Masking is independent of framing.   Good layered protocol design.
 + Intermediaries that do not process the payload will not need to
implement masking. This saves CPU, memory and also will make it easier
to change and/or remove masking in future.
 + WS parsing code is simple and symmetric.
 + session based masking algorithms can be used if desired
 + Can utilise the extension data space to carry the key - thus
testing the implementation of the parsing of extension data length and
preventing implementations assuming this will be zero.

Mask in Frame CONS:
 - The frame op-code, flags and length are sent in the clear.  Of
these, an attacker has reasonable control over the length field, so
could conceivably send 8 characters including "GET\n" as the length
(although this would be very difficult to do via the current
javascript API.  There are also simple heuristic defences for this,
such as fragmenting any frame that has a length that is all ascii and
has a CR)


In summary,   mask in frame is far more flexible, low cost and
demonstrable better design, at cost of exposing a very very unlikely
subcase of an already very very unlikely vulnerability to an as of yet
undiscovered threat, of which an exploitable variation is already in
the wild using non ws clients.