Re: [hybi] Masking only Payload/Extension Data

[Ian Fette (イアンフェッティ) <[e-mail]>]

Ok, I really don't care so I will just go along here. That said, it doesn't
seem like the above will let you figure out if you're looking at a masked
frame or an unmasked frame. Does that matter?

-Ian

2011/3/9 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.
>