Linux：理解HTTPS

HTTPS 是一种应用层协议，它在 HTTP 协议的基础上引入了一层由 SSL/TLS 协议实现的加密层。HTTP 协议的数据内容以明文文本的形式传输，这就导致数据在网络传输过程中，容易被中间人截获、篡改，篡改后的数据若被重新发送，接收方难以识别异常，进而引发安全问题。

常见的加密方式

对称加密

• 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。核心特征：加密和解密所用的密钥是相同的。
• （常见对称加密算法（了解）：DES、3DES、AES、TDEA、Blowfish、RC2 等）
• 特点：算法公开、计算量小、加密速度快、加密效率高

对称加密的核心逻辑：通过同一个 密钥，把明文加密成密文，并且也能把密文解密成明文。

非对称加密

• 需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。核心特征：公钥和私钥是配对存在的，二者缺一不可。
• （常见非对称加密算法（了解）：RSA、DSA、ECDSA）
• 特点：算法强度复杂、安全性依赖于算法与密钥，但由于其算法复杂，加密解密速度远低于对称加密。

非对称加密的两种使用方式：

1. 公钥加密，私钥解密
   • 通过公钥对明文加密，生成密文；
   • 只有配对的私钥才能将密文解密为明文。
2. 私钥加密，公钥解密
   • 通过私钥对明文加密，生成密文；
   • 只有配对的公钥才能将密文解密为明文。

数据摘要 && 数据指纹

• 数字指纹（又称数据摘要），其基本原理是利用单向散列函数（Hash 函数） 对原始信息进行运算，生成一串固定长度的二进制或十六进制字符串。数字指纹并不是一种加密机制，核心作用是判断数据在传输或存储过程中是否被篡改。
• （常见摘要算法：MD5、SHA1、SHA256、SHA512 等。这类算法的本质是把无限长度的原始数据 映射成固定长度的摘要值，因此理论上存在 "碰撞" 可能性（即两个不同的原始信息，计算出的摘要值完全相同），但不同算法的碰撞概率差异较大，如 SHA256 的碰撞概率远低于 MD5。）
• 摘要核心特征：与加密算法的本质区别是，摘要过程不可逆------ 无法通过生成的摘要值反推出原始信息，也不存在 "解密" 的概念。它通常用于数据完整性校验，比如对比原始数据的摘要和传输后数据的摘要，若两者一致则说明数据未被篡改。

方案 1：只使用对称加密

核心思路

通信双方提前约定一个共享密钥，所有数据都通过该密钥进行加密和解密，传输过程中只有密文流转。

核心缺陷

1. **密钥分发难题（致命缺陷）**如果密钥通过网络传输给对方，中间人可以直接截获密钥，之后就能解密所有通信数据，加密形同虚设。

方案 2：只使用非对称加密

核心思路

服务器生成公钥 + 私钥对，公钥公开给所有客户端，客户端用公钥加密数据后发送给服务器，服务器用私钥解密。

核心缺陷

1. 加密效率极低（性能瓶颈）
2. 公钥伪造风险 中间人可以冒充服务器，向客户端发送伪造的公钥。客户端用伪造公钥加密的数据会被中间人截获，中间人用自己的私钥解密后，再用真实服务器的公钥加密转发，全程不会被察觉。

方案 3：双方都使用非对称加密

核心思路

客户端和服务器各自生成一对公钥 + 私钥，并互相交换公钥：

• 客户端用服务器的公钥加密数据，服务器用私钥解密；
• 服务器用客户端的公钥加密数据，客户端用私钥解密。

核心缺陷

1. 性能问题进一步恶化
2. 仍存在公钥伪造风险双方交换公钥的过程中，中间人依然可以篡改公钥，冒充任意一方进行通信。

方案 4：非对称加密 + 对称加密（混合加密）

核心思路

结合两种加密方式的优点，用非对称加密解决密钥分发问题，用对称加密解决数据传输效率问题，这也是 HTTPS 的核心加密架构：

