HTTPS

简单来说，HTTPS 建立过程就是客户端（浏览器）和服务器通过“非对称加密”协商出一个“对称加密密钥”的过程。

建立流程

1. 客户端发起请求 (Client Hello)

浏览器向服务器发送：“你好，我支持这些加密套件（Cipher Suites）、TLS 版本，这是我生成的随机数 Client Random。”

2. 服务器响应 (Server Hello)

服务器回复：“收到，我确认使用这个 TLS 版本，这是我选定的加密套件，这是我生成的随机数 Server Random。”

3. 服务器发送证书 (Certificate)

服务器将它的 SSL 证书发给浏览器。

如果此时证书过期、域名不匹配或 CA 机构不受信任，浏览器就会抛出 ERR_CERT_AUTHORITY_INVALID 等错误，阻止连接。

4. 浏览器验证证书

浏览器会对证书进行“审计”：

• 证书是否过期？
• 域名是否匹配？
• 签发机构（CA）是否在内置的信任列表里？
• 使用内置的 CA 公钥验证证书的签名是否真实。

5. 客户端密钥交换 (Key Exchange)

验证通过后，浏览器生成一个新的随机数 Pre-master secret。

• 浏览器用服务器发来的公钥对 Pre-master secret 进行加密。
• 发送给服务器。

6. 服务器解密

服务器收到加密后的 Pre-master secret，用自己的私钥解密，得到原始数值。

7. 生成会话密钥 (Session Key)

现在，浏览器和服务器手里都有了三个原始参数：Client Random、Server Random、Pre-master secret。 双方通过相同的算法，利用这三个参数生成最终的 会话密钥（Session Key）。

8. 加密通信开始

双方发送一条“握手结束”的消息，之后的所有 HTTP 数据传输都使用这个 会话密钥 进行对称加密（因为对称加密速度快，适合大量数据传输）。

• 非对称加密（公钥/私钥）只用于建立连接时的密钥交换，因为它是计算密集型的，很慢。
• 对称加密（会话密钥）用于后续的数据传输，因为效率高。

Q&A

既然服务器公钥是公开的，中间人确实可以拦截浏览器发出的密文，自己生成一个新的 Pre-master secret，用同样的公钥加密后发给服务器。

---

中间人虽然能改，但他拿不到“结果”。假设中间人拦截了浏览器发给服务器的密文 A，替换成了自己伪造的密文 B。

• 服务器端： 会用自己的私钥解开 B，得到中间人伪造的 Pre-master secret。
• 结果： 此时，服务器和中间人确实拥有了相同的密钥，但是浏览器没有！
• 后果： 浏览器还在等着协议定义的“握手验证”消息。由于浏览器和服务器计算出的会话密钥（Session Key）不一致，后续的测试加密消息（Finished Message）将无法解密，握手会立即失败，连接断开。

结论： 中间人如果只是单纯修改密文，他只能破坏通信，而不能“窃听”或“冒充”，因为他无法让浏览器也用他的密钥。

因此中间人攻击是通过伪造公钥，让发送方使用伪造的公钥进行加密，然后篡改数据再使用正确的公钥加密篡改信息，让服务器收到错误的信息。而如果公钥身份确认，那么中间人攻击就不再存在。