What is a mask in a WebSocket frame?

I am working on a websocket implementation and I don’t know what the feeling of a mask in a frame is.

Can someone explain to me what he is doing and why he is recommending?

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+ 
+42
stream websocket tcp frame packet
Jan 05 '13 at 17:07
source share
2 answers

Web sites are defined in RFC6455, which states Section 5.3 :

The unpredictability of the masking key is necessary to prevent the selection of authors of malicious applications bytes that appear on the wire.

In the website entry, I found the following explanation:

masking-key (32 bits): if the mask bit is set (and, believe me, this is if you write for the server side), you can read here the unsigned bytes that are used for the xor payload. It was used to ensure that attackers could not abuse the attackers on the client side .

But I found the most obvious answer in the mailing list archive. There, John Tumplin states:

In principle, WebSockets is unique in that you need to protect the infrastructure network, even if you have hostile code running on the client, complete hostile server management, and the only part you can trust is the client browser. Due to the fact that the browser generates a random mask for each frame, the hostile client code cannot select byte patterns that appear on the wire and use this to attack a vulnerable network infrastructure .

As stated in the kmkaplan statement, the attack vector is described in Section 10.3 of the RFC.
This is a measure to prevent proxy cache poisoning attacks (see Attack Paper ). What he does creates some randomness. You must XOR the payload with a random masking key.

By the way: this is not just recommended. He is required .

+50
Jan 05 '13 at 17:30
source share

From in this article :

Masking WebSocket traffic from the client to the server is required because of the unlikely probability that malicious code can cause some broken proxies to do the wrong thing and use it as some kind of attack. No one proved that this could actually happen, but since the fact that this could have happened was sufficient reason for the browser developers to become twitching, a disguise was added to exclude the possibility of its use as an attack.

Thus, assuming that the attackers were able to compromise both the JavaScript code executed in the browser and the server server, masking is designed to prevent the sequence of bytes sent between these two endpoints, created in a special way that could violate any broken proxy servers between these two endpoints (broken, this means proxies that may try to interpret the websocket stream as HTTP when they really shouldn't).

The browser (and not the JavaScript code in the browser) has the last word on the randomly generated mask used to send the message, so attackers cannot understand what the final byte stream the proxy server can see.

Note that the mask is redundant if your WebSocket stream is encrypted (as it should be). Article from Python Flask author:

Why disguise at all? Because, apparently, there is a rather broken infrastructure that allows you to skip the update header and then processes the rest of the connection as a second HTTP request, which it then loads into the cache. I have no words for this. In any case, protection against this is basically a strong 32-bit random number as a masking key. Or you know ... use TLS and don't use shitty proxies.

+9
Aug 29 '15 at 20:22
source share



All Articles