HTTPS 背后的密码学：TLS 协议是如何保护通信的

在网络上传输的数据需要经过路由器、交换机、运营商网络等大量中间节点。如果数据以明文传输，其中任何一个节点都可以读取、篡改甚至伪造通信内容。登录密码、支付信息、私人消息都可能因此泄露。

TLS（Transport Layer Security，传输层安全协议）是解决这一问题的核心协议。HTTPS 就是将 HTTP 运行在 TLS 之上，除此之外，邮件传输、即时通信、数据库连接、各类 API 调用也广泛使用 TLS 保护。

本文从安全通信需要解决的问题出发，介绍 TLS 所依赖的密码学基础、证书与信任体系、握手过程，以及 TLS 1.3 带来的主要改进。

一、安全通信要解决的三个问题

一个安全的通信信道，需要同时满足三项要求：

• 机密性：通信内容只有双方能够读懂，中间人即使截获了数据，也无法得知其内容；
• 完整性：通信内容在传输过程中没有被篡改，任何修改都能被检测出来；
• 身份认证：通信的对方确实是声称的那个人，而不是冒充者。

三者缺一不可。只有加密而没有认证，攻击者可以冒充服务器，与客户端建立一个"加密"的连接，再将数据转发给真正的服务器，这就是中间人攻击。只有加密而没有完整性保护，攻击者虽然读不懂内容，却可能通过翻转密文中的特定位来篡改明文。

TLS 通过组合多种密码学工具，同时实现这三项目标。

二、密码学基础

1. 对称加密

对称加密使用同一个密钥进行加密和解密。通信双方只要事先共享一个密钥，就可以用它加密数据，第三方没有密钥则无法解密。

对称加密的优点是速度快，现代处理器普遍提供了专门的硬件指令来加速常用的对称加密算法，每秒可以处理数 GB 的数据，适合加密大量的通信内容。目前 TLS 中常用的对称加密算法是 AES，以及在缺乏硬件加速的设备上表现更好的 ChaCha20。

对称加密的根本难题在于密钥分发：双方如何在一个不安全的信道上，安全地约定一个共享密钥？如果直接通过网络发送密钥，它同样会被截获。

2. 非对称加密

非对称加密使用一对密钥：公钥和私钥。公钥可以公开给任何人，私钥由持有者严格保密。用公钥加密的数据只能用对应的私钥解密，反之，用私钥生成的签名可以用公钥验证。

非对称加密巧妙地解决了密钥分发问题：服务器公开自己的公钥，客户端用它加密一个随机生成的对称密钥发给服务器，只有持有私钥的服务器才能解密。

但非对称加密的运算速度比对称加密慢数个数量级，不适合直接加密大量数据。因此，实际协议中采用混合加密：用非对称密码学协商出一个对称密钥，再用对称加密保护后续的全部通信。

常见的非对称算法包括 RSA，以及基于椭圆曲线的算法。椭圆曲线密码在相同安全强度下所需的密钥长度短得多，运算也更快，已成为现代 TLS 的主流选择。

3. 密钥交换

除了用公钥加密密钥这种方式，还有一种更巧妙的方法：Diffie-Hellman 密钥交换。

其核心思想可以用一个调色的比喻理解：双方先公开约定一种公共颜色；每人各自秘密选择一种私有颜色，与公共颜色混合后，把混合结果公开发送给对方；收到对方的混合颜色后，再加入自己的私有颜色。最终，双方得到的颜色完全相同，都是"公共颜色 + 甲的私有颜色 + 乙的私有颜色"。而窃听者只看到了公共颜色和两个混合结果，由于从混合色中分离出原色在计算上极其困难，窃听者无法得到最终的颜色。

在实际的密码学实现中，"混合颜色"对应的是在特定数学结构上的运算，例如有限域上的模幂运算或椭圆曲线上的点乘运算，其逆运算在计算上是不可行的。现代 TLS 普遍使用基于椭圆曲线的版本，简称 ECDHE。

4. 前向保密

