1.1 明文HTTP的三大威胁#

HTTP 协议设计于 1990 年代初，那时的互联网还是学术网络，安全不是优先考虑的问题。HTTP 消息以纯文本传输，这意味着：

窃听（Eavesdropping）：任何网络路径上的设备都能读取 HTTP 消息内容。你在咖啡店 WiFi 下登录网银，同一网络下的任何人都可以用 Wireshark 看到你的用户名和密码。这不是理论风险——Firesheep 浏览器插件在 2010 年就演示了在开放 WiFi 上劫持 Facebook 会话有多容易。

篡改（Tampering）：中间人可以修改 HTTP 响应内容。ISP 可以在网页中注入广告，运营商可以在下载的 APK 中捆绑恶意软件，酒店 WiFi 可以在页面中插入 JavaScript。中国运营商的”流量充值弹窗”就是 HTTP 响应篡改的典型例子。

冒充（Impersonation）：没有身份验证机制，任何服务器都可以声称自己是 www.example.com。DNS 劫持加上 HTTP 明文传输，攻击者可以构建一个与真实网站一模一样的钓鱼页面，用户完全无法分辨。

1.2 CIA三要素与TLS的应对#

信息安全领域的 CIA 三要素——机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）——为分析安全需求提供了框架：

1.3 从SSL到TLS#

TLS 的前身是网景公司 1994 年设计的 SSL（Secure Sockets Layer）协议。SSL 2.0 存在严重安全缺陷，SSL 3.0 也不够安全（POODLE 攻击）。1999 年，IETF 接管协议标准化，将其更名为 TLS 1.0。后续版本演进：

2021 年起，主流浏览器和服务器已陆续禁用 TLS 1.0/1.1。今天部署 TLS 服务，至少应支持 TLS 1.2，推荐以 TLS 1.3 为主。

2.1 RSA密钥交换的完整握手#

TLS 1.2 最经典的握手方式基于 RSA 密钥交换。客户端用服务器证书中的 RSA 公钥加密一个随机生成的预主密钥（Pre-Master Secret），服务器用私钥解密，双方再基于三个随机数推导出会话密钥。

整个握手需要 2 个 RTT：第一个 RTT 交换 Hello 消息，第二个 RTT 交换密钥材料和 Finished 消息。握手完成后，双方使用推导出的会话密钥进行对称加密通信。

RSA 密钥交换的致命缺陷是没有前向保密：如果服务器的长期私钥泄露，攻击者可以解密以前录制的所有 TLS 会话。预主密钥只用服务器公钥加密了一次，私钥就是解密的万能钥匙。

2.2 ECDHE密钥交换#

为了解决前向保密问题，TLS 1.2 引入了基于临时 Diffie-Hellman 的密钥交换——DHE 和 ECDHE。ECDHE 使用椭圆曲线，在相同安全强度下密钥更短、计算更快，是目前的主流选择。

ECDHE 握手流程与 RSA 握手类似，但 ServerHello 之后多了 ServerKeyExchange 消息，服务器在此发送 ECDHE 参数和签名：

关键区别：会话密钥不是由预主密钥推导，而是由双方的临时 Diffie-Hellman 公钥计算出的共享密钥推导。临时密钥对在每次握手时重新生成，用完即弃——即使服务器长期私钥泄露，也无法反推过去的临时密钥，从而实现前向保密。

2.3 证书链验证#

握手过程中，客户端收到服务器证书后需要验证其真实性。验证不是简单地检查一张证书，而是沿着证书链逐级验证：

1. 接收证书链：服务器发送的通常不是一张证书，而是一个证书链——服务器证书 → 中间 CA 证书 → （可能还有更多中间 CA）→ 根 CA 证书
2. 逐级签名验证：每一张证书由上一级 CA 的私钥签名，客户端用上一级 CA 证书中的公钥验证签名
3. 到达信任锚：验证到客户端信任存储（Trust Store）中已存在的根 CA 证书为止
4. 附加检查：有效期、域名匹配（SAN/CN）、用途扩展（EKU）、吊销状态

