使用WSS进行身份验证然后将WS用于数据是否有意义?

时间:2013-01-08 09:22:36

标签: security ssl websocket

我正在使用websockets进行一些工作,需要解决安全问题。从我所看到的内容可以看出,在我的情况下SSL是最好的方法,所以WSS是要走的路(这不是问题,只是事实陈述)。

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

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

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

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

1 个答案:

答案 0 :(得分:1)

这听起来相当合理(假设服务器到客户端真的不是秘密)。我会建议一些变化:

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

您还需要确保您的初始wss连接已获得授权(而不仅仅是加密)。换句话说,服务器需要能够验证客户端是否是它所声称的并且具有进行此连接的授权。此外,如果ws连接真的只是针对不受保护的服务器到客户端数据,可以被嗅探,那么如果攻击者成功地建立连接,那么它就不是世界末日,因为他们只是在耗尽带宽和服务器CPU (再次假设客户端到服务器命令仅限于wss连接。)

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