Diffie-Hellman 密钥交换的一个重要优势是能够提供前向保密（Forward Secrecy）。

如果使用服务器的长期私钥直接加密会话密钥，那么一旦这个私钥在未来某天泄露，攻击者就可以解密此前截获并保存下来的所有历史通信。

而使用临时的 Diffie-Hellman 密钥交换时，每次连接双方都会生成新的临时密钥对，用完即丢弃。服务器的长期私钥只用于签名，证明自己的身份，不参与会话密钥的计算。即使长期私钥日后泄露，攻击者也无法还原过去的会话密钥。

ECDHE 中的"E"（Ephemeral，临时）指的正是这一点。

5. 哈希与消息认证

哈希函数能够将任意长度的数据映射为固定长度的摘要。安全的哈希函数具有两个关键性质：无法从摘要反推原始数据；难以找到两段不同的数据产生相同的摘要。常用的哈希函数包括 SHA-256 等。

单纯的哈希不足以保证完整性，因为攻击者可以在篡改数据后重新计算哈希值。消息认证码（MAC）在哈希计算中引入了一个只有通信双方知道的密钥，没有密钥就无法为篡改后的数据生成有效的认证码。

现代 TLS 使用认证加密（AEAD）模式，在一次运算中同时完成加密和完整性保护，例如 AES-GCM 和 ChaCha20-Poly1305。这避免了历史上因加密与认证组合方式不当而产生的多种漏洞。

6. 数字签名

数字签名用于证明数据的来源和完整性。签名者用私钥对数据的摘要进行运算，生成签名；任何人都可以用签名者的公钥验证签名是否有效。由于只有私钥持有者才能生成有效签名，验证通过即可确认数据确实来自该持有者，且未被修改。

三、证书与信任体系

非对称加密和密钥交换解决了密钥协商问题，但还剩下一个关键问题：客户端如何确认收到的公钥确实属于目标服务器，而不是中间人伪造的？

数字证书

数字证书将一个公钥与一个身份绑定在一起。证书中主要包含以下信息：

• 证书持有者的身份，例如域名；
• 持有者的公钥；
• 证书的有效期；
• 证书签发者的信息；
• 签发者对上述内容的数字签名。

证书由证书颁发机构（Certificate Authority，CA）签发。CA 在签发证书之前，会验证申请者确实控制着证书中声明的域名，例如要求申请者在该域名下放置特定内容，或在域名解析记录中添加指定的值。

信任链

操作系统和浏览器中预先内置了一组受信任的根证书。根 CA 的私钥通常离线保存，受到严格保护，一般不直接签发网站证书，而是签发中间证书，由中间 CA 签发最终的服务器证书。

客户端验证服务器证书时，沿着证书链逐级向上验证：

1. 验证服务器证书的签名是否由中间证书的公钥生成；
2. 验证中间证书的签名是否由上一级证书的公钥生成；
3. 直到到达一个内置于系统中的受信任根证书。

同时还需要检查：证书是否在有效期内，证书中的域名是否与正在访问的域名匹配，证书是否已被吊销。

只有整条链都验证通过，客户端才信任服务器提供的公钥。中间人即使伪造了一张证书，也无法获得受信任 CA 的签名，验证会失败。

证书吊销与透明度

如果服务器的私钥泄露，或证书被错误签发，就需要在有效期结束前将其吊销。传统方式是由 CA 发布吊销列表，或提供在线查询服务。但这些方式存在延迟、隐私和可用性方面的问题。目前较为常见的改进是由服务器主动获取 CA 对证书状态的签名响应，并在握手时附带发送给客户端，称为状态装订（Stapling）。

另一方面，为了防止 CA 被攻破或滥用而错误签发证书，业界建立了证书透明度机制：CA 签发的所有证书都必须记录到公开的、只能追加的日志中。域名所有者可以监控这些日志，及时发现针对自己域名的异常证书。主流浏览器要求证书必须包含已记录到透明度日志的证明，否则不予信任。

近年来，证书的有效期也在逐步缩短，配合自动化的证书签发和续期工具，降低了证书长期有效带来的风险。

