TLS 1.3是当前唯一能天然规避POODLE、FREAK等握手攻击的协议版本，它移除RSA密钥传输与静态DH，强制前向保密，并需配合可信CA证书、客户端双向验证及强加密套件协同实现严苛鉴权。
要让 Web 应用支持严苛的 TLS 握手鉴权，核心不是“开个开关”就能实现，而是从协议版本、证书策略、密钥交换机制和客户端身份验证四个层面协同收紧。重点在于拒绝弱协商、强制前向保密、验证可信链，并让应用层真正参与证书校验。
启用 TLS 1.3 并禁用降级协商
TLS 1.3 是当前唯一能天然规避多数握手攻击（如 POODLE、FREAK）的协议版本。它移除了 RSA 密钥传输、静态 DH、重协商等不安全机制，且默认启用前向保密。
- 确保服务器软件版本支持：Nginx ≥ 1.13.0、Apache ≥ 2.4.37、Tomcat ≥ 9.0.31（或 11+ 默认启用）
- 在配置中显式限定协议版本，例如 Nginx：
ssl_protocols TLSv1.3;，**不要写成TLSv1.2 TLSv1.3**——这会允许客户端降级到 TLS 1.2 并选择弱套件 - 禁用所有非 AEAD 类型的加密套件，只保留类似
TLS_AES_256_GCM_SHA384或TLS_CHACHA20_POLY1305_SHA256的强套件
部署可信证书并验证完整信任链
严苛鉴权的前提是服务器证书本身经得起检验。自签名或内部 CA 签发的证书无法满足“严苛”要求，必须由公开信任的 CA（如 Let’s Encrypt、Sectigo、DigiCert）签发。
- 证书必须包含完整中间证书链（bundle），不能仅上传 leaf 证书；Nginx 使用
ssl_certificate指向含 chain 的 PEM 文件，Apache 使用SSLCertificateChainFile或合并进主证书文件 - 启用 OCSP Stapling，让服务器主动提供证书吊销状态，避免客户端自行查询造成延迟或绕过验证
- 对 EV 或 OV 证书，可额外开启证书透明度（CT）日志检查（如通过 OpenSSL 的
-ct参数或 Nginx 的ssl_ct模块），增强对异常签发的感知能力
强制客户端证书并启用双向验证逻辑
单向 TLS（仅服务端证明身份）已不足以应对高敏场景。严苛鉴权需启用 mTLS（mutual TLS），即客户端也必须提供有效证书，且服务端代码必须执行校验。
- Azure 应用服务需在门户中开启“客户端证书模式”（如 Required），但注意：这只是转发证书，不自动校验
- 实际校验必须由应用代码完成——例如 Node.js 中检查
req.client.authorized和req.client.certificate；Java Spring Boot 中通过SSLContext提取并验证X509Certificate链；Tomcat 需设置clientAuth="true"并在 Filter 或 Servlet 中调用request.getAttribute("javax.servlet.request.X509Certificate") - 校验项至少包括：证书未过期、未被吊销（OCSP/CRL）、主题或 SAN 匹配预设白名单、签发者在信任库中、公钥强度 ≥ 2048 位 RSA 或 ≥ 256 位 EC
关闭明文通道与弱依赖项
再强的 TLS 握手，若运行在 HTTP 上或依赖不安全的底层组件，整体防线即失效。
- 彻底禁用 HTTP 端口（如 80）的响应，或强制 301 重定向至 HTTPS —— 但更推荐直接关闭监听，防止配置遗漏
- 禁用 TLS 压缩（防范 CRIME 攻击）、禁用重协商（除非明确启用安全重协商）、关闭 Session Ticket（避免密钥复用风险）
- 确认底层操作系统 Schannel（Windows）或 OpenSSL（Linux）版本不低于安全基线（如 OpenSSL ≥ 1.1.1u，Windows Server ≥ 2019 with latest updates）
