HTTPS 的核心—SSL/TLS 协议

HTTPS连接 == tcp三次握手协议+SSL/TLS四次握手协议

基于 RSA 算法的 TLS 握手详细流程

第一次握手：ClientHello 首先，由客户端向服务器发起加密通信请求，也就是clientHello请求。在这一步，客户端主要向服务器发送以下信息:

• 客户端支持的 TLS 协议版本，如 TLS 1.2 版本。

• 客户端生产的随机数( client Random)，后面用于生成「会话秘钥」条件之一。

• 客户端支持的密码套件列表，如 RSA 加密算法。

第二次握手：SeverHello 服务器收到客户端请求后，向客户端发出响应，也就是severHello 。服务器回应的内容有如下内容!

• 确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。

• 服务器生产的随机数( server Random)，也是后面用于生产「会话秘钥」条件之一。

  确认的密码套件列表，如 RSA 加密算法。

• 发送服务器的数字证书（细节补充↓）

CA 对证书签名（服务端证书的生成）—第二次握手的数字证书细节补充部分

1. 服务端生成密钥对

   • 服务端首先生成自己的 公钥（Public Key） 和 私钥（Private Key）。

   • 私钥自己保存，公钥放入证书请求文件（CSR）。

2. CA 收到 CSR 后，生成数字签名

   • CA 会对证书的 所有关键信息（如域名、公钥、有效期等）进行 Hash 计算（如 SHA-256），得到 HashA。

   • 然后 CA 用 自己的私钥（CA Private Key） 加密这个 HashA，生成 数字签名（Digital Signature）。

   • 最后，CA 把数字签名附加到证书里，颁发给网站。

   ✅ 关键点：

   • Hash 的对象：证书的完整内容（包括公钥、域名、有效期等）。

   • 数字签名 = CA 私钥加密(HashA)。

   • 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

---

第三次握手：证书验证（非对称加密 + 数字签名） + 对称加密

图源 ：小林coding

---

① 客户端验证证书（浏览器如何信任证书）

1.数字签名验证（密码学层面）

1. 客户端获取证书

   • 当访问 https://example.com 时，服务端会返回它的证书（包含公钥 + CA 的数字签名）。

2. 客户端计算证书的 HashB

   • 客户端用 相同的 Hash 算法（如 SHA-256）对证书的 原始内容（不包括签名部分）计算哈希，得到 HashB。

3. 客户端用 CA 的公钥解密签名

   • 客户端操作系统/浏览器内置了 受信任的 CA 公钥（CA Public Key）。

   • 用这个公钥解密证书中的 数字签名，得到 HashC（即原始 HashA）。

4. 对比 HashB 和 HashC

   • 如果 HashB == HashC，说明：

     • 证书未被篡改（完整性）。

     • 证书确实是由该 CA 颁发的（真实性）。

   • 如果不一致，浏览器会警告 “证书不可信”。

2.证书内容检查（逻辑层面）

即使证书通过，还需检查以下内容：

1. 域名一致性：

   • 证书中的 Common Name 或 Subject Alternative Names (SANs) 必须与当前访问的域名匹配。

   • 例如：访问 https://example.com，但证书是 *.google.com → 拒绝连接。

2. 有效期检查：

   • 当前时间必须在证书的 Not Before 和 Not After 之间。

   • 过期证书即使签名有效也会被拒绝。

3. CA 可信性：

   • 签发证书的 CA 必须存在于客户端的信任存储（如操作系统内置的根证书列表）。

   • 自签名证书或私有 CA 证书需手动导入信任链。

4. 证书吊销状态（可选但重要）：

   • 通过 CRL（证书吊销列表） 或 OCSP（在线证书状态协议） 检查证书是否被 CA 主动吊销。

②生成对称加密的会话秘钥

证书验证通过后，客户端和服务端会切换到 对称加密（如 AES）来加密实际数据传输。这是为了性能优化（对称加密比非对称加密快 1000 倍以上）。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息:

• 发送多个消息

  （通常合并为一个 TCP 包）：

  1. ClientKeyExchange：包含用服务端公钥加密的 Pre-Master Secret。

  2. ChangeCipherSpec：通知服务端后续消息使用对称密钥加密。

  3. Finished：用会话密钥加密的握手摘要，验证密钥一致性。

• 作用：交换密钥并切换到对称加密。

