Is masking really necessary when sending from Websocket client

Question

The current Websocket RFC requires that websocket clients mask all data within frames when sending (but server is not required to). The reason the protocol was designed this way is to prevent frame data from being altered by malicious services between the client and server (proxies, etc). However, the masking key is still known to such services (it is sent on a per frame basis at the beginning of each frame)

Am I wrong to assume that such services can still use the key to unmask, alter, and than re-mask the contents before passing the frame to the next point? If I'm not wrong, how does this fix the supposed vulnerability?

Answer 1

Section 10.3 of the RFC explains exactly why masking is required. It's a very specific response to a specific hacking technique. The problem it is trying to address is described in a 2010 paper called Talking to Yourself for Fun and Profit by some of the sharpest Internet transport security folks.

Client-to-Server masking is used by the Websocket protocol to prevent proxies from unwittingly treating WebSockets data as a cacheable HTTP request. You can argue whether that's pandering to stupid proxies (and I think it is), but that's the reason.

• JSON: Yes, yet after working with a hand full of Websocket services (both client side and server side) I feel I have a good understanding of the protocol, and I don't see how it would be a challenge for a proxy to unmask and modify frames on the fly. a) The masking key isn't based on the data [such as a hash], b) the masking key is not predictable so a man the middle can change the data and the key itself, c) (I believe) a proxy can likely pass completely new, unsolicited frames [properly masked and all], as a valid client once a valid client session is created/allowed/sneaked through it
• JSON: With that said, I also understand that I likely don't have the knowledge and experience of many setting on their board when this decision was made.
• Ross Patterson: Sounds like you didn't read that section or the paper it references. The masking isn't to prevent proxies from reading the data, it's to prevent them from unwittingly treating WebSockets data as a cacheable HTTP request. You can argue whether that's pandering to stupid proxies (and I think it is), but that's the reason.
• JSON: +1 for the explanation. That looks like it would have made a better answer. If you can move edit your original answer it would be great.

Answer 2

Masking is useless with wss:// aka WebSockets over SSL/TLS. Since it is recommended to use SSL/TLS whenever possible, you can reasonable conclude that masking covers a marginal use case.

• Adam Zuckerman: This really should have been a comment, but you don't have sufficient reputation yet....
• Ross Patterson: I'd argue (and I did, above) that masking is useless, period. But you're absolutely right - the problem masking is designed to avoid is completely prevented when using an encrypted TLS connection across the proxy server.