四、TLS 1.2 握手过程

TLS 连接建立时，客户端和服务器需要通过握手协商协议版本、加密算法，验证服务器身份，并生成会话密钥。以使用 ECDHE 密钥交换的 TLS 1.2 为例，握手的主要步骤如下：

1. 客户端问候：客户端发送支持的 TLS 版本、支持的密码套件列表、一个随机数，以及其他扩展信息，例如要访问的域名；
2. 服务器问候：服务器选定协议版本和密码套件，并发送自己的随机数；
3. 服务器证书：服务器发送自己的证书链；
4. 服务器密钥交换：服务器生成临时的椭圆曲线密钥对，发送临时公钥，并用证书对应的私钥对其进行签名；
5. 服务器问候结束；
6. 客户端密钥交换：客户端验证证书链和签名，然后生成自己的临时密钥对，发送临时公钥；
7. 双方各自根据对方的临时公钥和自己的临时私钥，计算出相同的共享秘密，再结合两个随机数，派生出会话密钥；
8. 切换加密并发送结束消息：双方通知对方后续通信将使用协商好的密钥加密，并发送一条包含此前所有握手消息摘要的加密消息，用于确认握手过程未被篡改。

整个握手需要两个往返（2-RTT）才能开始传输应用数据。加上 TCP 本身的三次握手，建立一个 HTTPS 连接至少需要三个往返。在高延迟网络中，这会带来明显的等待时间。

握手消息完整性的意义

第 8 步中对握手消息的校验非常重要。握手最初的几条消息是明文传输的，如果没有这一步，中间人可以篡改客户端问候中的密码套件列表，删除强加密算法，只保留弱算法，迫使双方使用容易被破解的加密方式，这称为降级攻击。结束消息对整个握手过程进行了校验，任何篡改都会导致校验失败、连接终止。

五、TLS 1.3 的改进

TLS 1.3 于 2018 年正式发布，是对协议的一次大幅修订。它的设计原则可以概括为：删繁就简，默认安全，降低延迟。

1. 删除不安全的算法

TLS 1.2 支持大量的密码套件，其中包括许多已被证明存在弱点的算法和模式。历年来针对 TLS 的多种攻击，都利用了这些遗留选项。

TLS 1.3 进行了大刀阔斧的精简：

• 删除了基于 RSA 公钥加密的密钥交换方式，只保留提供前向保密的 Diffie-Hellman 类密钥交换；
• 删除了所有非 AEAD 的加密模式，只保留认证加密算法；
• 删除了已知不安全的哈希算法和加密算法；
• 删除了压缩、重新协商等容易引发漏洞的功能。

密码套件的数量从数百个减少到少数几个，前向保密成为强制要求，而非可选项。

2. 一次往返完成握手

TLS 1.3 将完整握手缩短到一个往返（1-RTT）。

关键的改变在于：客户端在第一条消息中，就直接猜测服务器会使用的密钥交换算法，并附上相应的临时公钥。由于可选的算法已经大幅减少，这种猜测在绝大多数情况下都是正确的。

服务器收到后，立即计算出共享秘密，在回复中发送自己的临时公钥，并且从这一刻起，后续所有握手消息都已经加密，包括服务器证书。客户端收到服务器的回复后，即可计算出密钥、验证证书，并立即开始发送应用数据。

如果客户端猜错了，服务器会告知其选择的算法，客户端重新发送，此时退化为两个往返，但这种情况很少发生。

3. 更多握手内容被加密

在 TLS 1.2 中，服务器证书以明文传输，网络观察者可以从中得知客户端访问的是哪个网站。TLS 1.3 将证书和大部分扩展信息都放在加密之后发送，增强了隐私保护。

不过，客户端问候中用于指明目标域名的扩展字段仍然是明文的，因为服务器需要据此选择正确的证书。为了解决这一问题，业界正在推进加密客户端问候（Encrypted Client Hello）机制，将这部分信息也加密传输。

4. 零往返恢复

