第四章 TLS (Transport Layer Security)

一、导读

1.1 本章学习目标

理解 TLS 协议的核心目标：机密性、完整性和身份认证

掌握 TLS 1.2 和 TLS 1.3 握手过程的完整步骤及各步骤的安全意义

理解对称加密、非对称加密和哈希函数在 TLS 中的协同工作方式

掌握 TLS 握手对 Web 性能的影响，包括 RTT 开销和计算开销

理解前向保密（Forward Secrecy）的概念及其重要性

了解 TLS 会话恢复机制（Session ID、Session Ticket、TLS 1.3 PSK）

掌握 TLS 1.3 相比 TLS 1.2 的性能改进和安全增强

理解证书链验证过程及 OCSP Stapling 对性能的影响

1.2 为什么本章如此重要

在当今的互联网环境中，TLS 已经从可选的安全增强变成了必需的基础设施。随着 HTTPS 成为事实标准、HTTP/2 和 HTTP/3 强制要求加密传输、以及浏览器对非 HTTPS 站点的警告标记，TLS 的性能特征直接影响着每一个 Web 应用的加载速度和用户体验。

TLS 握手是 HTTPS 连接建立过程中最大的性能瓶颈之一。

TLS 握手延迟对比：

TLS 1.3 通过重新设计握手流程，将握手延迟从 2 个 RTT 减少到 1 个 RTT，并且支持 0-RTT 数据传输（对于之前连接过的服务器）。这些改进对于 Web 性能的提升非常显著，特别是在高延迟的移动网络环境中。

理解 TLS 的工作原理和性能特征，对于合理配置服务器加密参数、选择适当的 TLS 版本、优化证书链以及实施会话恢复策略都至关重要。这些优化措施可以直接减少 TLS 握手延迟，提升 Web 应用的响应速度。

1.3 核心问题引导

TLS 握手过程中，客户端和服务器交换了哪些信息？每条消息的作用是什么？

为什么 TLS 1.2 需要 2 个 RTT 而 TLS 1.3 只需要 1 个 RTT？TLS 1.3 是如何做到的？

对称加密和非对称加密在 TLS 中各自扮演什么角色？为什么不全部使用非对称加密？

什么是前向保密？为什么它对于长期安全性如此重要？

TLS 会话恢复有哪些方式？它们各自的优缺点是什么？

证书链验证过程是怎样的？OCSP 查询如何影响 TLS 握手性能？

TLS 1.3 的 0-RTT 模式是如何工作的？它有什么安全风险？

如何优化 TLS 配置以最大化 Web 性能？

二、核心概念详解

2.1 TLS 握手过程

TLS 握手是客户端和服务器之间建立安全连接的过程，目的是协商加密算法、验证身份并建立共享密钥。TLS 1.2 和 TLS 1.3 的握手过程有显著差异。

TLS 1.2 握手需要 2 个 RTT。第一个 RTT：客户端发送 ClientHello（支持的 TLS 版本、加密套件列表、随机数）；服务器回复 ServerHello（选定的加密套件、随机数）、证书、ServerKeyExchange、ServerHelloDone。第二个 RTT：客户端验证证书，计算预主密钥，发送 ClientKeyExchange、ChangeCipherSpec、Finished；服务器发送 ChangeCipherSpec、Finished。至此握手完成，可以开始传输应用数据。

TLS 1.3 将握手简化为 1 个 RTT。客户端在 ClientHello 中就发送密钥共享参数（key_share）和支持的加密套件；服务器在 ServerHello 中直接返回选定的加密套件、密钥共享参数和加密的扩展信息，然后立即发送 Finished。客户端收到后验证并发送自己的 Finished。整个握手只需 1 个 RTT。

TLS 1.3 还引入了 0-RTT 模式——如果客户端之前连接过该服务器，可以在第一个消息中直接携带应用数据（称为"早期数据"），服务器验证后直接处理。这使得回访用户可以零延迟地开始数据传输。但 0-RTT 数据存在重放攻击风险，不适用于非幂等操作。

握手过程的性能影响非常直接：每个 RTT 的延迟都会累加到页面加载时间中。对于需要建立多个 HTTPS 连接的场景（如加载来自多个域名的资源），TLS 握手的延迟会被放大。这就是为什么 TLS 会话恢复和连接复用如此重要。

