深入浅出：HTTPS 是如何保证我们通信安全的？

2025-06-21

嗨，大家好！今天咱们来聊聊那个我们每天都在用，但可能不太了解的“小锁头”——HTTPS。我们知道，HTTPS 比 HTTP 多了个 S，代表 Secure (安全)，它能保护我们在网络上的通信不被窃听和篡改。但它是怎么做到的呢？

你可能听说过 HTTPS 是用非对称加密，但其实，它巧妙地结合了对称加密和非对称加密两种技术，并通过数字证书和数字签名来确保通信双方的身份和数据的完整性。

HTTPS 的整个工作流程可以分为两个主要阶段：证书验证 和 数据传输。

证书验证阶段 (非对称加密的舞台)：
1. 浏览器发起 HTTPS 请求： 你在浏览器输入 https://example.com。
2. 服务端返回 HTTPS 证书： 服务器收到请求后，会把它自己的“身份证”（数字证书）发给浏览器。
3. 客户端验证证书： 浏览器检查这个“身份证”是不是真的、有没有过期、是不是发给这个网站的。如果“身份证”是假的或有问题的，浏览器就会弹出一个警告。
数据传输阶段 (对称加密的舞台)：
1. 生成随机数： 证书验证通过后，浏览器会在本地生成一个随机数（你可以把它想象成这次对话的“临时密码”）。
2. 用公钥加密随机数： 浏览器用服务器证书里的公钥，把这个“临时密码”加密。
3. 传输加密后的随机数： 浏览器把加密后的“临时密码”发给服务器。
4. 用私钥解密随机数： 服务器用自己的私钥解密，得到原始的“临时密码”。
5. 构造对称加密密钥： 现在，浏览器和服务器都有了同一个“临时密码”。它们会用这个“临时密码”作为基础，通过一个相同的算法，生成一个对称加密的密钥（Session Key）。
6. 加密通信： 之后的所有 HTTP 数据传输，都用这个对称加密密钥进行加密和解密。

效率问题： 非对称加密的计算速度非常慢，如果用它来加密我们浏览网页时的大量数据，那网页打开速度会慢得无法忍受。
对称加密则非常快，适合对大量数据进行加解密。
所以，HTTPS 的设计思路是：用非对称加密这个“慢但安全”的工具，来安全地协商和传递对称加密这个“快但不易传递”的密钥。 它们是“取长补短”的完美搭档。

为了防止“中间人攻击”。
什么是中间人攻击？ 想象一下：
1. 浏览器请求服务器，服务器把公钥 A 发给浏览器。
2. 一个“中间人”（黑客）截获了这个公钥 A，然后把它换成了自己的公钥 B（黑客有公钥 B 对应的私钥 B’）。
3. 浏览器不知道公钥被换了，用黑客的公钥 B 加密了“临时密码”，发给服务器。
4. 黑客截获后，用自己的私钥 B’ 解密，就得到了“临时密码”。然后，它再用服务器的公钥 A 把“临时密码”加密，发给服务器。
5. 服务器用自己的私钥 A’ 解密，也得到了“临时密码”。
- 结果： 浏览器和服务器都不知道中间有鬼，但黑客已经拿到了你们这次对话的“临时密码”，可以窃听和篡改所有信息。
数字证书的作用： 数字证书就像一个权威机构（CA - Certificate Authority）颁发的“带公章的身份证”。它把网站的域名和公钥绑定在一起，并用 CA 自己的私钥进行数字签名。

获取证书： 浏览器拿到服务器发来的数字证书，里面有网站的明文信息 T（包括域名、公钥等）和数字签名 S。
用 CA 公钥解密签名： 浏览器会在自己的系统里找这个 CA 机构的公钥（操作系统和浏览器会预装很多受信任的根 CA 证书）。用这个公钥解密数字签名 S，得到一个解密后的哈希值 S'。
计算明文哈希： 浏览器用证书里指定的哈希算法（比如 SHA-256）对明文信息 T 进行哈希计算，得到另一个哈希值 T'。
比较哈希值： 比较 S' 和 T' 是否相等。
- 如果相等： 说明证书是可信的，没有被篡改。因为只有 CA 机构的私钥才能生成正确的签名，而中间人没有这个私钥。
- 如果不相等： 说明证书被篡改了，浏览器会发出警告。
域名校验： 浏览器还会检查证书里的域名是否与当前访问的域名一致，防止“证书掉包”。

性能： 证书的明文信息可能很长，非对称加密很慢。先对明文进行哈希，得到一个固定长度的哈希值（摘要），然后再对这个短得多的哈希值进行加密，效率会高很多。
安全： 防止某些特定的攻击方式（如选择密文攻击），只对哈希值签名，而不是对原文签名，可以减少暴露的信息，更安全。

这就是信任链（Trust Chain）。操作系统和浏览器会预装一些最顶级的、全球公认的**根证书颁发机构（Root CA）**的证书。这些根证书是绝对信任的。
一个网站的证书可能是由一个中间 CA 颁发的，而这个中间 CA 的证书又是由另一个更高级的 CA 颁发的，最终可以追溯到某个受信任的根 CA。浏览器会沿着这条信任链逐级验证，直到找到一个它认识的根 CA。

不需要。 每次请求都重新握手、传输密钥，太耗时了。
HTTPS 使用**会话复用（Session Resumption）**机制。
Session ID： 在第一次 TLS 握手成功后，服务器会为这次会话生成一个 Session ID 并发给浏览器。浏览器会缓存这个 Session ID 和对应的对称加密密钥。
Session Ticket： 更现代的方式。服务器将加密的会话状态（Session Ticket）发给浏览器，浏览器下次请求时带上这个 Ticket，服务器解密后就能恢复会话，无需完整握手。
效果： 之后浏览器再次访问该网站时，可以直接带上 Session ID 或 Session Ticket，如果服务器端还保留着这个会话，就可以跳过复杂的握手过程，直接用之前协商好的密钥进行通信，大大提高了效率。

会被抓包，但内容是加密的。

HTTPS 只能防止用户在不知情的情况下，通信被中间人窃听。
如果用户主动授信，是可以构建“中间人”网络来抓包和解密的。
原理： 代理软件（如 Charles, Fiddler）会让用户在设备上安装一个它自己的 CA 根证书。当浏览器请求 HTTPS 网站时，代理软件会先伪装成服务器，用它自己的证书（由它自己签发）和浏览器进行握手，这样它就能拿到浏览器生成的对称加密密钥。然后，代理软件再用真实的服务器证书和服务器进行握手。这样，它就成了合法的“中间人”，可以解密和查看所有通信内容。

总结：

HTTPS 通过非对称加密解决了对称加密密钥的安全传输问题，通过数字证书和信任链解决了服务器身份验证和公钥合法性问题，最终使用高效的对称加密来保护实际的数据传输。这一套精妙的组合拳，构成了我们现代网络安全的基础。