1.https

HTTPS 也是⼀个应用层协议，是在 HTTP 协议的基础上引入了⼀个加密层，也就是 “运行在 SSL/TLS 加密通道上的 HTTP 协议”

因为在客户端请求数据的过程时，不免需要上传一些隐私数据进行请求，那么在传输的过程中就有可能被不法分子截获，因此有了比 http 更加安全的 https

2.对称加密

既然要保证网络传输的安全，原始的传输数据叫明文，经过特定算法加密的数据叫密文

对称加密指的是加密和解密使用的是同一个密钥。客户端先把用来加密的密钥发送给服务端，此时双方就协商好了一把密钥用于加密，客户端发送加密过的密文，服务端再用密钥解析就能获取明文了

但是你怎么把这把钥匙安全地给对方？如果在网上发钥匙，被黑客截获了，加密就白费了，这正是 HTTPS 引入非对称加密要解决的问题

3.非对称加密

非对称加密指的是使用一对公钥私钥进行加密解密

• 公钥 (Public Key)： 公开给所有人，用于加密

• 私钥 (Private Key)： 自己严密保存，用于解密

用公钥锁住的东西，只有对应的私钥能打开

和对称加密相似，服务端先生成一对公钥私钥，把公钥发送给客户端，私钥自行保留，然后客户端用该公钥来加密发送数据，服务端收到后用私钥解密获得明文

但是这依然存在风险，如果中间人将服务端发送的公钥，换成中间人自己生成的公钥给到客户端，然后每次客户端发送密文时，中间人都能用自己的私钥解密偷窃隐私数据，然后再用服务端的公钥加密给回到服务端，服务端和客户端都无法发现被中间人盗取过

4.双方都用非对称加密

客户端和服务端都生成一对公钥私钥，客户端和服务端交换公钥，客户端给服务端发信息：先用 S 对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'。服务端给客户端发信息：先用 C 对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥 C'

但是这依然不能解决中间人替换公钥的风险，而且非对称加密是个很耗时的过程，这会导致效率很低下

5.非对称加密 + 对称加密

服务端生成一对公钥私钥，把公钥发给客户端，客户端生成对称密钥，先用对称密钥加密明文，然后用公钥进一步加密保护，发送给服务端，服务端用私钥解密，再用对称密钥解密，由于使用了公钥私钥保护对称密钥，后续的过程都使用对称加密

但是刚开始的公钥发送过程还是没有得到保护，依然可以被中间人替换，最需要解决的问题就是这个公钥的发送

7.非对称加密 + 对称加密 + 证书认证

7.1 🤔什么是数据摘要（数据指纹）？

把任意长度的数据，通过算法压缩成一串固定长度的字符（指纹），原文只要改动一个标点符号，生成的摘要会完全由面目全非，且该摘要产生哈希碰撞的概率极低，无法从摘要反推回原文。数据摘要可以理解为身份证，用来比对和原文数据的一致性

7.2 🤔什么是CA认证？

服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性

这是一个关于 HTTPS/SSL 数字证书申请、签发与验证流程 的详细解析图。展示了服务器（Server）、证书颁发机构（CA）和客户端（Client）三者如何通过非对称加密和数字签名技术建立信任链

第一阶段：证书申请（Server 端操作）

1. 生成公钥与私钥对 (Step 1)

• 操作：服务器（Server）首先生成一对非对称密钥，即公钥（pub_svr）和私钥（pri_svr）
• 原则：私钥必须严格保密，仅服务器自己持有；公钥将对外公开

2. 生成证书签名请求 (CSR)

• 内容：服务器准备申请信息，包括域名（图中示例为 cdn.qq.com）、申请者信息（TEG/APD）以及刚刚生成的公钥（pub_server）
• CSR文件：将上述信息打包生成 .csr 请求文件
• 注意：申请过程中绝不会包含服务器的私钥

🤔如果黑客把我的 CSR 截下来，把里面的公钥换成他自己的，然后发给 CA 骗证书怎么办？

这就是 CA 机构存在的意义——审核。 在 CA 给你签发证书之前，他必须验证你真的是域名的主人。验证方式通常有 DNS 验证： 让你在域名的 DNS 记录里加一条特定的乱码。文件验证： 让你在网站服务器的特定目录下放一个特定的文件。

第二阶段：证书审核与签发（CA 端操作）

3. 审核信息 (Step 2)

• CA 机构收到 CSR 请求后，会验证申请者的身份真实性以及其对域名的所有权

4. 签发证书 (Step 3)

• 审核通过后，CA 会生成证书的明文信息 (INFO)，包含：

• 签发机构（CA_qq）

• 有效时间（2022/1/1-2024/1/1）

• 域名（cdn.qq.com）

• 服务器公钥（pub_server）等