2.2 加密体系：对称加密、非对称加密与哈希

TLS 使用三种密码学原语的协同工作来实现安全通信。非对称加密（公钥加密）用于密钥交换和身份认证——服务器使用私钥签名证书，客户端使用服务器的公钥验证签名。对称加密用于实际的数据传输——双方通过密钥交换协商出一个共享的会话密钥，后续所有数据都使用该密钥进行对称加密。哈希函数用于数据完整性校验和密钥派生。

为什么不全部使用非对称加密？因为非对称加密的计算开销比对称加密高出几个数量级。RSA 2048 的加密速度比 AES-256 慢约 1000 倍。因此，TLS 采用混合方案：使用非对称加密安全地交换对称密钥，然后使用对称加密进行高效的数据传输。

TLS 1.3 大幅简化了支持的加密套件。它只保留了 AEAD（Authenticated Encryption with Associated Data）类型的加密套件，如 AES-GCM 和 ChaCha20-Poly1305，这些算法同时提供加密和认证。TLS 1.3 还移除了不安全的算法，如 RSA 密钥传输、CBC 模式加密、RC4、SHA-1 等。

对于 Web 性能，加密计算本身也会引入延迟。服务器的 TLS 握手需要执行非对称加密运算（如 RSA 签名或 ECDH 密钥交换），这些运算的计算量与密钥长度成正比。使用 ECDHE（椭圆曲线 Diffie-Hellman）代替传统的 RSA 密钥交换，可以在保持相同安全强度的同时大幅减少计算开销——ECDHE 256 位密钥的安全强度相当于 RSA 3072 位，但计算速度快得多。

2.3 前向保密（Forward Secrecy）

前向保密（也称为完美前向保密，PFS）是一种安全属性，确保即使服务器的长期私钥在未来被泄露，过去的通信记录也不会被解密。实现前向保密的关键是使用临时密钥交换（Ephemeral Key Exchange）——每次握手都生成新的临时密钥对，握手完成后立即销毁。

在 TLS 1.2 中，如果使用 RSA 密钥交换（非前向保密），客户端直接用服务器的 RSA 公钥加密预主密钥。如果攻击者记录了加密的握手数据，并在未来获取了服务器的 RSA 私钥，就可以解密所有历史通信。

TLS 1.3 强制要求前向保密——只允许使用 ECDHE 密钥交换，彻底移除了 RSA 密钥交换。这意味着 TLS 1.3 的所有连接都具备前向保密特性。

从性能角度看，ECDHE 密钥交换需要服务器在每次握手时执行椭圆曲线运算，比 RSA 密钥交换多了一些计算开销。但由于 ECDHE 256 的运算量远小于 RSA 2048，实际上 TLS 1.3（ECDHE 256 + AES-GCM）的握手性能可能优于 TLS 1.2（RSA 2048 + AES-CBC）。

2.4 TLS 会话恢复

TLS 会话恢复允许客户端和服务器在之前的握手基础上快速恢复安全连接，避免完整的握手开销。TLS 提供了三种会话恢复机制：

Session ID（TLS 1.2）：服务器在握手时分配一个会话 ID，客户端在后续连接中携带该 ID。如果服务器在缓存中找到对应的会话状态，可以跳过密钥协商，直接恢复会话。这需要 1 个 RTT（而非完整握手的 2 个 RTT）。服务器需要维护会话状态缓存。

Session Ticket（TLS 1.2）：服务器将会话状态加密后以 Ticket 的形式发送给客户端存储。后续连接中客户端携带 Ticket，服务器解密后恢复会话。与 Session ID 不同，Session Ticket 不需要服务器维护状态，更适合分布式服务器集群。恢复同样需要 1 个 RTT。

Pre-Shared Key / PSK（TLS 1.3）：TLS 1.3 将前两种机制统一为 PSK。服务器在首次握手结束时发送一个 session_ticket 扩展，包含 PSK 标识和票据。后续连接中，客户端在 ClientHello 中携带 PSK 标识，并可以同时发送早期数据（0-RTT）。PSK 恢复只需 1 个 RTT，加上 0-RTT 数据传输，性能提升显著。

会话恢复对 Web 性能的影响非常显著。对于回访用户，会话恢复可以将 TLS 握手延迟减少 50% 以上（从 1 RTT 减少到 0 或 1 RTT 加上早期数据）。结合 DNS 缓存和 TCP 连接复用，可以显著减少 HTTPS 连接的总建立时间。

