直接禁用tlsv1.0和tlsv1.1是防范beast、poodle等历史漏洞最根本有效的做法；需在nginx每个server块中明确配置ssl_protocols tlsv1.2 tlsv1.3，禁用弱套件、启用pfs与aead加密，并通过openssl、nmap及ssl labs实测验证。
直接禁用 TLSv1.0 和 TLSv1.1 是防范 BEAST、POODLE 等历史漏洞最根本有效的做法。这些攻击不依赖私钥泄露或配置疏漏，而是利用旧协议本身的设计缺陷——比如 TLSv1.0 中可预测的初始化向量（BEAST）和松散的填充字节验证（POODLE）。只要服务器不协商这些协议，攻击就完全无法触发。
只启用 TLSv1.2 和 TLSv1.3
在 Nginx 的 每个 server 块（尤其是监听 443 的 HTTPS 配置中）明确指定协议版本：
- 删除所有 SSLv2、SSLv3、TLSv1.0、TLSv1.1
- 仅保留
ssl_protocols TLSv1.2 TLSv1.3; - 不要写成
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3—— 只要含任一低版本，扫描工具就会判为不安全 - 该配置必须出现在实际生效的 server 块内，不能只写在 http 块里被覆盖
搭配强加密套件并启用前向保密
协议只是基础，加密套件选择同样关键。BEAST 和 POODLE 虽属协议层漏洞，但弱套件会放大风险，且影响合规评级：
- 使用现代 AEAD 类算法，如
ECDHE-ECDSA-AES128-GCM-SHA256或ECDHE-RSA-AES256-GCM-SHA384 - 禁用 RC4、3DES、CBC 模式套件（如
AES128-SHA），它们易受 BEAST、Lucky13 等攻击 - 设置
ssl_prefer_server_ciphers on;，确保服务端主导套件协商 - 启用 PFS（前向保密），即使私钥未来泄露，历史流量也无法解密
关闭 TLS 压缩与冗余功能
CRIME 和 BREACH 攻击虽不直接等同于 BEAST/POODLE，但常在同一扫描报告中并列出现，属于同类威胁模型：
- 确认未启用
ssl_session_compression on;（Nginx 默认已关闭，但需检查自定义配置） - 避免在响应头中暴露压缩信息，如
Vary: Accept-Encoding对敏感接口慎用 - 禁用不必要扩展，例如不启用
ssl_buffer_size强制小包（可能加剧 BEAST 风险）
验证配置是否真正生效
改完配置后务必测试，不能只看 reload 成功：
- 用
openssl s_client -connect example.com:443 -tls1_1尝试连接，应返回 handshake failure - 运行
nmap --script ssl-enum-ciphers -p 443 example.com查看实际支持的协议与套件 - 提交域名到 SSL Labs，获取 A+ 评级及详细漏洞提示
- 检查 HTTP 响应头中是否仍存在
Server: nginx/...或错误页泄露版本信息（防暴露是整体安全的一环）