1. 服务器生成并公开公钥 + 私钥对；
2. 客户端生成一个临时对称密钥（会话密钥），用服务器的公钥加密该对称密钥，发送给服务器；
3. 服务器用私钥解密，得到客户端的对称密钥；
4. 后续所有数据都通过对称密钥加密传输。

核心缺陷（需额外机制弥补）

1. 公钥伪造风险依然存在

中间人伪造公钥攻击的完整过程

• 服务器：非对称加密公钥 S、私钥 S'
• 中间人：非对称加密公钥 M、私钥 M'
• 客户端：无初始密钥，需要获取服务器公钥来协商对称密钥

1. 客户端发起请求客户端向目标服务器发送 HTTPS 连接请求，请求获取服务器公钥用于后续加密通信。

2. 服务器发送公钥 服务器生成明文报文，携带自己的公钥 S，发送给客户端。

3. 中间人劫持并替换公钥 中间人拦截服务器发送的报文，提取并保存真实公钥 S；随后将报文中的公钥 S 替换为自己的公钥 M，伪造一个 "服务器公钥报文" 发送给客户端。

4. 客户端误信伪造公钥 客户端收到报文，无法验证公钥的归属，默认公钥 M 就是目标服务器的公钥；客户端随即生成一个临时对称密钥 X （用于后续数据传输），并用公钥 M 加密 X，生成加密报文发送给服务器。

5. 中间人解密并二次加密 中间人再次拦截客户端的加密报文，用自己的私钥 M' 解密报文，获取对称密钥 X；随后用之前保存的服务器真实公钥 S 加密 X，生成新的加密报文发送给服务器。

6. 服务器解密获取密钥 服务器收到报文，用自己的私钥 S' 解密，成功得到对称密钥 X，并认为 X 是客户端与自己协商的专属密钥。

7. 中间人窃听 / 篡改通信 客户端与服务器后续均使用对称密钥 X 加密传输数据，但由于 X 已被中间人获取：

   • 中间人拦截客户端→服务器的密文，用 X 解密即可窃听明文，修改后再用 X 加密转发；
   • 同理可拦截服务器→客户端的密文，实现双向窃听与篡改；
   • 客户端和服务器全程无法察觉通信已被劫持。

问题本质

客户端缺少对公钥身份的验证机制，无法确认收到的公钥是否属于目标服务器，这是中间人攻击能够成功的核心原因。

引入证书

CA 认证

服务器在使用 HTTPS 协议前，需要向权威的CA（证书颁发机构）申领一份数字证书。

这份数字证书包含以下核心信息：

1. 证书申请者信息：服务器的域名、组织名称等身份标识；
2. 服务器的公钥：服务器用于非对称加密的公钥；
3. CA 的数字签名：CA 用自身私钥对 "申请者信息 + 服务器公钥" 生成的摘要加密后的结果，是证书合法性的核心凭证；
4. 证书有效期：证书的生效和过期时间。

在 HTTPS 握手阶段，服务器不会直接传输裸公钥，而是将这份数字证书发送给客户端（如浏览器）。客户端会先验证证书的合法性（通过内置的 CA 公钥解密签名、对比摘要、检查有效期等），验证通过后，才从证书中提取服务器的公钥进行后续通信。

服务端申请 CA 证书的数字签名生成过程

当服务端向 CA 机构申请数字证书时，CA 机构会先对服务端的身份和信息进行严格审核，审核通过后，会为该服务端生成专属的数字签名，最终和证书明文一起组成合法的数字证书。具体过程如下：