以访问 www.example.com 为例，证书链可能如下：

1
DigiCert Global Root CA（根CA，预装在浏览器/OS信任存储中）
2
  └─ DigiCert TLS RSA SHA256 2020 CA1（中间CA）
3
       └─ www.example.com（终端实体证书，EE证书）

浏览器验证时，先用中间 CA 的公钥验证 www.example.com 证书的签名，再用根 CA 的公钥验证中间 CA 证书的签名，最后确认根 CA 在本地信任存储中。任何一级验证失败，连接都会被终止。

3.1 设计动机#

TLS 1.2 的设计积累了 20 年的安全债：过多不安全的密码套件、复杂的协商过程、已知漏洞的算法。TLS 1.3 不是在 1.2 上打补丁，而是大幅简化——移除了所有不安全的算法，将握手从 2-RTT 缩短到 1-RTT，并引入 0-RTT 模式。

TLS 1.3 移除的内容包括：RSA 密钥交换（不支持前向保密）、静态 DH 密钥交换、CBC 模式密码、RC4、SHA-1、MD5、压缩、 renegotiation、非 AEAD 密码套件。这意味着 TLS 1.3 只保留了经过充分验证的算法，大幅减少了实现错误的可能性。

3.2 1-RTT握手#

TLS 1.3 的核心优化是：客户端在 ClientHello 中直接发送密钥交换参数，不必等服务器先发证书再决定用什么密钥交换方式。

与 TLS 1.2 的关键区别：

• 客户端在第一条消息中就发送 ECDHE 公钥（key_share 扩展），服务器收到后立即可以计算共享密钥
• 服务器在 ServerHello 之后的全部消息都已加密——包括证书！TLS 1.2 中证书是明文传输的，TLS 1.3 加密了证书，提升了隐私性
• 不再有 ChangeCipherSpec 消息，密钥切换隐含在握手流程中
• CertificateVerify 消息用服务器的私钥对整个握手记录签名，替代了 TLS 1.2 中对 ServerKeyExchange 的单独签名

3.3 0-RTT与PSK#

如果客户端之前与服务器建立过 TLS 1.3 连接，可以使用之前协商的预共享密钥（Pre-Shared Key，PSK）在第一条消息中就发送加密的应用数据——这就是 0-RTT（Zero Round Trip Time）模式：

1
# 0-RTT 的 ClientHello 携带 early_data
2
ClientHello {
3
    tls_version: 1.3
4
    key_share: <ECDHE公钥>
5
    pre_shared_key: <PSK标识>
6
    early_data: <加密的应用数据>   # 0-RTT 数据
7
}

0-RTT 的代价是重放攻击风险：攻击者可以录制并重放 0-RTT 数据，导致服务器重复执行操作（如重复扣款）。因此 0-RTT 只适用于幂等操作，不能用于非幂等的写操作。

3.4 TLS 1.2与1.3对比#

4.1 X.509证书结构#

TLS 证书遵循 X.509 v3 标准。一张证书本质上是一组声明的签名封装——CA 声明”我确认这个公钥属于这个域名”，并用 CA 的私钥对这组声明签名。证书的核心字段：

1
# 查看证书详细信息
2
openssl x509 -in cert.pem -text -noout
3

4
# 输出示例（关键字段）
5
Certificate:
6
    Data:
7
        Version: 3 (0x2)
8
        Serial Number: 0e:8f:...（序列号，CA内唯一）
9
        Signature Algorithm: sha256WithRSAEncryption
10
        Issuer: C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1
11
        Validity:
12
            Not Before: Mar 10 00:00:00 2025 GMT
13
            Not After : Mar 10 23:59:59 2026 GMT
14
        Subject: C=US, O=Example Inc, CN=www.example.com
15
        Subject Public Key Info:
16
            Public Key Algorithm: rsaEncryption
17
                RSA Public-Key: (2048 bit)
18
        X509v3 extensions:
