为什么 WebSocket 被屏蔽? [英] Why are WebSockets masked?

问题描述

我正在遵循 MDN 提供的关于编写 WebSocket 的指南服务器，该指南非常简单易懂...

然而，在学习本教程后，我遇到了来自客户端的 WebSocket 消息发送的框架:

<前><代码>0 1 2 30 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|操作码|M|有效载荷长度 |扩展的有效载荷长度 ||I|S|S|S|(4) |A|(7) |(16/64) ||N|V|V|V||S||(如果有效载荷 len==126/127) |||1|2|3||K|||+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +|扩展有效载荷长度继续，如果有效载荷 len == 127 |+ - - - - - - - - - - - - - - - +-------------------------------+||屏蔽键，如果 MASK 设置为 1 |+-------------------------------+-------------------------------+|屏蔽键(续) |有效载荷数据 |+-------------------------------- - - - - - - - - - - - - - - - +:有效载荷数据继续......:+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +|有效载荷数据继续... |+---------------------------------------------------------------+

在做了一些函数来正确地解除客户端发送的数据和帧的掩码后，让我想知道为什么数据甚至一开始就被掩码了.我的意思是，您不必屏蔽从服务器发送的数据...

如果有人出于不良原因获取数据，则可以相对容易地取消屏蔽，因为屏蔽密钥包含在整个消息中.或者即使他们没有密钥，帧中的掩码密钥也只有 2 个字节长.由于密钥非常非常小，因此有人可以轻松地揭开数据的掩码.

我想知道为什么数据被屏蔽的另一个原因是，通过在 TLS/SSL 和 HTTPS 上使用 WSS(WebSockets Secure)，您可以简单地比屏蔽更好地保护您的 WebSocket 数据.

我是否忽略了 WebSockets 被屏蔽的原因?似乎它只是在没有增加任何安全性的情况下增加了揭开客户端发送的数据的毫无意义的努力.

解决方案

jfriend00 的评论有很好的链接，可以找到很好的信息...

我确实想指出一些显而易见的事情，以表明屏蔽未加密的 websocket 连接是必要的要求，而不仅仅是有益的:

代理、路由器和其他中介(尤其是 ISP)经常读取客户端发送的请求并纠正"任何问题、添加标头以及优化"(例如从缓存响应)网络资源消耗.

>

某些标头和请求类型(例如 Connect)通常指向这些中介而不是端点服务器.

由于这些设备中的许多设备较旧且不了解 Websockets 协议，因此可能会编辑或处理看起来像 HTTP 请求的明文.

因此，有必要将明文转移"到无法识别的字节，以启动通过"而不是处理".

在此之后，它只是利用掩码来确保黑客不会反转"此掩码以发送恶意帧.

至于要求 wss 而不是掩码 - 我知道在编写标准时考虑过这一点......但是在证书免费之前，这将使任何需要 SSL/TLS 的网络标准成为富人"的标准，而不是互联网范围内的解决方案.

至于为什么要屏蔽 wss 数据?"- 我不确定这个，但我怀疑它是为了让解析器与连接无关并且更容易编写.在明文中，未屏蔽的帧是协议错误，会导致服务器启动断开连接.无论连接如何，解析器的行为都相同，这允许我们将解析器与原始 IO 层分离，使其与连接无关并为基于事件的编程提供支持.

I was following a guide provided by MDN on Writing a WebSocket server, the guide is pretty straightforward and easy to understand...

However upon following this tutorial I ran across the frame that WebSocket messages from the client are sent in:

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 ...                |
+---------------------------------------------------------------+

After making some functions to properly unmask the data and the frame that are sent by client, it made me wonder why the data is even masked to begin with. I mean, you don't have to mask data you're sending from the server...

If someone were getting the data for bad reasons, it could be relatively easy to unmask it because the masking key is included with the whole message. Or even provided they didn't have the key, the masking-key in the frame is only 2 bytes long. Someone could easily unmask the data since the key is very very small.

Another reason I'm wondering why the data is masked is because you can simply protect your WebSocket data better than the masking by using WSS (WebSockets Secure) on TLS/SSL, and over HTTPS.

Am I missing the point of why WebSockets are masked? Seems like it just adds pointless struggle to unmask the data sent by the client when it doesn't add any security to begin with.

解决方案

jfriend00's comment has great links to good information...

I do want to point out to the somewhat obvious, so as to show that masking unencrypted websocket connections is a necessary requirement, rather than just beneficial:

Proxies, routers and other intermediaries (esp. ISPs) often read the requests sent by the a client and "correct" any issues, add headers and otherwise "optimize" (such as respond from cache) network resource consumption.

Some headers and request types (such as Connect) are often directed at these intermediaries rather than the endpoint server.

Since many of these devices are older and unaware of the Websockets protocol, clear text that looks like an HTTP request might be edited or acted upon.

Hence, it was necessary that clear text would be "shifted" to unrecognized bytes, to initiate a "pass through" rather than "processing".

After this point, it was just about leveraging the masking to make sure hackers didn't "reverse" this masking to send malicious frames.

As for requiring wss instead of masking - I know this was considered during the writing of the standard... but until certificates are free, this would make any web standard requiring SSL/TLS a "rich man's" standard rather than an internet wide solution.

As for "why mask wss data?" - I'm not sure about this one, but I suspect that it is meant to allow the parser to be connection agnostic and easier to write. In clear text, unmasked frames are a protocol error and result in a disconnection initiated by the server. Having the parser behave the same, regardless of the connection, allows us to separate the parser from the raw IO layer, making it connection agnostic and offering support for event based programming.

这篇关于为什么 WebSocket 被屏蔽?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！