WebSocket消息加密需分层设计：TLS仅保传输通道，应用层必须实现端到端加密（E2EE），否则服务端内存、日志及内网调用中数据仍为明文；推荐混合加密架构，首次连接用RSA加密随机AES密钥，后续消息采用AES-GCM（含IV、tag及AAD校验），密钥会话级隔离且不持久化；前端应使用Web Crypto API动态生成密钥与IV，服务端仅透传加密载荷；解密须严格校验IV、tag、AAD一致性及时间戳有效性，失败即丢弃整帧。

WebSocket 消息加密不能只靠 wss://，必须分层设计：TLS 保通道，应用层做端到端加密（E2EE），否则服务端内存、日志、内网微服务调用中数据仍是明文。

明确加密边界：WSS 不等于消息安全

wss:// 只加密传输链路，等同于 HTTPS 对 HTTP 的保护。一旦连接终止在 Nginx 或负载均衡器，后续到业务服务的通信（如 ws:// 内网转发）就是明文。浏览器调试器、内存 dump、服务端未脱敏日志，都可能直接暴露原始消息内容。审计常见问题：聊天记录、用户 ID、支付金额字段全为明文 JSON。

推荐采用混合加密架构

兼顾安全性与性能，避免单用 RSA（慢、有长度限制、无 IV）或硬编码 AES 密钥（密钥泄露即全线崩溃）：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 首次连接后，客户端用服务端下发的 RSA 公钥加密一个随机生成的 32 字节 AES-256 密钥，发送回服务端
• 服务端用私钥解出该密钥，双方以此建立本次会话专属的对称加密通道
• 后续所有消息均使用 AES-GCM 加密：带认证标签（tag），防篡改；每次使用唯一 12 字节 IV；附加数据（AAD）包含时间戳 + client_id，用于校验时效性与来源
• 会话断开即丢弃密钥，不复用，不存 Cookie 或 URL 参数中

前端实现要点（Web Crypto API）

不用 CryptoJS 等第三方库，优先使用浏览器原生 window.crypto.subtle：

• 密钥通过安全接口动态获取（绑定 access_token 或 session_id），绝不写死在 JS 中
• 消息先用 TextEncoder 编码为 Uint8Array，避免中文乱码
• IV 每次调用 crypto.getRandomValues(new Uint8Array(12)) 生成，base64 后与密文一并传输
• 服务端只透传加密载荷，不参与解密逻辑 —— 即使是 WebSocket 代理（如 Cloudflare），也应配置为 TLS 直通

后端解密关键校验项

解密失败常因格式或参数错位，需重点检查：

• base64 解码后是否正确分离 IV（前 12 字节）、密文主体、GCM tag（最后 16 字节）
• AES-GCM 解密时传入的 additionalData 是否与加密端完全一致（含时间戳格式、client_id 拼接方式）
• 时间戳偏差是否超过预设阈值（如 ±30 秒），超时则拒绝解密
• 解密返回 null 或抛异常时，必须丢弃整帧，不作任何 fallback 处理