19
            X509v3 Subject Alternative Name:   # SAN，域名匹配的核心
20
                DNS:www.example.com
21
                DNS:example.com
22
            X509v3 Basic Constraints: critical
23
                CA:FALSE                        # 非CA证书
24
            X509v3 Key Usage: critical
25
                Digital Signature, Key Encipherment
26
            X509v3 Extended Key Usage:
27
                TLS Web Server Authentication   # 服务器认证用途
28
    Signature Algorithm: sha256WithRSAEncryption

其中几个字段特别重要：

• Subject Alternative Name（SAN）：证书覆盖的域名列表。现代浏览器只检查 SAN，不再检查 Common Name（CN）。一张证书可以通过 SAN 覆盖多个域名——这就是通配符证书和 SAN 证书的基础
• Basic Constraints：标记证书是否为 CA 证书。CA 证书可以签发下级证书，终端实体证书不能
• Key Usage / Extended Key Usage：限制证书的用途。服务器认证证书的 EKU 必须包含 TLS Web Server Authentication

4.2 CA层级结构#

证书信任不是扁平的，而是层级化的。根 CA 信任存储中通常只有 100 多个根 CA，但它们签发了数百万张终端证书。信任通过层级代理传递：

为什么需要中间 CA？根 CA 的私钥是最核心的资产——一旦泄露，整个信任链崩塌。因此根 CA 的私钥通常离线保存（存在硬件安全模块 HSM 中，物理隔离），日常签发工作由中间 CA 完成。中间 CA 证书由根 CA 签名，但中间 CA 的私钥可以在线使用。这样即使中间 CA 私钥泄露，只需吊销该中间 CA 证书，不影响根 CA 的其他分支。

4.3 证书链验证步骤#

客户端收到证书链后，执行以下验证：

4.4 OCSP装订与CRL#

证书吊销是 PKI 的薄弱环节。CA 签发证书后，如果私钥泄露或证书信息有误，需要通知所有依赖方”这张证书不再可信”。两种标准机制：

CRL（Certificate Revocation List）：CA 定期发布一个被吊销证书的序列号列表。客户端下载 CRL 后在本地缓存，验证时查表。问题在于 CRL 可能很大（数 MB），且更新有延迟——证书刚被吊销，但客户端缓存的 CRL 还是旧的。

OCSP（Online Certificate Status Protocol）：客户端实时向 CA 的 OCSP 响应器查询某张证书的吊销状态。问题在于这暴露了用户的浏览隐私——CA 知道你在访问哪个网站。此外 OCSP 响应器故障时，客户端面临”软失败”（忽略吊销状态）还是”硬失败”（拒绝连接）的两难。

OCSP 装订（OCSP Stapling）：服务器定期从 CA 获取自己证书的 OCSP 响应，并在 TLS 握手时将 OCSP 响应”装订”在 Certificate 消息中发送给客户端。这样客户端不需要单独联系 CA，既保护了隐私，又降低了延迟：

1
# Nginx 启用 OCSP 装订
2
ssl_stapling on;
3
ssl_stapling_verify on;
4
ssl_trusted_certificate /etc/ssl/ca-bundle.crt;  # 中间CA证书
5
resolver 8.8.8.8 8.8.4.4 valid=300s;
6
resolver_timeout 5s;

5.1 Diffie-Hellman密钥交换原理#

Diffie-Hellman（DH）密钥交换的精妙之处在于：双方可以在完全公开的信道上协商出一个共享密钥，任何窃听者都无法计算出这个密钥。其数学基础是离散对数问题的计算困难性。

窃听者可以看到 p、g、A = g^a mod p、B = g^b mod p，但从 A 反推 a（离散对数问题）在计算上不可行，因此无法计算共享密钥 s = g^ab mod p。

椭圆曲线 Diffie-Hellman（ECDHE）将同样的原理搬到椭圆曲线上。用 X25519 曲线时，私钥仅 32 字节，公钥也仅 32 字节，但安全强度等价于 3072 位 RSA——更短的密钥、更快的计算、更少的网络传输。