• 客户端通过三个随机数（Client Random、Server Random、Pre-Master Secret）和协商的加密算法生成最终的「会话密钥」。

第四次握手：服务端确认 + 对称加密

客户端通过三个随机数（Client Random、Server Random、Pre-Master Secret）和协商的加密算法（第一、第二次握手确定的）生成最终的「会话密钥」。

然后，向客户端发送最后的信息：

• 发送 多个消息（通常合并为一个 TCP 包）：

  • ChangeCipherSpec：通知客户端服务端已切换到对称密钥加密。

  • Finished：用会话密钥加密的握手摘要，确认密钥正确。

• 作用：完成双向认证，确保双方密钥一致。

---

关键问题解答

Q1: Hash 的对象是什么 || 数字证书里面有什么 ？

图源：小林coding

✅ 证书的完整内容，包括：

• 域名（Common Name）

• 服务器公钥（Subject Public Key）

• 颁发者（Issuer）

• 有效期（Valid From/To）

• 扩展信息（如 SANs）

• 数字签名（Certificate Signature）

数字证书主要由以下三大部分组成：

1. 公钥：用于加密数据或验证数字签名，是公开的部分，与持有者的私钥形成一对。

2. 信息：包括证书持有者的信息（如名称、组织等）和颁发者的信息、有效期、序列号等元数据。

3. 数字签名：由证书颁发机构使用其私钥对证书信息进行加密生成，用于验证证书的完整性和真实性。

Q2: 为什么需要解密数字签名？

因为数字签名是 CA 用私钥加密的 HashA，只有用 CA 的公钥解密才能证明：

1. 证书确实来自该 CA（真实性）。

2. 证书内容未被篡改（完整性）。

Q3: 为什么对比 HashB 和 HashC？

• 如果两者一致，说明证书内容与 CA 签发时完全一致。

• 如果不一致，可能证书被中间人篡改（如替换了公钥）。

Q4: 3个随机数怎么保证安全？

1. RSA密钥交换：

   • 安全性完全依赖第三个**Pre-Master Secret**的保密性。

   • Client/Server Random主要提供会话唯一性。

2. ECDHE密钥交换：

   • 临时密钥对实现前向保密。

   • 三个随机数共同参与密钥生成，缺一不可。

Q5: 既然私钥泄露了结合明文传输的两个随机数，之前的所有会话密钥就会被破解，那前两个随机数的意义是什么？

在 RSA 密钥交换中，由于 Pre-Master Secret 的传输依赖于服务器私钥，两个随机数的作用确实受到限制。只有在支持前向保密的密钥交换算法（如 DHE 或 ECDHE）中，两个随机数的价值才能得到更充分的体现。

(1) 提高密钥生成的鲁棒性

• 引入多个随机源可以减少单一随机数生成器出现问题的风险。例如，如果 Pre-Master Secret 的随机性不足，Client Random 和 Server Random 可以部分弥补这一缺陷。

(2) 为未来协议改进提供灵活性（重点）

• TLS 协议的设计具有一定的通用性，两个随机数的存在为未来的密钥协商算法（如 DHE 或 ECDHE）提供了兼容性支持。

• 在现代密钥交换算法（如 ECDHE）中，Pre-Master Secret 是通过临时密钥对协商生成的，两个随机数仍然参与最终的会话密钥生成，进一步增强了安全性。

(3) 防止静态密钥问题

• 如果没有随机数，每次握手可能会生成相同的会话密钥，这会导致严重的安全隐患。随机数的引入确保了即使在相同的网络环境下，每次握手都会生成不同的会话密钥。

Q6: 为什么HTTPS需要混合使用对称和非对称加密？

1. 非对称加密（RSA/ECC）：

   • 仅用于身份认证（证书验证）和密钥交换（传递Pre-Master Secret）。

   • 计算开销大（RSA加密比AES慢1000倍），不适合加密大量数据。

2. 对称加密（AES）：

   • 会话密钥加密实际数据传输，效率高。

   • 依赖非对称加密安全传递密钥。

Q7: 什么是前向保密（PFS）？为什么RSA密钥交换无法实现？

• 前向保密：即使长期私钥泄露，历史会话也无法解密。

• RSA的缺陷：

  • Pre-Master Secret用服务器公钥加密，私钥泄露可解密所有历史记录。

• 解决方案：

  • 使用ECDHE算法：每次会话生成临时密钥对，握手后丢弃私钥。