对于此前已经建立过连接的客户端，TLS 1.3 支持零往返（0-RTT）恢复：客户端利用上次连接中保存的预共享密钥，在第一条握手消息中直接附带加密的应用数据，服务器无需等待握手完成即可处理请求。

0-RTT 显著降低了重复连接的延迟，但它有一个重要的安全限制：0-RTT 数据不具备防重放保护。攻击者可以截获这部分数据，然后重复发送给服务器。如果这些数据代表的是一笔转账请求，重放可能导致重复扣款。

因此，0-RTT 只应当用于幂等的请求，例如读取页面或查询数据，而不应用于会改变服务器状态的操作。服务器和应用需要明确区分哪些请求可以通过 0-RTT 处理。

TLS 1.2 与 TLS 1.3 的对比

六、TLS 与传输层的结合

传统的 HTTPS 运行在 TCP 之上，连接建立需要先完成 TCP 握手，再进行 TLS 握手。

新一代传输协议 QUIC 运行在 UDP 之上，并将 TLS 1.3 直接集成到传输层的握手中，传输连接的建立和加密密钥的协商在同一个往返中完成。对于已经访问过的服务器，还可以使用 0-RTT 直接发送数据。基于 QUIC 的 HTTP/3 因此在高延迟和移动网络环境中能够更快地建立连接。

此外，QUIC 不仅加密应用数据，还对大部分传输层控制信息进行加密，减少了中间网络设备可以观察和干预的内容。

七、工程实践中的注意事项

禁用旧版本协议。 SSL 3.0、TLS 1.0 和 TLS 1.1 都已被正式废弃，存在已知漏洞，服务端应当只启用 TLS 1.2 和 TLS 1.3。对于 TLS 1.2，应只启用提供前向保密和认证加密的密码套件。

实现证书自动续期。 证书过期是导致服务中断的常见原因之一。随着证书有效期越来越短，手动管理已经不现实，应当使用自动化工具完成证书的签发、续期和部署，并对证书的剩余有效期进行监控告警。

提供完整的证书链。 服务器需要发送服务器证书以及所有中间证书。缺少中间证书时，部分客户端会验证失败，而另一些客户端由于缓存了该中间证书可能正常工作，这类问题往往难以排查。

妥善保护私钥。 私钥应当设置严格的文件权限，避免出现在代码仓库、日志或镜像中。对于安全要求高的场景，可以使用硬件安全模块或云服务提供的密钥管理服务，使私钥无法被导出。

启用严格传输安全。 即使网站支持 HTTPS，用户首次输入域名时，浏览器可能仍会先尝试使用明文 HTTP 访问，这给了攻击者将连接劫持到明文协议的机会。通过 HTTP 严格传输安全（HSTS）策略，服务器可以告知浏览器在一定期限内只使用 HTTPS 访问该域名。

客户端不要关闭证书校验。 在开发和测试中，为了绕过自签名证书的错误，有时会关闭客户端的证书校验。如果这段代码进入生产环境，TLS 的身份认证将完全失效，连接对中间人攻击毫无防御能力。正确的做法是在测试环境中配置受信任的内部 CA。

关注后量子密码迁移。 大规模量子计算机一旦实现，现有的 RSA 和椭圆曲线密码将可能被破解。由于攻击者可以先截获并保存加密流量，日后再进行解密，需要长期保密的数据面临现实的风险。业界已经开始在 TLS 密钥交换中部署将传统算法与抗量子算法结合使用的混合方案，主流浏览器和部分服务端已默认启用。

结语

TLS 的设计体现了密码学工程的一个基本思路：没有单一的密码学工具能够解决所有问题，安全来自于多种工具的恰当组合。非对称密码学解决密钥协商和身份认证，对称加密高效地保护大量数据，哈希与认证加密确保完整性，证书体系将公钥与现实身份联系起来。

TLS 1.3 的演进也说明了另一个道理：协议的安全性不仅取决于它支持哪些强大的算法，也取决于它去掉了哪些不安全的选项。减少可配置的空间、让安全成为默认值，往往比提供更多选择更能保护实际部署中的系统。