为什么 WebSockets 被屏蔽了？
Why are WebSockets masked?
我遵循了 MDN 在 Writing a WebSocket server 上提供的指南，该指南非常简单易懂...
然而，在学习本教程后，我 运行 跨过发送来自客户端的 WebSocket 消息的框架：
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 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |<b>Masking-key, if MASK set to 1</b> |
+-------------------------------+-------------------------------+
| <b>Masking-key (continued)</b> | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
在做了一些函数来正确地取消屏蔽客户端发送的数据和帧之后，我想知道为什么数据一开始就被屏蔽了。我的意思是，您不必屏蔽从服务器发送的数据...
如果有人出于不良原因获取数据，则可以相对容易地取消屏蔽，因为屏蔽密钥包含在整个消息中。或者即使他们没有密钥，帧中的掩码密钥也只有 2 个字节长。由于密钥非常非常小，因此有人可以轻松地揭露数据。
我想知道为什么数据被屏蔽的另一个原因是，通过在 TLS/SSL 和 HTTPS 上使用 WSS（WebSockets 安全），您可以简单地比屏蔽更好地保护您的 WebSocket 数据。
我是否忽略了 WebSockets 被屏蔽的原因？似乎它只是增加了毫无意义的努力来揭露客户端发送的数据，而它一开始并没有增加任何安全性。
jfriend00 的评论有很好的信息链接...
我确实想指出一些显而易见的事情，以表明屏蔽未加密的 websocket 连接是必要的要求，而不仅仅是有益的：
代理、路由器和其他中介（尤其是 ISP）经常读取客户端发送的请求和 "correct" 任何问题，添加 headers 否则 "optimize"（例如从缓存响应）网络资源消耗。
一些 headers 和请求类型（例如 Connect）通常针对这些中介而不是端点服务器。
由于其中许多设备较旧且不了解 Websockets 协议，因此可能会编辑或执行看起来像 HTTP 请求的明文。
因此，明文必须 "shifted" 到无法识别的字节，才能启动 "pass through" 而不是 "processing"。
在这一点之后，就是利用掩码来确保黑客没有"reverse"这个掩码来发送恶意帧。
至于需要 wss 而不是屏蔽 - 我知道在编写标准时考虑到了这一点...但是在证书免费之前，这将使任何 Web 标准都需要 SSL/TLS "rich man's" 标准而不是互联网范围的解决方案。
至于 "why mask wss data?" - 我不确定这个，但我怀疑它是为了让解析器与连接无关并且更容易编写。在明文中，未屏蔽的帧是协议错误，会导致服务器发起断开连接。无论连接如何，让解析器的行为相同，允许我们将解析器与原始 IO 层分开，使其与连接无关，并为基于事件的编程提供支持。
实际上权威的 RFC RFC 6455 The WebSocket Protocol 有解释。我在这里引用它：
10.3. Attacks On Infrastructure (Masking)
In addition to endpoints being the target of attacks via WebSockets,
other parts of web infrastructure, such as proxies, may be the
subject of an attack.
As this protocol was being developed, an experiment was conducted to
demonstrate a class of attacks on proxies that led to the poisoning
of caching proxies deployed in the wild [TALKING]. The general form
of the attack was to establish a connection to a server under the
"attacker's" control, perform an UPGRADE on the HTTP connection
similar to what the WebSocket Protocol does to establish a
connection, and subsequently send data over that UPGRADEd connection
that looked like a GET request for a specific known resource (which
in an attack would likely be something like a widely deployed script
for tracking hits or a resource on an ad-serving network). The
remote server would respond with something that looked like a
response to the fake GET request, and this response would be cached
by a nonzero percentage of deployed intermediaries, thus poisoning
the cache. The net effect of this attack would be that if a user
could be convinced to visit a website the attacker controlled, the
attacker could potentially poison the cache for that user and other
users behind the same cache and run malicious script on other
origins, compromising the web security model.
To avoid such attacks on deployed intermediaries, it is not
sufficient to prefix application-supplied data with framing that is
not compliant with HTTP, as it is not possible to exhaustively
discover and test that each nonconformant intermediary does not skip
such non-HTTP framing and act incorrectly on the frame payload.
Thus, the defense adopted is to mask all data from the client to the
server, so that the remote script (attacker) does not have control
over how the data being sent appears on the wire and thus cannot
construct a message that could be misinterpreted by an intermediary
as an HTTP request.
Clients MUST choose a new masking key for each frame, using an
algorithm that cannot be predicted by end applications that provide
data. For example, each masking could be drawn from a
cryptographically strong random number generator. If the same key is
used or a decipherable pattern exists for how the next key is chosen,
the attacker can send a message that, when masked, could appear to be
an HTTP request (by taking the message the attacker wishes to see on
the wire and masking it with the next masking key to be used, the
masking key will effectively unmask the data when the client applies
it).
It is also necessary that once the transmission of a frame from a
client has begun, the payload (application-supplied data) of that
frame must not be capable of being modified by the application.
Otherwise, an attacker could send a long frame where the initial data
was a known value (such as all zeros), compute the masking key being
used upon receipt of the first part of the data, and then modify the
data that is yet to be sent in the frame to appear as an HTTP request
when masked. (This is essentially the same problem described in the
previous paragraph with using a known or predictable masking key.)
If additional data is to be sent or data to be sent is somehow
changed, that new or changed data must be sent in a new frame and
thus with a new masking key. In short, once transmission of a frame
begins, the contents must not be modifiable by the remote script
(application).
The threat model being protected against is one in which the client
sends data that appears to be an HTTP request. As such, the channel
that needs to be masked is the data from the client to the server.
The data from the server to the client can be made to look like a
response, but to accomplish this request, the client must also be
able to forge a request. As such, it was not deemed necessary to
mask data in both directions (the data from the server to the client
is not masked).
Despite the protection provided by masking, non-compliant HTTP
proxies will still be vulnerable to poisoning attacks of this type by
clients and servers that do not apply masking.
我遵循了 MDN 在 Writing a WebSocket server 上提供的指南，该指南非常简单易懂...
然而，在学习本教程后，我 运行 跨过发送来自客户端的 WebSocket 消息的框架：
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 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |<b>Masking-key, if MASK set to 1</b> |
+-------------------------------+-------------------------------+
| <b>Masking-key (continued)</b> | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
在做了一些函数来正确地取消屏蔽客户端发送的数据和帧之后，我想知道为什么数据一开始就被屏蔽了。我的意思是，您不必屏蔽从服务器发送的数据...
如果有人出于不良原因获取数据，则可以相对容易地取消屏蔽，因为屏蔽密钥包含在整个消息中。或者即使他们没有密钥，帧中的掩码密钥也只有 2 个字节长。由于密钥非常非常小，因此有人可以轻松地揭露数据。
我想知道为什么数据被屏蔽的另一个原因是，通过在 TLS/SSL 和 HTTPS 上使用 WSS（WebSockets 安全），您可以简单地比屏蔽更好地保护您的 WebSocket 数据。
我是否忽略了 WebSockets 被屏蔽的原因？似乎它只是增加了毫无意义的努力来揭露客户端发送的数据，而它一开始并没有增加任何安全性。
jfriend00 的评论有很好的信息链接...
我确实想指出一些显而易见的事情，以表明屏蔽未加密的 websocket 连接是必要的要求，而不仅仅是有益的：
代理、路由器和其他中介（尤其是 ISP）经常读取客户端发送的请求和 "correct" 任何问题，添加 headers 否则 "optimize"（例如从缓存响应）网络资源消耗。
一些 headers 和请求类型（例如 Connect）通常针对这些中介而不是端点服务器。
由于其中许多设备较旧且不了解 Websockets 协议，因此可能会编辑或执行看起来像 HTTP 请求的明文。
因此，明文必须 "shifted" 到无法识别的字节，才能启动 "pass through" 而不是 "processing"。
在这一点之后，就是利用掩码来确保黑客没有"reverse"这个掩码来发送恶意帧。
至于需要 wss 而不是屏蔽 - 我知道在编写标准时考虑到了这一点...但是在证书免费之前，这将使任何 Web 标准都需要 SSL/TLS "rich man's" 标准而不是互联网范围的解决方案。
至于 "why mask wss data?" - 我不确定这个，但我怀疑它是为了让解析器与连接无关并且更容易编写。在明文中，未屏蔽的帧是协议错误，会导致服务器发起断开连接。无论连接如何，让解析器的行为相同，允许我们将解析器与原始 IO 层分开，使其与连接无关，并为基于事件的编程提供支持。
实际上权威的 RFC RFC 6455 The WebSocket Protocol 有解释。我在这里引用它：
10.3. Attacks On Infrastructure (Masking)
In addition to endpoints being the target of attacks via WebSockets,
other parts of web infrastructure, such as proxies, may be the
subject of an attack.
As this protocol was being developed, an experiment was conducted to
demonstrate a class of attacks on proxies that led to the poisoning
of caching proxies deployed in the wild [TALKING]. The general form
of the attack was to establish a connection to a server under the
"attacker's" control, perform an UPGRADE on the HTTP connection
similar to what the WebSocket Protocol does to establish a
connection, and subsequently send data over that UPGRADEd connection
that looked like a GET request for a specific known resource (which
in an attack would likely be something like a widely deployed script
for tracking hits or a resource on an ad-serving network). The
remote server would respond with something that looked like a
response to the fake GET request, and this response would be cached
by a nonzero percentage of deployed intermediaries, thus poisoning
the cache. The net effect of this attack would be that if a user
could be convinced to visit a website the attacker controlled, the
attacker could potentially poison the cache for that user and other
users behind the same cache and run malicious script on other
origins, compromising the web security model.
To avoid such attacks on deployed intermediaries, it is not
sufficient to prefix application-supplied data with framing that is
not compliant with HTTP, as it is not possible to exhaustively
discover and test that each nonconformant intermediary does not skip
such non-HTTP framing and act incorrectly on the frame payload.
Thus, the defense adopted is to mask all data from the client to the
server, so that the remote script (attacker) does not have control
over how the data being sent appears on the wire and thus cannot
construct a message that could be misinterpreted by an intermediary
as an HTTP request.
Clients MUST choose a new masking key for each frame, using an
algorithm that cannot be predicted by end applications that provide
data. For example, each masking could be drawn from a
cryptographically strong random number generator. If the same key is
used or a decipherable pattern exists for how the next key is chosen,
the attacker can send a message that, when masked, could appear to be
an HTTP request (by taking the message the attacker wishes to see on
the wire and masking it with the next masking key to be used, the
masking key will effectively unmask the data when the client applies
it).
It is also necessary that once the transmission of a frame from a
client has begun, the payload (application-supplied data) of that
frame must not be capable of being modified by the application.
Otherwise, an attacker could send a long frame where the initial data
was a known value (such as all zeros), compute the masking key being
used upon receipt of the first part of the data, and then modify the
data that is yet to be sent in the frame to appear as an HTTP request
when masked. (This is essentially the same problem described in the
previous paragraph with using a known or predictable masking key.)
If additional data is to be sent or data to be sent is somehow
changed, that new or changed data must be sent in a new frame and
thus with a new masking key. In short, once transmission of a frame
begins, the contents must not be modifiable by the remote script
(application).
The threat model being protected against is one in which the client
sends data that appears to be an HTTP request. As such, the channel
that needs to be masked is the data from the client to the server.
The data from the server to the client can be made to look like a
response, but to accomplish this request, the client must also be
able to forge a request. As such, it was not deemed necessary to
mask data in both directions (the data from the server to the client
is not masked).
Despite the protection provided by masking, non-compliant HTTP
proxies will still be vulnerable to poisoning attacks of this type by
clients and servers that do not apply masking.