关于 websocket 的 mask 字段 [英] about websocket's mask field

问题描述

关于 websocket 协议，你可以从这里阅读详细信息，http://tools.ietf.org/html/rfc6455#section-5.3

about websocket protocal ,you can read the detail from here,http://tools.ietf.org/html/rfc6455#section-5.3

在面具部分，它说:

掩码密钥是客户端随机选择的 32 位值.
准备蒙版帧时，客户端必须选择新的蒙版
来自允许的 32 位值集合的键.屏蔽键需要
不可预测；因此，屏蔽密钥必须来自强熵源和给定​​帧的掩码键不得
使服务器/代理可以轻松预测
的掩码密钥后续帧.掩码键的不可预测性是
防止恶意应用程序的作者选择出现在线路上的字节.RFC 4086 [RFC4086] 讨论了什么为安全敏感
需要一个合适的熵源应用程序.

The masking key is a 32-bit value chosen at random by the client.
When preparing a masked frame, the client MUST pick a fresh masking
key from the set of allowed 32-bit values. The masking key needs to
be unpredictable; thus, the masking key MUST be derived from a strong source of entropy, and the masking key for a given frame MUST NOT
make it simple for a server/proxy to predict the masking key for a
subsequent frame. The unpredictability of the masking key is
essential to prevent authors of malicious applications from selecting the bytes that appear on the wire. RFC 4086 [RFC4086] discusses what entails a suitable source of entropy for security-sensitive
applications.

我不明白为什么掩码密钥必须是不可预测的，更不用说这里真的需要掩码吗?因为你每次都发送它，嗅探器可以得到它并轻松解密它.这是我唯一能做的有用的东西认为它首先使人类无法读取播放数据，并且服务器需要更多时间来处理接收

i don't get why must the mask key be unpredictable ,not to mention is the mask really be necessary here?since you send it every time ,the sniffer can get it and easily decrypt it.the only useful thing i could think is it's made the playload data unreadable for human in the first place,and take more time for server to handle a receive

推荐答案

这与有效载荷数据的安全性无关，而是要让数据的发送方无法预测线路上出现的实际字节.

It's not about security for the payload data it's to make it impossible for the sender of the data to be able to predict the actual bytes that appear on the wire.

需要屏蔽从客户端到服务器的 WebSocket 流量，因为恶意代码不太可能导致某些损坏的代理执行错误操作并将其用作某种攻击.没有人证明这真的会发生，但由于它可能发生的事实足以让浏览器供应商感到不安，因此添加了掩码以消除其被用作攻击的可能性.

Masking of WebSocket traffic from client to server is required because of the unlikely chance that malicious code could cause some broken proxies to do the wrong thing and use this as an attack of some kind. Nobody has proved that this could actually happen, but since the fact that it could happen was reason enough for browser vendors to get twitchy, masking was added to remove the possibility of it being used as an attack.

这个想法是，由于生成 WebSocket 框架的 API 级别代码需要选择一个屏蔽键并屏蔽应用程序代码提供的数据，因此应用程序代码无法以任何有意义的方式指示最终通过潜在损坏的数据中间人，因此不会造成麻烦.由于屏蔽密钥在帧中，因此可以编写中介来理解和取消屏蔽数据，以便在需要时执行某种形式的巧妙检查.

The idea being that since the API level code generating the WebSocket frame gets to select a masking key and mask the data supplied by the application code the application code cannot in any meaningful way dictate the data that ends up passing through the potentially broken intermediaries and therefore can't cause trouble. Since the masking key is in the frame intermediaries can be written to understand and unmask the data to perform some form of clever inspection if they want to.

这也解释了从服务器到客户端没有屏蔽的原因……我在我的博客上写了更多关于这个的文章，此处.

This also explains the lack of masking from server to client... I wrote more about this on my blog, here.

这篇关于关于 websocket 的 mask 字段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！