TLS 加固的三条底线
TLS 服务端加固先说三条底线：只启用 TLS 1.2 与 1.3，只保留具备前向保密的 ECDHE 加 AEAD 套件，证书链与 SNI 配置正确。在这之上再考虑 HSTS、OCSP 装订、会话票据策略与密钥轮换。加固追求的是安全性与兼容性的平衡，把选项调到最严格往往以牺牲可用性为代价，改完必须用真实客户端矩阵复测。
nginx 参考配置
nginx 参考配置
ssl_protocols TLSv1.2 TLSv1.3; # 只留现代版本
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off; # 现代客户端由客户端优先更合适
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # 会话缓存降低重复握手开销
ssl_session_tickets off; # 关闭票据以换取更强的前向保密
ssl_stapling on; # 开启 OCSP 装订
ssl_stapling_verify on;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains' always;配置项读法
| 配置 | 作用 | 注意事项 |
|---|---|---|
| ssl_protocols | 允许的协议版本 | 保留 1.0 与 1.1 会让整站合规状态失效 |
| ssl_ciphers | 套件列表 | 只留 ECDHE 加 AEAD，避免 CBC 与静态 RSA |
| ssl_prefer_server_ciphers | 是否优先服务端顺序 | 现代客户端下通常设为 off |
| ssl_session_cache | 会话缓存 | 显著降低重复握手开销，注意共享内存上限 |
| ssl_session_tickets | 会话票据 | 关闭提升前向保密，代价是恢复性能下降 |
| ssl_stapling | OCSP 装订 | 减少客户端额外查询，需保证能访问 CA |
| HSTS 头 | 强制浏览器只用 HTTPS | 下发前确认全部子域都有有效证书 |
典型使用场景
- 等保或 PCI 类合规扫描报出弱协议与弱套件，需要按要求收敛配置
- 新站点上线前先做一次基线加固，避免后续带着历史配置迁移
- CDN 与源站同时配置 TLS，需要保证两段都满足同一套要求
- 排查兼容性投诉时，按客户端矩阵确认是哪些套件被收紧导致失败
- 更换证书与密钥后核对加固项是否仍然生效
改完必须验证
改完必须验证
nginx -t && nginx -s reload # 先语法检查再重载
openssl s_client -connect h:443 -tls1 </dev/null 2>&1 | head -3 # 期望直接失败：旧版本已关闭
openssl s_client -connect h:443 -tls1_3 -brief </dev/null | head -6 # 确认 1.3 协商成功
nmap --script ssl-enum-ciphers -p 443 h # 列出实际支持的协议与套件任何 TLS 配置改动都要先验证再全量生效：用 nginx -t 检查语法，重载后立即用 s_client 与扫描工具复测。套件写错会让部分客户端直接握手失败，现象往往只在特定设备上出现。
关闭会话票据是在前向保密与恢复性能之间做取舍：票据密钥一旦泄露会影响已建立的会话，高并发场景应结合连接复用能力评估再决定。