HTTPS 与 TLS 握手详解

HTTPS 的全称是 HTTP Secure，也常被称为 HTTP over SSL或 HTTP over TLS。它的核心定义非常简单：

HTTPS 不是一个新的传输协议，它只是在 HTTP 和 TCP 之间插入了一个 TLS 层：

数据流是：HTTP 报文 → 交给 TLS 加密 → 再交给 TCP 传输。反过来，接收时：TCP 收到数据 → TLS 解密 → 还原为 HTTP 报文。

SSL（Secure Socket Layer，安全套接层）是 Netscape 公司在 1990 年代发明的加密协议。后来标准化为 TLS（Transport Layer Security，传输层安全）。

HTTPS 的设计面临一个两难问题：

HTTPS 的解法是取两者之长：

想象你要和远方的朋友安全通信：

保险箱（非对称加密）只用来传钥匙，真正的货物（HTTP 报文）用普通锁（对称加密）来保护。保险箱虽安全但笨重，普通锁虽简单但轻便。

HTTPS 通信分为两个阶段，不要混淆：

发送是加密下行，接收是解密上行，路径完全对称

在发送第一条 HTTP 报文之前，客户端和服务器必须先完成 TLS 握手。以下描述的是 TLS 1.2 的 RSA 密钥交换模式，这也是目前最广泛部署的握手流程。整个过程可以浓缩为四句话：

客户端主动发起握手，发送一个 Client Hello消息。它虽然可以被看作"一个字节的数据"，但实际上携带了丰富的协商信息：

• 支持的 TLS 版本列表：比如 TLS 1.2、TLS 1.3
• 可选的对称加密算法（Cipher Suites）：比如 AES-GCM、ChaCha20-Poly1305
• 可选的非对称加密算法：比如 RSA、ECDHE
• 可选的哈希算法：比如 SHA-256、SHA-384
• 客户端随机数（Client Random）：一个随机生成的、不容易被猜到的随机数

服务器收到 Client Hello 后，做出选择并回应 Server Hello：

• 选定的 TLS 版本：从客户端列表里挑一个双方都支持的最高版本
• 选定的加密套件（Cipher Suite）：从客户端列表里挑一个最优的
• 服务器随机数（Server Random）：服务端也生成一个随机数

到这一步，客户端和服务端都拥有了相同的 TLS 版本、相同的加密套件、以及两个随机数（客户端随机数 + 服务器随机数）。

Server Hello 之后，服务器立即发送自己的证书（Certificate）。证书的核心作用是：

证书中的关键信息包括：

• 服务器公钥（最核心）
• 服务器主机名 / 域名（如 good.com）
• 证书签发机构（CA）信息
• 证书有效期（起止时间）
• 数字签名（CA 用自己的私钥对证书内容的哈希值做非对称加密的结果）

客户端收到证书后，需要做两重验证：

1. 验证证书签名链：确认这确实是 CA 签发的证书，不是伪造的
2. 验证主机名：确认证书上的域名和自己正在访问的域名一致

验证通过后，客户端用服务器公钥加密一个Pre-Master Secret（客户端生成的第三个随机数），发送给服务器。

以上 8 步是TLS 1.2（RSA 密钥交换模式）的完整流程。TLS 1.3（2018 年发布，RFC 8446）对此做了大幅简化，核心变化如下：

TLS 1.3 简化后的握手流程：

服务器证书上的签名（Signature）是这样生成的：CA 用自己的私钥对服务器证书内容的哈希值做一次非对称加密，得到密文——这就是签名。验证时反过来：

验证时：

但客户端怎么拿到 CA 的公钥来验证签名呢？这引出了证书链：

验证链路：用根 CA 公钥 → 验证中间 CA 的签名 → 得到中间 CA 公钥 → 验证服务器证书签名 → 确认服务器公钥合法。

为什么不需要无限递归？因为根证书是操作系统/浏览器出厂时预置的，被认为是无条件可信的。这些根证书由全球公认的 CA 机构持有（如 DigiCert、Let's Encrypt、GlobalSign 等）。

即使证书的签名链验证通过，仍然可能有危险。考虑这个场景：

你本想去 good.com，但请求被 bad.com的攻击者拦截。攻击者拿出自己的合法证书（由正规 CA 签发，确实属于 bad.com）给你验证。你验证证书签名——完全通过！因为证书本身确实是合法的。

所以客户端验证的第二步是检查主机名：证书里包含了服务器的主机名和域名。客户端会比对证书上的域名和自己正在访问的域名是否一致。如果访问 good.com但证书上写的是 bad.com，浏览器就会报"证书不匹配"的警告。

三个随机数共同参与生成 Master Secret，再由 Master Secret 派生出最终的对称密钥。

核心问题：如果只用 Pre-Master Secret 一个随机数来生成密钥，会怎样？

假设只用一个随机数生成密钥，那么相同的随机数 ⇒ 相同的密钥。这就引出了重放攻击：

三个随机数的防御逻辑：

• Client Random 和 Server Random 的作用：确保每次握手的密钥都不同。即使 Pre-Master Secret 碰巧相同，只要 Client Random 或 Server Random 不同，最终的密钥就不同
• 每次 TLS 握手生成的 Client Random 和 Server Random 都是全新的，所以每次会话的对称密钥也是全新的
• 攻击者重放旧的密文，服务器用当前会话的密钥去解密 → 解密失败（密钥不匹配）→ 丢弃

三个随机数生成了 Master Secret，而 Master Secret 又通过密钥派生函数（PRF）进一步生成四把密钥：

如果客户端和服务器用同一把密钥加密，会存在一个很损的攻击方式——反射攻击（Reflection Attack）：

双向不同密钥的防御逻辑：

• 客户端用客户端加密密钥加密数据发给服务器
• 服务器用服务端加密密钥加密数据发给客户端
• 攻击者把客户端的密文扔回给客户端 → 客户端用服务端加密密钥解密 → 解密失败（因为这条密文是用客户端加密密钥加密的，不是服务端加密密钥）

MAC（Message Authentication Code，消息认证码）和 HMAC（Hash-based Message Authentication Code，基于哈希的消息认证码）是 TLS 完整性保护的核心机制。

TLS 的每条加密消息都附带一个 HMAC 校验值：

密文和 HMAC 标签一起发送。接收方先用加密密钥解密，再用 MAC 密钥验证 HMAC——双重保障：别人看不到（加密），别人改不了（HMAC）。

TLS 握手只在连接建立时做一次。之后的 HTTP 请求/响应都直接用对称密钥加密，TLS 层变成透明的加解密管道。如果开启了 TLS Session Resumption（会话恢复），后续连接甚至可以跳过完整握手，直接恢复之前的密钥。