直接启用 TLS 1.3 并禁用旧版本是最有效的加密风险清零方式，它天然剔除 RC4、3DES、SHA-1、MD5、静态 RSA、CBC 等所有已知高危组件，且 RFC 8996 与 PCI DSS 已强制淘汰 TLS 1.0/1.1。
直接启用 TLS 1.3 并禁用旧版本，是当前最有效、最简洁的加密风险清零方式。它不是简单“加个新协议”，而是通过协议层重构，天然剔除 RC4、3DES、SHA-1、MD5、静态 RSA、CBC 模式等所有已知高危组件，无需逐条排查套件——只要 TLS 1.3 跑起来，这些风险就不存在了。
明确禁用 TLS 1.0 和 1.1
这两个版本已被 RFC 8996 正式弃用，且被 PCI DSS 等合规标准强制淘汰。它们无法支持前向保密，也缺乏对现代攻击（如 POODLE、BEAST）的防护能力。
- Windows 系统：修改注册表项 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols，将 TLS 1.0 和 1.1 的 Enabled 值设为 0，并确保 DisabledByDefault 为 1
- Nginx：在 server 块中配置 ssl_protocols TLSv1.2 TLSv1.3，不写 TLSv1 或 TLSv1.1
- .NET 应用：.NET Framework 4.8+ 默认支持 TLS 1.3，但需确保未在代码中硬编码
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11这类过时设置
只保留 TLS 1.3 原生密码套件
TLS 1.3 本身只定义了 5 个标准化密码套件，全部基于 AEAD 模式（如 AES-GCM、ChaCha20-Poly1305），全部强制前向保密，全部禁用非认证加密。你不需要“筛选”套件，只需确保服务端不降级协商到 TLS 1.2。
- Nginx 示例：ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256' —— 这些是 TLS 1.3 专属套件名，不含任何 TLS 1.2 兼容标识
- OpenSSL 3.0+：默认启用 TLS 1.3，无需额外配置套件；若使用旧版 OpenSSL，需确认编译时启用了 TLS 1.3 支持
- SQL Server：依赖 Windows Schannel，只要系统启用 TLS 1.3 且禁用旧协议，SQL Server 自动使用 TLS 1.3 套件，无需数据库侧单独配置
验证是否真正运行在 TLS 1.3 上
配置完成不等于生效。很多环境表面启用了 TLS 1.3，实际仍因客户端兼容性或中间设备拦截而回落到 TLS 1.2。
- 用浏览器开发者工具 → Security 标签页，查看连接详细信息中的协议版本
- 用 openssl s_client -connect example.com:443 -tls1_3 直连测试，确认返回中含 Protocol : TLSv1.3 和有效证书链
- 用 Wireshark 抓包：TLS 1.3 的 ClientHello 中 supported_versions 扩展必须包含 0x0304（即 TLS 1.3），且 ServerHello 后所有握手消息（如 Certificate、CertificateVerify）均为加密传输
注意 0-RTT 的安全边界
TLS 1.3 的 0-RTT 能显著提速，但它存在重放风险，仅适用于幂等操作（如 GET 请求）。对登录、支付等敏感操作，服务端应主动拒绝 0-RTT 数据，或结合时间戳/Nonce 机制校验。
- Nginx 不直接控制 0-RTT，由底层 OpenSSL 或 BoringSSL 决定；生产环境建议默认关闭 0-RTT，除非业务明确需要且已做好防重放设计
- 应用层应在接收 0-RTT 数据前检查请求幂等性，例如对 POST 请求返回 425 Too Early 状态码
- 避免在 0-RTT 数据中携带身份凭证、会话令牌等敏感信息