2.5 证书验证与 OCSP

TLS 握手过程中，客户端必须验证服务器的数字证书。证书验证包括：检查证书是否由受信任的 CA 签发、验证证书链的签名、检查证书有效期、检查证书是否被吊销。

证书链验证可能涉及多个中间 CA 证书。如果客户端缓存中没有中间证书，服务器需要在握手时发送完整的证书链，增加了数据传输量。一个典型的证书链（叶证书 + 1-2 个中间证书）大小约 3-10KB，在慢速网络中可能需要一个额外的 RTT 来传输。

证书吊销检查是另一个性能瓶颈。传统方式是客户端向 CA 的 OCSP（Online Certificate Status Protocol）响应器发送查询，检查证书是否被吊销。这个额外的 HTTP 请求可能引入 100-500ms 的延迟，而且 OCSP 响应器的可用性往往不稳定。

OCSP Stapling 解决了这个问题：服务器定期从 CA 获取 OCSP 响应，并在 TLS 握手时将其"装订"（Staple）到证书中一起发送给客户端。这样客户端不需要单独查询 OCSP 响应器，减少了一个网络往返。OCSP Stapling 是目前最有效的证书吊销检查优化方案。

三、深入分析与讨论

3.1 TLS 1.3 的安全与性能改进详解

TLS 1.3 是对 TLS 协议的一次全面革新，在安全性和性能两方面都有重大改进。安全性方面，TLS 1.3 移除了所有已知不安全的算法（RSA 密钥传输、CBC 模式、RC4、SHA-1、MD5、EXPORT 级加密、静态 Diffie-Hellman 等），强制使用前向保密（ECDHE），所有加密套件都使用 AEAD 模式。

性能方面，TLS 1.3 将握手从 2-RTT 减少到 1-RTT，并支持 0-RTT。1-RTT 的实现依赖于"密钥共享提前发送"——客户端在 ClientHello 中就发送了 key_share 扩展（包含 ECDHE 公钥），服务器可以直接计算共享密钥，不需要额外的往返。0-RTT 则依赖于 PSK 机制——客户端使用之前建立的 PSK 加密早期数据，服务器收到后可以立即解密处理。

TLS 1.3 还简化了密钥派生过程，使用 HKDF（HMAC-based Key Derivation Function）替代了 TLS 1.2 的 PRF（Pseudorandom Function），提供了更清晰的密钥分层结构。握手消息的加密也更加彻底——TLS 1.3 中除了 ClientHello 和 ServerHello 之外，所有握手消息都是加密的，包括证书和 Finished 消息，提高了隐私保护。

3.2 TLS False Start 与 1-RTT 优化

在 TLS 1.3 普及之前，TLS False Start 是一种在 TLS 1.2 上实现 1-RTT 握手的优化技术。其核心思想是：客户端在收到服务器的 ServerHello 后立即开始发送应用数据，而不需要等待服务器的 Finished 消息。这要求使用支持前向保密的密钥交换（如 ECDHE），确保即使 Finished 消息被篡改，攻击者也无法解密已发送的数据。

Google 在 2010 年提出了 False Start，并在 Chrome 浏览器中实现。然而，False Start 需要客户端和服务器都支持该特性，而且某些中间设备（如 TLS 代理和防火墙）可能会干扰 False Start 的行为。随着 TLS 1.3 的广泛采用，False Start 已逐渐被原生的 1-RTT 握手所取代。

3.3 TLS 性能优化最佳实践

在生产环境中，TLS 的性能优化涉及多个层面。服务器配置方面：优先使用 TLS 1.3，启用 OCSP Stapling，使用 ECDHE 密钥交换（推荐 X25519 曲线），配置 AEAD 加密套件（AES-128-GCM 优先于 AES-256-GCM，因为 128 位安全性已经足够且性能更好）。

证书优化方面：使用 ECC 证书（如 ECDSA P-256）代替 RSA 证书，ECC 256 位的签名速度比 RSA 2048 快约 10 倍；优化证书链长度，移除不必要的中间证书；使用 OCSP Must-Staple 扩展强制要求 OCSP Stapling。

会话恢复方面：启用 Session Ticket 或 TLS 1.3 PSK，配置合理的票据有效期（建议 24 小时到 7 天）；使用 TLS 会话缓存减少重复握手的概率。

