HTTPS原理详解

HTTPS原理

HTTPS就是在HTTP基础上添加了一个传输层安全协议 TLS 。之前使用的是安全套接字层协议 SSL，因为安全性原因 SSL被废弃了。

目的是保证传输安全，接下来我会讲述一下怎么保证安全。主要是三个方面的保证。通过这三个方面可以保证安全性。

• 信息加密：HTTP 交互信息是被加密的，第三方就无法被窃取；

• 校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；

• 身份证书：证明淘宝是真的淘宝网；

在HTTP通信前，就会进行TLS握手，其流程如下：

中文翻译过来就是：

ClientHello（客户端问候）

• TLS Version：TLS协议版本（如TLS 1.2或1.3）

• Client Random：客户端随机数（32字节），会话密钥生成材料之一

• Cipher Suites：客户端支持的密码套件列表，按优先级排序

ServerHello（服务器问候）

• TLS Version：服务器选择的TLS版本

• Server Random：服务器随机数（32字节），会话密钥生成材料之二

• Cipher Suites (ECDHE_RSA)：服务器选定的密码套件

  • ECDHE：椭圆曲线迪菲-赫尔曼临时密钥交换

  • RSA：RSA签名算法用于身份认证

Certificate（证书）

• 服务器的X.509数字证书链，包含RSA公钥用于验证签名

ServerKeyExchange（服务器密钥交换）

• Named Curve：命名的椭圆曲线（如secp256r1、x25519）

• Pubkey：服务器的临时ECDH公钥

• Signature：对上述参数的RSA签名，证明密钥合法性

ServerHelloDone（服务器问候完成）

• 服务器表示握手信息发送完毕

ClientKeyExchange（客户端密钥交换）

• Pubkey：客户端的临时ECDH公钥

ChangeCipherSpec（变更密码规范）

• 通知对方从现在开始使用新协商的加密参数

Finished（完成）

• 加密的握手完整性验证消息

• 包含所有握手消息的HMAC摘要

Application Data（应用数据）

• 加密的HTTP请求/响应数据

这里有一个流程图：

语言描述一下，就是：

1. 先进行三次握手。

2. 客户端传递三个参数给服务器，分别是：

   1. 一个随机数C

   2. 客户端的TLS协议版本号

   3. 密码套件列表（也就是，所有的可选择加密函数）。

3. 客户端回复ACK报文，表示我收到了你传的三个参数。

4. 服务器回复hello报文，里面也包含3个参数：

   1. 一个新的随机数S

   2. 协商后的TLS版本号

   3. 使用的加密函数，也就是密码套件（RSA）。

5. 服务器回复服务器使用的证书。

6. 服务器表示我想对你说的结束了。

7. 客户端回复ACK报文，表示我接收到了你的消息。

8. 客户端产生一个新的随机数 (pre-master)，使用服务器的RSA公钥加密，然后通过Change Cipher Key Exchange传递到服务端。服务端用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。（这里是非对称加密，确保安全性）。

现在，双方有三个随机数 C、S、pre-master。

1. 双方使用这三个数生成对话密钥（对称密钥）。客户端发送Change Cipher Spec告诉服务器使用加密方式发送信息（这里是对称加密，加快数据传输效率）。

2. 客户端发Encrypted Handshake Message（Finishd），作用是把之前所有发送的数据做个摘要。

3. 服务器回复ACK表示收到了。

4. 服务器使用加密回复。服务器发送Change Cipher Spec。

5. 服务器也发Finishd，也是摘要信息。

6. 客户端回复ACK报文，表示收到了。

7. 之后客户端发起请求就会使用会话密钥加密报文。

8. 服务端同样使用会话密钥加密报文进行响应。

---

1. TCP三次握手（建立TCP连接）。

2. TLS握手开始：

   • a. 客户端→服务器：ClientHello

     • 支持的TLS版本

     • 客户端随机数(C)

     • 支持的密码套件列表

   • b. 服务器→客户端：ServerHello

     • 选择的TLS版本

     • 服务器随机数(S)

     • 选择的密码套件（如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384）

   • c. 服务器→客户端：Certificate（服务器证书链）

   • d. 服务器→客户端：ServerKeyExchange（如果是ECDHE）

   • e. 服务器→客户端：ServerHelloDone

   • f. 客户端验证服务器证书

   • g. 客户端→服务器：ClientKeyExchange

     • 加密的pre-master（RSA方式）或客户端ECDHE公钥

   • h. 客户端→服务器：ChangeCipherSpec（通知开始加密）

   • i. 客户端→服务器：Finished（加密的握手摘要）

   • j. 服务器→客户端：ChangeCipherSpec

   • k. 服务器→客户端：Finished

3. 双方基于C、S、pre-master生成相同的会话密钥。

4. 开始加密的HTTP通信。

---

值得注意的安全特性：

1. 前向保密（Forward Secrecy）

你描述的流程是RSA密钥交换 ，这不支持前向保密 。现代网站更多使用ECDHE_RSA：

