从Websocket客户端发送时是否真的需要屏蔽

当前的Websocket RFC要求Websocket 客户端在发送时屏蔽帧内的所有数据（但不需要服务器）。以此方式设计协议的原因是为了防止客户端和服务器之间的恶意服务（代理等）更改帧数据。但是，此类服务仍然知道屏蔽密钥（在每个帧的开头按帧发送）

我是否以为这样的服务仍然可以使用该密钥来取消遮罩，更改内容，然后在将帧传递到下一个点之前重新遮罩内容呢？如果我没看错，这将如何修复假定的漏洞？

security protocol websockets

— JSON格式
source

Answers:

RFC的10.3节明确说明了为什么需要屏蔽。这是对特定黑客技术的非常具体的响应。一些最精明的Internet传输安全人员在2010年的一篇名为“与自己交谈以获取乐趣和获利”中描述了它要解决的问题。

Websocket协议使用客户端到服务器的掩码来防止代理无意间将WebSockets数据视为可缓存的HTTP请求。您可以争辩说这是否愚蠢（我认为是）愚蠢的代理人，但这就是原因。

— 罗斯·帕特森
source

是的，但是在使用了完整的Websocket服务（客户端和服务器端）之后，我觉得我对该协议有了很好的了解，而且我不认为代理揭露和修改代理将面临什么挑战飞行中的帧。a）屏蔽密钥不是基于数据[例如哈希]，b）屏蔽密钥不可预测，因此中间人可以更改数据和密钥本身，c）（我相信）代理可以一旦创建/允许/隐藏有效的客户端会话，就可能会通过全新的，未经请求的帧[适当地屏蔽并全部屏蔽]，作为有效的客户端

— JSON

话虽如此，我也理解在做出此决定时，我可能不具备许多董事的知识和经验。

— JSON

听起来您没有读过该部分或它所引用的论文。屏蔽并不是要防止代理读取数据，而是要防止代理无意间将WebSockets数据视为可缓存的HTTP请求。您可以争辩说这是否愚蠢（我认为是）愚蠢的代理人，但这就是原因。

— 罗斯·帕特森

+1为解释。看起来它会提供更好的答案。如果您可以移动编辑原始答案，那就太好了。

— JSON

屏蔽wss://对SSL / TLS上的WebSocket 毫无用处。由于建议尽可能使用SSL / TLS，因此可以得出合理的结论，即掩盖覆盖了一个很小的用例。

— 洛朗·卡莱特
source

这确实应该是一个评论，但是您还没有足够的声誉....

— Adam Zuckerman