• 核心步骤：生成数字签名 (Signature)

• 摘要计算：CA 对明文信息（INFO）进行 Hash 运算（如 SHA-256），得到摘要

• 加密签名：CA 使用自己的私钥（private_CA）对摘要进行加密。公式为：Sig = Enc_by_private_CA[Hash(INFO)]

• 最终的证书包含了“明文信息”和“数字签名”

5. 返回证书 (Step 4)

• CA 将签发好的证书发送回服务器

第三阶段：证书验证（Client 端操作）

6. 下发证书

• 当客户端（Client）向服务器发起 HTTPS 连接请求时，服务器将证书发送给客户端

7. 验证证书 (Step 5)

• 客户端收到证书后，执行严格的校验流程，确保未被篡改且来源可信：
• 完整性校验（防篡改）：

1. 计算摘要：客户端提取证书中的明文信息（INFO），使用相同的 Hash 算法计算摘要，记为 D_cal
2. 解密签名：客户端使用CA 的公钥（通常预置在操作系统或浏览器中）解密证书中的数字签名（Sig），得到解密后的摘要，记为 D_pem。公式为：D_pem = Dec_by_pub_CA[Sig]
3. 对比：如果 D_cal == D_pem，证明证书内容在传输过程中未被篡改，且确由持有 CA 私钥的机构签发

• 有效性校验：
• 检查当前时间是否在证书的“有效时间”内
• 检查访问的域名是否与证书中的“域名”匹配
• 检查证书是否在吊销列表（CRL）中或通过 OCSP 验证状态

第四阶段：后续流程

8. 密钥协商 (Step 6)

• 一旦证书验证通过，客户端就会信任服务器的身份，并从证书中提取出服务器的公钥（pub_server）
• 双方利用该公钥进行后续的密钥协商（如 ECDHE 算法），生成会话密钥（Session Key），用于后续数据的对称加密传输

7.3 🤔什么是数字签名？

签名过程（由发送者/签名者操作）：

把原始的数据通过散列函数进行计算，得到一个固定长度的散列值，这就是数据摘要，使用 CA 机构的私钥（即证书签发者的私钥）对刚才计算出的摘要（散列值）进行加密，就得到了签名，将生成的签名跟原始的数据打包在一起，生成数字签名的数据，发送给接收方

验证过程（由接收方/验证者操作）：

接收方收到数字签名的数据后，将其拆解为数据和签名两部分，对收到的数据使用同样的散列函数重新算一遍，得到一个新的散列值，然后使用用 CA 机构的公钥对收到的签名进行解密，还原出发送者当时计算的散列值，对比得到的两个散列值

• 如果相等： 证明数据未被篡改，且签名是真的（公钥能解开，说明确实是对应的私钥锁的）。验证通过！
• 如果不等： 说明要么数据在路上被改了，要么签名是伪造的。验证失败！

为什么签名不直接加密，而是要先hash形成摘要?

缩小签名密文的长度，加快数字签名的验证签名的运算速度

7.4 非对称加密 + 对称加密 + 证书认证

客户端发起连接后，首先通过服务器提供的 SSL/TLS 证书完成身份认证，确认对方是真实的目标服务器；接着利用服务器公钥加密一个随机的预主密钥，安全地传递给服务器，双方再基于这个预主密钥计算出同一把临时对称密钥；之后所有的业务数据都用这把对称密钥进行高速加密传输，既通过非对称加密解决了对称密钥的安全分发问题，又通过对称加密保证了通信效率，同时证书认证从源头阻止了中间人伪装攻击

预主密钥是啥？为啥不直接用公钥加密对称密钥？

1. 预主密钥是客户端生成的一个随机数，它的核心作用是作为生成最终对称密钥的 “原料”，如果客户端直接生成最终的对称密钥并用公钥加密发送，那么这个密钥在网络中传输的是 “成品”，一旦出现算法漏洞或私钥泄露，风险会直接波及最终密钥。而预主密钥只是 “原料”，客户端和服务器还要结合各自生成的随机数，通过算法推导出最终的对称密钥。这种 “多因子混合” 的方式让密钥更难被破解。
2. 最终的对称密钥由 Client Random + Server Random + 预主密钥 共同生成，引入了双方的随机数，让每一次会话的密钥都具有极高的独特性，即使预主密钥在某次会话中被意外泄露，也不会影响其他会话的安全

中间人有没有可能篡改该证书？

中间人篡改了证书的明文，由于他没有 CA 机构的私钥，所以无法 hash 之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名，如果强行篡改，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人

中间人整个掉包证书？

因为中间人没有 CA 私钥，所以无法制作假的证书，所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包，这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来

---

希望读者们多多三连支持

小编会继续更新

你们的鼓励就是我前进的动力！