Re: [hybi] Masking only Payload/Extension Data

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

Can someone please explain to me why this matters? Given that we went with a
32-bit mask included in the frame, and it's just xor, I'm really not
sympathetic to arguments about "it's hard to unmask" etc. The only thing
that I've heard that resonates at all is that you have to know which
direction the connection is going, e.g. which is the client and which is the
server, that said it seems like any proxy doing anything interesting would
probably already know this?

-Ian

On Tue, Mar 8, 2011 at 11:29 PM, Brian <[e-mail]> wrote:

> In hope of getting consensus on the idea that only the payload and
> extension data should be masked and not the framing itself, I took a
> pass at adjusting sections 4.1 and 4.2 accordingly.  It didn't take
> much, just a few minor tweaks.
>
> What do you think?  Any chance we could reach a rough consensus on
> masking only the extension/payload data?
>
>
>
> 4.1.  Overview
>
>   In the WebSocket protocol, data is transmitted using a sequence of
>   frames.  The payload portion of frames sent from the client to the
>   server is always masked to avoid confusing network intermediaries,
>   such as intercepting proxies.  The payload portion of frames sent
>   from the server to the client are not masked.
>
>   The base framing protocol defines a frame type with an opcode, a
>   payload length, and designated locations for extension and
>   application data, which together define the _payload_ data.  Certain
>   bits and opcodes are reserved for future expansion of the protocol.
>   As such, In the absence of extensions negotiated during the opening
>   handshake (Section 5), all reserved bits MUST be 0 and reserved
>   opcode values MUST NOT be used.
>
>   A data frame MAY be transmitted by either the client or the server at
>   any time after handshake completion and before that endpoint has sent
>   a close message (Section 4.5.1).
>
> 4.2.  Client-to-Server Masking
>
>   The client MUST mask the payload of all frames sent to the server,
>   including all extension data.
>
>   The masking-key is contained completely within the payload.
>
>   The masking-key is a 32-bit value chosen at random by the client.
>   The masking-key MUST be derived from a strong source of entropy, and
>   the masking-key for a given frame MUST NOT make it simple for a
>   server to predict the masking-key for the payload in a subsequent
>   frame.
>
>   Each masked payload consists of a 32-bit masking-key followed by
>   masked-data:
>
>
>     masked-payload  = masking-key masked-data
>     masking-key     = 4full-octet
>     masked-data     = *full-octet
>     full-octet      = %x00-FF
>
>
>   The masked-data is the clear-text payload "encrypted" using a simple
>   XOR cipher as follows.
>
>
>   Octet i of the masked-data is the XOR of octet i of the clear text
>   frame with octet i modulo 4 of the masking-key:
>     j              = i MOD 4
>     masked-octet-i = clear-text-octet-i XOR octet-j-of-masking-key
>
>
>   When preparing a masked-payload, the client MUST pick a fresh masking-
>   key uniformly at random from the set of allowed 32-bit values.  The
>   unpredictability of the masking-nonce is essential to prevent the
>   author of malicious application data from selecting the bytes that
>   appear on the wire.
>
>
>
>
> Brian McKelvey
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>