初次握手后，我可以安全地依赖 WebSocket 连接吗？

Question

典型场景：

1) 客户端使用 HTTPS 在 POST 请求中将其凭据发送到服务器。

2) 服务器验证凭据是正确的，并对用户进行身份验证。因此它向客户端返回一个 JWT（JSON Web 令牌）。

3) 客户端打开一个非安全的WebSocket 连接 (ws://)。所以客户端和服务器现在有一个通道可以轻松交换数据（确切原因在这里无关紧要）。

4）用户通过WebSocket和JWT一起向服务器发送任何类型的请求，服务器可以验证这些请求是否合法。

5) 服务端每次请求成功验证JWT后，使用WebSocket通道返回用户询问的数据。

因为我们使用了 HTTPS，所以我们假设 JWT 在发布时没有被盗（HTTPS 可能会被击败，但我们假设它对我们的目的来说是正常的）。

我们使用非安全 WebSocket 的事实意味着有人可以嗅探 WebSocket 通道的流量并在心跳中窃取 JWT。因此，我们改用 WebSocket Secure (wss://) 并应用相同的先前场景。

现在我们正在使用 WebSocket Secure，当我们使用 WSS 通道时，我们是否需要在我们向服务器发出的每个请求中继续发送 JWT？或者 WebSocket 安全通道是否足够安全，因此服务器和客户端都 100% 确定（只要 TLS 没有被击败）该通道是合法的？

换句话说：一旦安全建立了 WSS 通道，我们可以信任它吗？（直到连接明显关闭）

我真的不明白 WSS 连接是如何建立的，以及一旦建立它是如何工作的。我的理解是：关键部分是握手，一旦握手完成，您就可以安全地依赖 WSS 通道（因为它可以防止使用 TLS 的 MITM 攻击，而 WS 不会这样做）。

最近几天我读了很多关于这一切的东西，但有些概念仍然不清楚。任何帮助将不胜感激！

Answer 1

Websockets 使用持久的 TCP/IP 连接。

使用wss类似于使用 HTTPS，这意味着一旦 SSL/TLS 握手完成，所有 Websocket 数据都被“包装”（通常是编码）在 TLS 包中。

假设 TLS/SSL 连接是安全的，Websocket 连接将保持安全并且可以（并且可能应该）仅进行一次身份验证。

因此，没有理由一遍又一遍地发送 JWT。使用连接的持久状态将用户“分配”到连接是更好的解决方案。

旁注：虽然不安全，但即使在“明文”( ws://)使用 Websocket 连接时也最好发送一次 JWT ，因为嗅探 JWT 的机会较少。