Re: [hybi] RFC 6455 Client-Server Masking

[Steven Atkinson <[e-mail]>]

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 <[e-mail]>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 <
> [e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hybi
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>



-- 
Sincerely,
Steve Atkinson
Software Engineer
>|<  Kaazing Corporation, CA USA  >|<