websocket 必须使用 wss:// 并强制启用 tls 1.3，禁用 tls 1.0/1.1，谨慎配置 tls 1.2（禁用 cbc、rsa 密钥交换等），结合 sni、证书校验、子协议与 origin 验证实现纵深防御。
WebSocket 本身不提供加密能力，必须依赖底层传输协议来保障通信安全。实际部署中，应始终使用 wss://（WebSocket Secure）而非 ws://，即让 WebSocket 运行在 TLS 加密通道之上。TLS 版本选择直接决定连接的安全基线和抗攻击能力。
TLS 1.3 是当前唯一推荐的版本
截至 2026 年，TLS 1.3 已成为事实上的工业标准，全球约 66% 的 HTTPS 流量使用该版本。对 WebSocket 而言，采用 TLS 1.3 可带来三重实质性加固：
- 握手仅需 1 次往返（1-RTT），重复连接支持 0-RTT，显著降低首帧延迟，尤其利于实时交互场景
- 强制启用前向保密（PFS），即使服务器私钥未来泄露，历史 WebSocket 会话也无法被解密
- 精简密码套件，移除了 RSA 密钥交换、RC4、CBC 模式、SHA-1、MD5 等已知不安全算法，仅保留 AES-GCM、ChaCha20-Poly1305 等现代加密组合
必须禁用 TLS 1.0 和 1.1
这两个版本已被 IETF 正式弃用，主流浏览器和操作系统（包括 Windows Server 2012 及更新版本）默认禁用。它们存在 BEAST、POODLE 等可利用漏洞，且不支持前向保密。若服务端仍启用 TLS 1.0/1.1，攻击者可能通过降级攻击迫使客户端回退至弱协议，使 wss 连接形同虚设。
谨慎对待 TLS 1.2 的配置细节
虽然 TLS 1.2 尚未完全淘汰，但其安全性高度依赖具体配置：
- 禁用所有基于 CBC 模式的密码套件（如 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA），避免填充预言类攻击（如 POODLE 变种）
- 禁用静态 RSA 密钥交换，强制使用 ECDHE 等支持前向保密的密钥交换机制
- 优先选用 SHA-256 或更高强度的签名哈希算法，避免使用 SHA-1
- 确保服务器证书由可信 CA 签发，且有效期符合最新要求（自 2029 年起 SSL/TLS 证书最长有效期为 47 天，需自动化续期）
配套加固不可忽视
TLS 版本只是基础，还需结合其他措施形成纵深防御：
- 启用服务器名称指示（SNI），支持单 IP 托管多个 wss 域名，避免证书混淆
- 在 Web 服务器（如 Nginx、Apache）或反向代理层统一配置 TLS 策略，避免应用层自行处理加密逻辑
- 定期审计密码套件顺序，确保最强选项排在最前；可通过在线工具（如 SSL Labs Test）验证配置有效性
- 对 WebSocket 子协议（subprotocol）和 Origin 头做严格校验，防止跨域滥用
