1

我正在使用 websockets 做一些工作，需要解决安全问题。从我所读到的内容来看，显然 SSL 在我的情况下是最好的方法，所以 WSS 是要走的路（这不是问题，只是事实陈述）。

服务器可能会将大量数据流式传输到客户端。这些数据不是私人的或敏感的，所以我不担心有人会嗅到这些数据。我主要担心的是 WS 连接已被验证，因为在服务器上接收命令可能是有害和破坏性的。客户必须是可信的。

服务器将是一个处理能力有限的嵌入式设备。所以我的观点是数据可以通过WS明文传输。

所以我的方法是让客户端通过 wss 连接到服务器，进行身份验证并请求会话密钥。然后客户端将断开 wss 连接，然后通过 ws 连接到服务器，并传递从之前的 wss 连接接收到的会话密钥。如果连接立即传递有效的会话密钥（会话密钥具有适当的到期时间），服务器将仅接受 ws 连接。每个客户端仅允许通过 ws 进行一次连接尝试，并在成功的 wss 连接上进行重置。

所以我的问题是这种方法是否合理，或者我的方法是否会有一些严重的漏洞。我仅限于ws和wss，我在服务器上使用node.js和websocket-node，在客户端使用纯javascript。

4

1 回答 1

1

这听起来相当合理（假设服务器到客户端确实不是秘密）。但是，我会建议一些变化：

  • 只需保持从客户端到服务器的两个 WebSocket 连接。第一个是 wss，用于令牌交换和客户端到服务器命令（您提到的可能有害）。如果第一个连接断开或超时，则 ws 连接也应终止。
  • 不允许任何客户端通过 ws 连接来服务器命令/控制。
  • 确保除了超时之外，令牌只能使用一次。否则，攻击者可以嗅探 ws 连接并尝试重放令牌以获得连接。

您还需要确保您的初始 wss 连接是经过授权的（不仅仅是加密的）。换句话说，服务器需要能够验证客户端是它所说的那个人并且有权建立这个连接。此外，如果 ws 连接真的只是用于未受保护的服务器到可以被嗅探的客户端数据，那么如果攻击者能够成功建立连接，那也不是世界末日，因为他们只是用尽了带宽和服务器 CPU （再次假设客户端到服务器的命令仅限于 wss 连接）。

另外，我会尝试将服务器到客户端的连接作为 ws 和 wss 进行基准测试。额外的 CPU 负载可能比您预期的更容易忍受（某些嵌入式设备也具有 SSL/TLS 卸载硬件）。

于 2013-01-08T16:41:20.933 回答