典型场景:
客户端使用 HTTPS 在 POST 请求中将其凭据发送到服务器。
服务器验证凭据是否正确并对用户进行身份验证。因此它向客户端返回一个 JWT(JSON Web Token)。
客户端打开一个非安全 WebSocket 连接 (
ws://)。所以客户端和服务器现在有一个 channel 可以轻松地交换数据(具体原因在这里并不重要)。用户通过WebSocket连同JWT向服务器发送任何类型的请求，服务器可以验证这些请求是否合法。
服务器在成功验证每个请求的 JWT 后，使用 WebSocket channel 返回用户请求的数据。
因为我们使用了 HTTPS，所以我们假设 JWT 在发布时没有被盗(HTTPS 可能会被击败，但我们假设它对我们的目的来说是正常的)。
我们使用不安全的 WebSocket 这一事实意味着有人可以嗅探 WebSocket channel 的流量并在心跳中窃取 JWT。因此，我们改用 WebSocket Secure (wss://) 并应用与之前相同的场景。
现在我们正在使用 WebSocket Secure，当我们使用 WSS channel 时，是否需要在我们向服务器发出的每个请求中继续发送 JWT？或者 WebSocket 安全通道是否足够安全，以至于服务器和客户端都 100% 确定(只要 TLS 没有被击败)该 channel 是合法的？
换句话说:一旦安全地建立了 WSS channel ，我们可以信任它吗？ (直到连接明显关闭)
我不太明白 WSS 连接是如何建立的，以及建立后如何工作。我的理解是:关键部分是握手，一旦握手完成，您就可以安全地依赖 WSS channel (因为它可以防止使用 TLS 的 MITM 攻击，而 WS 不会这样做)。
最近几天我阅读了很多关于这一切的资料，但有些概念仍然不清楚。任何帮助将不胜感激!
最佳答案
Websockets 使用持久的 TCP/IP 连接。
使用 wss 类似于使用 HTTPS，这意味着一旦 SSL/TLS 握手完成，所有 Websocket 数据都将“包装”(通常编码)在 TLS 包中。
假设 TLS/SSL 连接是安全的，Websocket 连接将保持安全并且可以(并且可能应该)仅验证一次。
因此，没有理由一遍又一遍地发送 JWT。使用连接的持久状态将用户“分配”到连接是更好的解决方案。
旁注:虽然不安全，但即使在“明文”使用 Websocket 连接时也最好发送一次 JWT (ws://)，因为嗅探 JWT 的机会较少。
关于ssl - 初始握手后我可以安全地依赖 WebSocket 连接吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46606719/