5.2 RSA密钥交换 vs ECDHE#

5.3 为什么前向保密至关重要#

假设你运营一个 HTTPS 网站，使用 RSA 密钥交换。某情报机构录制的所有 TLS 流量都存储着，暂时无法解密。几年后，他们通过某种方式获取了你的服务器私钥——此时所有历史流量都可以解密。这就是没有前向保密的后果：安全性的保质期等于私钥的保密期。

前向保密改变了这个等式。使用 ECDHE 时，每次握手都生成新的临时密钥对，用完即弃。即使服务器长期私钥泄露，攻击者也无法恢复已丢弃的临时密钥——没有临时密钥，就无法计算共享密钥，就无法解密历史流量。每条 TLS 连接的安全性独立于其他连接，一条连接被攻破不影响其他连接。

2013 年斯诺登泄密事件后，前向保密从”锦上添花”变成了”必须部署”。各大浏览器和服务器纷纷默认启用 ECDHE 套件，TLS 1.3 更是将 ECDHE 作为唯一的密钥交换方式。

6.1 密码套件的组成#

密码套件（Cipher Suite）是一个命名字符串，定义了 TLS 连接使用的全部密码算法。以 TLS_AES_256_GCM_SHA384 为例：

TLS 1.2 的密码套件名称更长，例如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，显式包含密钥交换和身份验证算法。TLS 1.3 简化了命名——密钥交换始终是 ECDHE，身份验证由证书类型决定，套件名只包含加密算法和哈希算法。

6.2 AEAD密码#

TLS 1.3 只允许 AEAD（Authenticated Encryption with Associated Data）密码：AES-GCM、AES-CCM 和 ChaCha20-Poly1305。AEAD 同时提供加密和认证——每条记录既有密文又有认证标签，解密时先验证标签再返回明文，从根本上杜绝了 TLS 1.2 中 CBC 模式的 padding oracle 攻击。

TLS 1.3 定义的 5 个密码套件：

ChaCha20-Poly1305 在没有 AES 硬件加速的移动设备上性能显著优于 AES-GCM。Google 推动了这个套件的标准化——Android 设备大量使用 ChaCha20。

6.3 安全配置实践#

Mozilla 维护的 SSL Configuration Generator 是配置 TLS 的权威参考。以下是一个兼顾安全与兼容的 Nginx 配置：

1
# Nginx TLS 安全配置（Mozilla Intermediate 预设）
2
server {
3
    listen 443 ssl http2;
4
    server_name example.com;
5

6
    # 证书
7
    ssl_certificate     /etc/ssl/certs/example.com.crt;
8
    ssl_certificate_key /etc/ssl/private/example.com.key;
9

10
    # 协议版本
11
    ssl_protocols TLSv1.2 TLSv1.3;
12

13
    # TLS 1.2 密码套件（优先ECDHE+AESGCM）
14
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
15
                ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
16
                ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
17

18
    # TLS 1.3 密码套件（独立配置）
19
    ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:
20
                                     TLS_CHACHA20_POLY1305_SHA256:
21
                                     TLS_AES_256_GCM_SHA384;
22

23
    # 服务器密码套件偏好
24
    ssl_prefer_server_ciphers on;
25

26
    # 会话缓存
27
    ssl_session_cache shared:SSL:10m;
28
    ssl_session_timeout 1d;
29

30
    # 会话票据（TLS 1.2 会话恢复 / TLS 1.3 PSK）
31
    ssl_session_tickets off;  # 票据密钥泄露影响前向保密
32

33
    # OCSP 装订
34
    ssl_stapling on;
35
    ssl_stapling_verify on;
36

37
    # HSTS（强制HTTPS）
38
    add_header Strict-Transport-Security "max-age=63072000" always;
39
}

7.1 openssl s_client#

openssl s_client 是调试 TLS 连接的瑞士军刀，可以查看握手过程的每一个细节：

