Re: [hybi] RFC 6455 Client-Server Masking

Has the working group considered an FAQ?

This question (including some of the follow up) are very common.  The
answer hasn't changed and there is a record of the discussion leading
to the specified conclusion.

On 12 April 2013 11:30, Steven Atkinson <steven.atkinson@kaazing.com> wrote:
> To really boil this down to it's essentials, as far as I understand the
> masking,
> it's so that proxies cannot be confused or tricked into caching HTTP content
> when they are not supposed to.
>
> Consider using a WebSocket for sending HTTP request messages *within the
> envelope* of a WebSocket message.
> In this case, we would want to avoid proxies picking up the enveloped
> payload by mistake and caching it, otherwise an attacker
> could maliciously poison the cache of a proxy by sending HTTP content inside
> WebSocket messaging to purposefully control proxy behavior.
>
> The masking prevents/makes this harder because the payload will no longer
> look like HTTP and will be less likely to be misinterpreted by the proxy.
>
> One perhaps better alternative would have been to never mask, and mandate
> that WSS be the default, and that no plain-text WebSockets would be allowed.
> That way, we get "confusion" avoidance for intermediaries, but also get
> confidentiality and non-repudiation security properties.
>
>
> On Sun, Jan 27, 2013 at 5:26 PM, Brian McKelvey <theturtle32@gmail.com>
> wrote:
>>
>> The purpose of the masking has nothing to do with preventing eavesdropping
>> or interception.  It's meant to prevent malicious javascript running in a
>> web browser from connecting to arbitrary non-websocket services, or from
>> tricking http-unaware proxies into doing the attacker's bidding, caching
>> malicious data, etc.
>>
>> It's about preventing browsers from initiating attacks against
>> unsuspecting services, not about preventing eavesdropping or securing the
>> privacy of data in transit.  The use of TLS with WebSockets is required for
>> that.
>>
>> Brian
>>
>> Sent from my iPhone
>>
>> On Jan 27, 2013, at 3:58 PM, Denis McMahon
>> <denis.m.f.mcmahon@googlemail.com> wrote:
>>
>> > The unpredictability of the masking key is essential to prevent authors
>> > of malicious applications from selecting the bytes that appear on the
>> > wire.
>> >
>> > From this statement, I assume that the purpose of masking is "to prevent
>> > authors of malicious applications from selecting the bytes that appear
>> > on the wire."
>> >
>> > -= However =-
>> >
>> > The masking key is transmitted as part of the packet, and appears as 4
>> > bytes ABCD. This is like sending data inside a locked casket for
>> > security, WITH THE KEY SAFELY TIED TO THE CASKET!
>> >
>> > It follows from the protocol description that to detect any arbitrary
>> > sequence of n bytes in length, it is merely necessary to determine the
>> > four possible bit sequences that those bytes might represent, and
>> > monitor for all four of those bit sequences.
>> >
>> > The masking sequence for any N bytes of data will be one of four
>> > sequences, based on the mask bytes ABCD:
>> >
>> > 012345678.....n
>> > ABCDABCDA......
>> > BCDABCDAB......
>> > CDABCDABC......
>> > DABCDABCD......
>> >
>> > Given any sequence b1 ... bn which the attacker wishes to detect, the
>> > attacker simply has to combine, for each frame, b1 ... bn with each of
>> > the 4 possible sequences of n bytes in length of masking bytes, and
>> > listen for all 4 sequences. Computationally this is a trivial exercise!
>> >
>> > This mechanism does nothing to significantly increase the difficulty of
>> > a malicious application listening to the bytes on the wire with the
>> > intention of detecting specific patterns.
>> >
>> > It would be much better if the protocol dropped the masking concept,
>> > stated that it makes no attempt to protect data from eavesdropping or
>> > interception, and made the recommendation that if data security is
>> > desired, then appropriate transport layer security eg RFC 5246 TLS1.2 /
>> > RFC 6101 SSL3.0 should be employed.
>> >
>> > Denis McMahon
>> >
>> > _______________________________________________
>> > hybi mailing list
>> > hybi@ietf.org
>> > https://www.ietf.org/mailman/listinfo/hybi
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>
> --
> Sincerely,
> Steve Atkinson
> Software Engineer
>>|<  Kaazing Corporation, CA USA  >|<
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>