1. CA 机构持有专属密钥对 ：CA 机构拥有一套自己的非对称加密密钥对 ------ 私钥A 和公钥A'。其中，私钥A严格保密 ，仅 CA 机构自己持有；公钥A'会预置到所有主流客户端（如浏览器、操作系统）中，供客户端验证证书使用。
2. 生成证书明文数据的摘要 ：CA 机构提取服务端证书申请中的明文数据（包括服务器域名、服务器公钥S、组织信息、证书有效期等），用指定的哈希算法（如 SHA256）对这些明文数据计算，生成固定长度的唯一数据摘要。
3. 用 CA 私钥加密摘要生成数字签名 ：CA 机构使用自己的私钥A，对上述生成的数据摘要进行非对称加密，得到的加密结果就是数字签名S。
4. 组合形成完整数字证书 ：CA 机构将证书明文数据 和 数字签名S 绑定在一起，形成一份完整的数字证书，并颁发给服务端。

这份数字证书的核心价值在于：客户端可以通过预置的 CA 公钥A'解密签名，验证证书是否被篡改、是否属于目标服务器。

方案 5：非对称加密 + 对称加密 + 证书认证

这是 HTTPS 的最终安全方案，整合了混合加密的效率优势和 CA 证书的身份认证能力，彻底解决了前 4 个方案的核心缺陷

1. 非对称加密 ：仅用于协商对称密钥，解决对称加密的密钥分发难题。
2. 对称加密 ：用于传输所有业务数据，保证通信效率。
3. CA 证书认证 ：用于验证服务器公钥的合法性，阻断中间人伪造公钥的攻击路径。
4. 补充机制 ：搭配数据摘要（Hash） 校验完整性、随机数 / 时间戳 防重放攻击。

完整执行流程

1. 客户端发起 HTTPS 连接请求

2. 服务器响应并发送证书

3. 中间人劫持但无法伪造证书 由于中间人没有 CA 私钥，无法生成合法的 CA 数字签名

4. 客户端验证证书合法性

   1. 从证书中取出服务器公钥S

   2. 用CA_公钥解密数字签名，得到CA 生成的原始数据摘要

   3. 用和 CA 相同的 Hash 算法，对证书中的明文计算，得到当前摘要

   4. 对比摘要 + 额外校验 ：

      • 若两个摘要一致 → 证书未被篡改，公钥S合法；
      • 同时校验证书是否在有效期内、域名是否与目标一致；
      • 若验证失败 → 客户端直接终止连接，提示 "证书不安全"。

5. 客户端生成会话密钥并加密传输 用服务器公钥S加密，发送给服务器

6. 服务器解密生成会话密钥 用自己的私钥S'解密

7. 双方用对称密钥安全通信

中间人对 CA 证书的攻击尝试与失效原因

一、 中间人篡改证书明文 → 直接被客户端识别

1. 攻击行为 ：中间人拦截服务器发送的合法证书，修改证书内的明文信息（如替换服务器公钥为自己的公钥M、篡改域名等）。
2. 攻击失效原因 ：
   • 证书的数字签名 是 CA 用私钥对原始明文的 Hash 摘要加密生成的，签名和原始明文是一一对应的。
   • 中间人没有 CA 私钥，无法对篡改后的明文重新计算摘要并生成合法签名，只能保留原签名。
   • 客户端验证时，会对篡改后的明文重新计算 Hash 摘要，再用 CA 公钥解密原签名得到原始摘要。两者对比必然不一致，客户端直接判定证书被篡改，终止连接。

二、中间人整体掉包证书 → 无法通过身份校验

1. 攻击行为 ：中间人不用篡改原有证书，而是替换成自己从 CA 申请的合法证书，试图冒充服务器。
2. 攻击失效原因 ：
   • 证书身份信息不匹配 ：中间人申请的合法证书，其绑定的域名是中间人自己的域名，而非目标服务器的域名。
   • 客户端验证时，会核对证书中的域名是否和自己访问的目标域名一致。一旦不一致，客户端直接拒绝信任该证书，攻击失败。
   • 补充：如果中间人想申请目标服务器域名的证书，CA 机构会要求申请者提供域名所有权证明（如验证域名解析记录、企业资质等），中间人无法通过审核，根本拿不到合法证书。

为什么数字签名要先 Hash 生成摘要，而非直接加密明文？

缩小密文长度、提升验证速度