1
# 基本连接：查看证书链和协商参数
2
openssl s_client -connect example.com:443 -servername example.com
3

4
# 仅查看证书链，不发送HTTP请求
5
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -text -noout
6

7
# 强制使用TLS 1.3
8
openssl s_client -connect example.com:443 -servername example.com -tls1_3
9

10
# 查看完整握手过程（含字节级输出）
11
openssl s_client -connect example.com:443 -servername example.com -msg
12

13
# 测试特定密码套件
14
openssl s_client -connect example.com:443 -servername example.com \
15
  -cipher ECDHE-RSA-AES128-GCM-SHA256
16

17
# 导出服务器证书
18
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
19
  sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' > server.crt
20

21
# 验证证书链
22
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt server.crt

s_client 的输出包含大量信息。重点关注以下字段：

1
# 协商结果
2
Protocol  : TLSv1.3
3
Cipher    : TLS_AES_256_GCM_SHA384
4
Session-ID: A1B2C3...
5
Master-Key: ...（TLS 1.2 显示，1.3 不显示）
6

7
# 证书链深度
8
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
9
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
10
depth=0 C = US, O = Example Inc, CN = www.example.com

7.2 Wireshark抓包分析#

用 Wireshark 抓取 TLS 握手包，可以直观看到每条消息的字段：

1
# 抓取TLS流量（443端口）
2
sudo tcpdump -i eth0 -w tls_capture.pcap 'tcp port 443'
3

4
# 用tshark过滤TLS握手消息
5
tshark -r tls_capture.pcap -Y "tls.handshake.type < 20" -V
6

7
# 仅显示ClientHello中的密码套件
8
tshark -r tls_capture.pcap -Y "tls.handshake.type == 1" \
9
  -T fields -e tls.handshake.extensions_supported_groups
10

11
# 显示服务器选定的密码套件
12
tshark -r tls_capture.pcap -Y "tls.handshake.type == 2" \
13
  -T fields -e tls.handshake.ciphersuite

Wireshark 中的关键过滤器：

7.3 SSL Labs测试#

Qualys SSL Labs 提供的在线测试是评估 TLS 配置安全性的权威工具：

1
# 通过API测试（需要API key）
2
curl "https://api.ssllabs.com/api/v3/analyze?host=example.com"
3

4
# 查看详细终端信息
5
curl "https://api.ssllabs.com/api/v3/getEndpointData?host=example.com&s=1.2.3.4"

更方便的方式是直接访问 https://www.ssllabs.com/ssltest/，输入域名即可获得完整的 TLS 安全评估报告，包括：

• 协议版本支持情况
• 密码套件强度排序
• 证书链验证结果
• 已知漏洞检测（BEAST、POODLE、ROBOT 等）
• 前向保密支持情况
• HSTS 配置检查

目标是获得 A+ 评级。常见扣分项：支持 TLS 1.0/1.1（降级到 B）、缺少 HSTS 头（降级到 A-）、使用弱密码套件。

7.4 证书固定#

证书固定（Certificate Pinning）是一种额外的安全措施——应用不再信任系统默认的 CA 信任存储，而是硬编码只信任特定的证书或公钥。这可以防止恶意 CA 签发伪造证书的攻击。

1
# 提取证书公钥的SHA-256哈希（用于HPKP/证书固定）
2
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
3
  openssl x509 -pubkey -noout | \
4
  openssl rsa -pubin -outform der | \
5
  openssl dgst -sha256 -binary | \
6
  openssl enc -base64
7

8
# 输出示例
9
# pin-sha256="X3pG3Od6kE8bGj5nO9vF2kR7mW4qL1aB5cY8dU0hIjM="

不过，HTTP 公钥固定（HPKP）已被 Chrome 弃用——因为配置错误会导致网站长期不可访问，风险远大于收益。现代替代方案是 Certificate Transparency（CT）：所有公开可信的 CA 必须将签发的证书记录到公开的 CT 日志中，域名所有者可以监控是否有未授权的证书被签发。