HTTPS 的核心—SSL/TLS 协议

HTTPS通信的完整建立顺序严格遵循以下三步：

1. 先完成TCP三次握手 (建立可靠的传输层连接，能不能传输和接受？)

2. 在完成TLS握手 (在传输层之上建立安全层，能不能安全的传输？)

3. 发送HTTPS请求/响应 (在安全通道中进行HTTP通信)

是整个机制最巧妙的地方：

1. “商量用什么锁”（协商对称加密算法） -> 可以公开

2. “秘密传递造钥匙的配方”（用非对称加密安全交换 Pre-Master Secret) -> 这是安全的核心

3. “双方各自造出同一把钥匙”（用三个随机数生成会话密钥） -> 本地完成，无需传输

4. “以后就用这把钥匙和商量好的锁来通信”（切换至对称加密）-> 高效且安全

基于 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 主动吊销。

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

证书验证通过后，客户端开始执行密钥交换流程，目标是让双方安全地协商出同一个会话密钥（Session Key），为后续高效的对称加密通信做准备。

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

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

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

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

1. 生成并加密 Pre-Master Secret：

   • 客户端生成第三个随机数，称为 预主密钥（Pre-Master Secret）。

   • 客户端从服务器证书中取出服务器的公钥，并用该公钥加密 Pre-Master Secret。

   • 客户端将加密后的结果通过 ClientKeyExchange 消息发送给服务器。

2. 生成主密钥与会话密钥：

   • 此时，客户端已经拥有了三个随机数：Client Random、Server Random 和 Pre-Master Secret。

   • 客户端使用双方协商的密钥派生算法，基于这三个随机数，生成用于对称加密的实际会话密钥。

3. 准备切换密码套件：

   • 客户端发送 ChangeCipherSpec 消息。这是一个简单的信号，通知服务器：“我这边已经准备好，此后所有发出的消息都将使用刚刚生成的会话密钥进行加密”。

4. 验证握手完整性：

   • 客户端计算至今为止所有握手消息的摘要，并使用刚刚生成的会话密钥进行加密，形成 Finished 消息发送给服务器。

   • 此消息的作用是：让服务器验证整个握手过程是否被篡改，以及双方生成的密钥是否一致。

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

1. 服务器获得密钥：

   • 服务器收到 ClientKeyExchange 消息后，用自己的私钥解密，得到明文的 Pre-Master Secret。

   • 服务器使用相同的三个随机数（Client Random、Server Random、Pre-Master Secret）和相同的算法，在本地独立计算出相同的会话密钥。

2. 服务器切换密码套件：

   • 服务器发送 ChangeCipherSpec 消息，通知客户端：“我这边也切换完毕，后续消息将使用会话密钥加密”。

3. 服务器完成握手：

   • 服务器同样计算所有握手消息的摘要，用会话密钥加密后，通过 Finished 消息发送给客户端。

   • 客户端解密并验证此消息，确认密钥一致且握手未被篡改。

作用：至此，双向的身份认证和密钥协商已全部完成。一个安全的、加密的通道正式建立，后续所有的应用数据（HTTP请求/响应）都将使用高效的对称加密算法（如AES）进行传输。

---

关键问题解答

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算法：每次会话生成临时密钥对，握手后丢弃私钥。