• RSA密钥交换：服务器私钥泄露 → 所有历史会话可被解密。

• ECDHE密钥交换：每次会话生成临时密钥，支持前向保密。

2. Finished消息的重要性

Finished消息不只是"做个摘要"，它是：

• 验证握手过程是否被篡改。

• 确认双方计算出的密钥一致。

• 使用刚刚协商的密钥加密，验证加密通道可用。

3. ChangeCipherSpec的作用

这是一个简单的协议（只有1字节），作用是：

• 通知对方：从下一条消息开始使用新协商的加密参数。

• 这是一个明确的分界点。

---

常见混淆点澄清：

Q: 为什么需要这么多步骤？

A: 每步都有特定安全目的：

• Hello消息：协商参数，交换随机数。

• Certificate：身份认证。

• KeyExchange：安全传输密钥材料。

• ChangeCipherSpec：明确切换加密模式。

• Finished：验证握手完整性。

Q: 对称加密的密钥怎么保证安全？

A: 密钥协商过程保证了：

1. 密钥材料通过非对称加密安全传输。

2. 双方独立计算相同的会话密钥。

3. 密钥只在内存中存在，不通过网络传输。

Q: 为什么不用非对称加密所有数据？

A: 性能原因：

• 非对称加密：计算复杂，速度慢（RSA加密比对称加密慢1000倍以上）。

• 对称加密：速度快，适合大量数据传输。

核心补充：数字证书如何验证身份？

在TLS握手的 第3步（Certificate），服务器发送其数字证书。客户端的验证过程是建立信任的关键，它确保你正在连接的"淘宝网"确实是真正的淘宝网，而非一个中间人伪装的服务器。

1. 数字证书里有什么？

一份标准的数字证书通常包含以下核心信息：

• 持有者信息：网站域名、组织名称等。

• 持有者公钥：服务器用于密钥交换或签名的公钥。

• 颁发者信息：签发此证书的证书认证机构（CA）。

• 有效期：证书的生效和过期时间。

• CA的数字签名：这是证书防伪的核心，由CA用自己的私钥对证书所有信息的摘要进行加密生成。

2. 证书的"信任链"

服务器的证书并非凭空被信任，而是依赖于一个由根证书、中间证书构成的 "信任链"。

• 根CA ：位于信任链顶端的、极少数极度权威的机构（如DigiCert、GlobalSign）。其根证书已预先内置在操作系统或浏览器中，是整个信任体系的基石。

• 中间CA：由根CA授权签发的下级CA。实际签发服务器证书的通常是这些中间CA。这形成了"根CA -> 中间CA -> 服务器证书"的信任链。

• 作用：分层管理提高了安全性和灵活性。即使某个中间CA的私钥泄露，只需吊销该中间证书，无需动摇整个根信任体系。

3. 客户端如何验证证书？（核心流程）

当客户端收到服务器证书后，会执行一套严谨的验证流程，如下图所示：

证书签发与验证流程示意图

证书签名过程（由CA完成）：

1. 信息打包与摘要 ：CA将证书持有者的公钥、身份信息、有效期等所有明文内容，使用指定的哈希算法（如SHA-256）进行计算，得到一个唯一的摘要值H1。

2. CA私钥签名 ：CA使用自己的私钥 对摘要值H1进行加密，生成数字签名（Certificate Signature）。

3. 合成证书 ：将这个数字签名附加到原始证书信息上，最终形成我们看到的数字证书。

客户端验证过程：

1. 计算摘要 ：客户端拿到证书后，使用证书里声明的同一个哈希算法，对证书的明文部分 （公钥、身份信息等）进行独立计算，得到摘要值H2。

2. 解密签名 ：客户端需要验证签名。它会从自己信任的CA库（预置在系统中）里，找到签发该证书的CA的公钥 ，并用这个公钥去解密证书附带的数字签名 ，得到被解密出来的原始摘要值H1。

3. 比对验证 ：客户端比较自己计算出的 H2 和从签名中解密出的 H1。

   • 如果 H1 == H2 ：说明证书信息在签发后未被篡改，且确由该CA签发，证书有效。

   • 如果不相等：说明证书内容被篡改或签名无效，客户端将立即终止连接，并发出安全警告。

4. 为什么这个过程能防止中间人攻击？

中间人即使截获了通信，他也无法伪造一个有效的证书：

• 他无法篡改内容 ：如果中间人修改了证书中的公钥（换成自己的），那么客户端重新计算的摘要值 H2 就会改变，与CA签名解密的 H1 不匹配，验证失败。

• 他无法伪造签名 ：要生成一个能被验证通过的签名，必须使用CA的私钥。而CA的私钥受到严格保护，中间人无法获取。用其他任何密钥生成的签名，都无法被客户端用CA的公钥正确解密和验证。

信任链验证示意图

此图说明了客户端会沿着"服务器证书 -> 中间CA证书 -> 根CA证书"的链条逐级验证签名，直至找到操作系统内置的、受信任的根证书，整个信任链才算建立完成。