4. TLS 版本与配置：TLS 1.2 vs TLS 1.3、协议版本降级攻击、服务端配置最佳实践、客户端配置最佳实践

聊到TLS版本，我见过太多团队还在用TLS 1.0甚至SSL 3.0。说实话，每次看到这种配置，我心里都咯噔一下。版本选择不是简单的“能用就行”，它直接决定了你的加密通道有多坚固。

4.1 TLS 1.2 vs TLS 1.3：核心差异

先看一张对比表，把两个版本的关键区别摆出来。

我个人习惯把TLS 1.3看作一次“减法革命”。它砍掉了那些容易出问题的特性，比如压缩、重协商、静态RSA密钥交换。你想想看，攻击面少了，安全自然就上去了。

我在项目中遇到过一家金融客户，他们的支付接口还在用TLS 1.2的RSA密钥交换。我告诉他们：一旦私钥泄露，之前所有通信记录都能被解密。这就是没有前向安全性的代价。TLS 1.3强制使用(EC)DHE，每次会话的密钥都是临时生成的，私钥泄露只影响当前会话，不影响历史数据。

4.2 协议版本降级攻击

降级攻击，说白了就是攻击者强迫客户端和服务端使用一个更弱的协议版本。比如你支持TLS 1.3，攻击者通过中间人篡改握手消息，让你们俩都以为对方只支持TLS 1.0。

为什么会这样？因为TLS协议设计时考虑了向后兼容。客户端在ClientHello里告诉服务端“我支持的最高版本是1.3”，服务端如果只支持1.2，就回复一个ServerHello说“我们用1.2”。攻击者可以伪造这个回复，让双方都降级到更低的版本。

我曾经在渗透测试中复现过这种攻击。目标是一个老旧的内网系统，服务端配置了TLS 1.2，但客户端库版本太旧，没有实现降级保护机制。我通过中间人工具修改了ClientHello中的supported_versions扩展，服务端就乖乖降级到了TLS 1.0。然后我用一个已知的BEAST攻击脚本，成功解密了会话流量。

防御降级攻击的关键措施：

• 服务端： 禁用SSL/TLS回退，设置最低允许的TLS版本，启用SCSV（Signaling Cipher Suite Value）回退指示。
• 客户端： 实现降级保护机制，比如TLS 1.3客户端在收到低于1.3的ServerHello时，必须验证服务端是否真的不支持更高版本。
• 监控： 记录所有TLS握手失败的日志，特别是版本协商异常的情况。

4.3 服务端配置最佳实践

服务端配置是TLS安全的第一道防线。我总结了一套“四步走”的配置方法。

1. 版本控制： 只启用TLS 1.2和TLS 1.3。禁用TLS 1.0、TLS 1.1以及所有SSL版本。
2. 密码套件选择： 对于TLS 1.3，使用默认套件即可。对于TLS 1.2，只启用支持前向安全性的ECDHE套件。
3. 证书管理： 使用至少2048位的RSA密钥或256位的ECDSA密钥。证书链要完整，不要漏掉中间证书。
4. 安全扩展： 启用HSTS、OCSP Stapling、证书透明度等扩展。

下面是一个Nginx的配置示例，我经常用它作为基线模板。

server {
    listen 443 ssl http2;
    server_name example.com;

    # 版本控制：只允许TLS 1.2和1.3
    ssl_protocols TLSv1.2 TLSv1.3;

    # 密码套件：优先使用TLS 1.3的套件
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on;

    # 证书路径
    ssl_certificate /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # HSTS
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # 其他安全头
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options DENY;
}

4.4 客户端配置最佳实践

客户端配置往往被忽视。很多开发者觉得“服务端配好了就行”，但客户端的安全同样重要。你想想看，如果客户端库有漏洞，攻击者照样能绕过服务端的防护。

客户端配置的核心原则：

• 版本协商： 客户端应该主动声明支持的最高版本，并实现降级保护。不要默认使用系统自带的旧版TLS库。
• 证书验证： 严格验证服务端证书的合法性，包括域名匹配、有效期、吊销状态。不要跳过证书验证。
• 密码套件： 优先使用服务端推荐的套件，但客户端也要有自己的安全底线。比如禁用所有不提供前向安全性的套件。
• 会话恢复： 合理使用会话ID和会话票据，但要注意0-RTT的安全风险（可能被重放攻击）。

下面是一个Python客户端的配置示例，使用ssl模块和requests库。

import ssl
import requests

# 创建SSL上下文
context = ssl.create_default_context()

# 只允许TLS 1.2和1.3
context.minimum_version = ssl.TLSVersion.TLSv1_2
context.maximum_version = ssl.TLSVersion.TLSv1_3

# 禁用不安全的密码套件
context.set_ciphers('ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM')

# 严格验证证书
context.verify_mode = ssl.CERT_REQUIRED
context.check_hostname = True

# 使用自定义会话
session = requests.Session()
session.verify = True

# 发起请求
response = session.get('https://example.com', timeout=10)
print(response.status_code)

4.5 知识体系结构图

下面这张SVG图展示了TLS版本与配置的核心逻辑，包括版本对比、降级攻击路径、以及服务端/客户端的配置要点。

这张图把整个知识体系串起来了。从版本选择开始，到两个版本的特性对比，再到降级攻击的路径，最后落到服务端和客户端的防御措施。你可以在实际工作中把它当作一个检查清单。