网络层面：使用 CDN 在边缘节点处理 TLS 握手，减少客户端到服务器的物理距离；部署 HTTP/2 或 HTTP/3 减少连接数量，从而减少 TLS 握手次数。

四、实践案例

4.1 案例一：TLS 握手延迟对页面加载的影响

一个电商网站从 HTTP 迁移到 HTTPS 后，页面加载时间增加了约 500ms。

问题诊断：

优化措施与效果：

4.2 案例二：OCSP Stapling 的性能提升

一个金融网站的用户报告 HTTPS 连接建立缓慢。

问题诊断：

优化措施与效果：

五、常见误区与注意事项

误区：HTTPS 比 HTTP 慢很多，应该避免使用。 现代 TLS 的性能开销已经非常小。TLS 1.3 的 1-RTT 握手、会话恢复、0-RTT 等特性大幅减少了延迟。此外，HTTP/2 和 HTTP/3 只在 HTTPS 上可用，它们的多路复用和头部压缩等特性带来的性能提升远超 TLS 的开销。

误区：RSA 密钥交换比 ECDHE 更快。 虽然 RSA 密钥交换不需要服务器执行 Diffie-Hellman 运算，但 RSA 2048 的加密运算实际上比 ECDHE X25519 的密钥交换更慢。而且 ECDHE 提供前向保密，安全性更高。TLS 1.3 已经彻底移除了 RSA 密钥交换。

误区：0-RTT 是安全的，可以用于所有请求。 TLS 1.3 的 0-RTT 数据存在重放攻击风险——攻击者可以截获 0-RTT 数据并重复发送。因此，0-RTT 只应用于幂等操作（如 GET 请求），不应用于非幂等操作（如 POST 支付请求）。

注意事项：证书链大小影响握手性能。 过长的证书链会增加握手数据量。应确保服务器发送的证书链完整但不冗余——包含叶证书和必要的中间证书，但不包含根证书（根证书已预装在客户端的信任存储中）。

注意事项：TLS 版本协商可能导致额外延迟。 如果服务器不支持 TLS 1.3，客户端可能需要降级到 TLS 1.2，增加握手延迟。应确保服务器和 CDN 都支持 TLS 1.3，并配置正确的版本优先级。

六、本章小结

本章全面介绍了 TLS 协议的工作原理、握手过程、加密体系以及对 Web 性能的影响。TLS 是 HTTPS 的安全基础，其握手过程是 HTTPS 连接建立中最大的延迟来源之一。

核心要点包括：TLS 1.2 需要 2 个 RTT 完成握手，TLS 1.3 优化为 1 个 RTT 并支持 0-RTT；TLS 使用非对称加密进行密钥交换、对称加密进行数据传输、哈希函数保证完整性；前向保密通过临时密钥交换确保历史通信的安全性；会话恢复机制（Session Ticket、PSK）可以显著减少回访用户的握手延迟；OCSP Stapling 消除了证书吊销检查的额外网络往返。

优化 TLS 性能的关键措施包括：升级到 TLS 1.3、使用 ECC 证书、启用 OCSP Stapling、配置会话恢复、使用 CDN 减少物理距离。这些优化可以将 TLS 握手延迟减少 50% 以上，显著提升 Web 应用的响应速度。

七、思考题与练习

详细描述 TLS 1.2 和 TLS 1.3 的握手过程，比较两者的 RTT 差异和安全性差异。

解释为什么 TLS 需要同时使用对称加密和非对称加密，以及各自在 TLS 中的具体作用。

什么是前向保密？为什么 TLS 1.3 强制要求前向保密？ECDHE 如何实现前向保密？

比较 Session ID、Session Ticket 和 TLS 1.3 PSK 三种会话恢复机制的工作原理和优缺点。

TLS 1.3 的 0-RTT 模式如何工作？它面临什么安全风险？如何缓解这些风险？

解释 OCSP Stapling 的工作原理，以及它如何改善 TLS 握手性能。

为一个高流量电商网站设计 TLS 优化方案，考虑证书选择、协议版本、会话恢复、CDN 部署等方面。

使用 OpenSSL 命令行工具或浏览器开发者工具分析一个网站的 TLS 配置，包括协议版本、加密套件、证书链和握手时间。