10

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?

Improve this question

2 Answers 2

Reset to default
17

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.

Improve this answer
4
  • 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
    Feb 1, 2014 at 18:17
  • 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.
    – JSON
    Feb 1, 2014 at 18:38
  • 5
    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.
    – Ross Patterson
    Feb 1, 2014 at 23:51
  • 1
    +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.
    – JSON
    Feb 2, 2014 at 3:42
8

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.

Improve this answer
2
  • 1
    This really should have been a comment, but you don't have sufficient reputation yet....
    – Adam Zuckerman
    May 18, 2016 at 18:33
  • 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.
    – Ross Patterson
    Oct 20, 2021 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.