🎬 艾莉丝的简介：

核心思维导图

HTTPS 协议原理 ├─1. HTTPS 基础认知 │ ├─1.1定义与协议栈定位 │ └─1.2明文传输的风险：中间人攻击与运营商劫持 ├─2. 密码学基础 │ ├─2.1加密与解密的核心定义 │ ├─2.2对称加密 │ ├─2.3非对称加密 │ ├─2.4数据摘要（数字指纹） │ └─2.5数字签名 ├─3. HTTPS 加密方案演进与缺陷 │ ├─3.1方案1：仅使用对称加密 │ ├─3.2方案2：仅使用单向非对称加密 │ ├─3.3方案3：双向非对称加密 │ └─3.4方案4：非对称+对称混合加密 ├─4. 中间人攻击（MITM）原理 │ ├─4.1攻击前提 │ ├─4.2针对混合加密方案的攻击流程 │ └─4.3核心漏洞本质 ├─5. CA 证书与身份认证体系 │ ├─5.1数字证书的结构与本质 │ ├─5.2CA机构与证书签发流程 │ ├─5.3客户端证书校验逻辑 │ └─5.4防篡改、防掉包的原理 └─6. HTTPS 完整工作流程（最终方案） ├─6.1握手与通信全步骤 ├─6.2全程三组密钥的分工 └─6.3常见证书异常场景

1 ~> HTTPS 基础认知

1.1 定义与协议栈定位

• HTTPS = HTTP + TLS/SSL：在 HTTP 明文协议基础上，新增 TLS/SSL 安全层，实现传输加密、身份认证与数据完整性校验，本质是 “加密的 HTTP”。
• 协议栈层级：
  • 应用层：HTTP 安全层：TLS / SSL（加密解密、密钥协商） 传输层：TCP 网络层：IP 数据链路层
• 通信双方必须同时支持 TLS/SSL，发送端加密、接收端解密，HTTP 层感知不到加密过程。

1.2 明文传输的风险

HTTP 明文传输时，数据经过路由器、运营商、公共 WiFi 等中间节点时可被直接读取与篡改，典型风险：

• 运营商劫持：篡改 HTTP 响应中的下载链接、注入广告，将目标资源替换为推广内容；
• 中间人攻击（MITM）：攻击者截获并篡改通信双方的全部数据，窃取账号密码、支付信息等敏感内容，且用户无感知。

2 ~> 密码学基础

2.1 加密与解密核心定义

• 明文：原始可直接读取的传输数据；
• 密文：明文经过加密变换后生成的不可直接读取的数据；
• 密钥：加密与解密过程中使用的中间参数，是控制明文与密文转换的核心。

2.2 对称加密

• 核心特征：加密与解密使用同一个密钥，又称单密钥加密。
• 常见算法：DES、3DES、AES、Blowfish、RC2 等。
• 优势：算法公开、计算量小、加密速度快、效率高，适合大数据量传输。
• 核心问题：密钥如何安全地在通信双方之间同步，密钥本身的传输存在泄露风险。

最简示例（按位异或）：

// 明文a=1234，密钥key=8888intcipher=a^key;// 加密：得到密文9834intplain=cipher^key;// 解密：还原明文1234`

2.3 非对称加密

• 核心特征：存在一对配对密钥 ——公钥（公开可分发）与私钥（必须严格保密）；公钥加密只能用私钥解密，私钥加密只能用公钥解密。
• 常见算法：RSA、DSA、ECDSA。
• 优势：密钥分发安全，无需提前同步密钥，可用于身份认证。
• 劣势：算法复杂度高、运算速度远慢于对称加密，不适合大数据量传输。
• 两种使用场景：
  • 公钥加密、私钥解密：保证只有私钥持有者能读取数据，用于加密传输；
  • 私钥加密、公钥解密：保证数据只能由私钥持有者发出，用于数字签名。

2.4 数据摘要（数字指纹）

• 原理：通过单向散列函数（Hash 函数）对任意长度数据运算，生成固定长度的散列值。
• 常见算法：MD5、SHA1、SHA256、SHA512。
• 核心特性：
  • 定长输出：无论输入数据多大，输出长度固定；
  • 强碰撞抗性：输入改动 1 个比特，输出散列值会发生巨大差异；
  • 单向不可逆：无法通过散列值反推原始数据。
• 本质：不属于加密算法（无解密过程），核心作用是校验数据完整性、判断数据是否被篡改。
• 典型应用：网盘秒传、数据库密码存储、文件完整性校验。

2.5 数字签名

• 定义：对数据摘要使用私钥进行加密，得到的结果即为数字签名，随原始数据一同传输。
• 校验流程：
  • 接收方拆分原始数据与签名；
  • 对原始数据重新计算摘要，同时用公钥解密签名得到原始摘要；
  • 对比两个摘要，一致则说明数据未被篡改，且签名来自私钥持有者。
• 核心作用：同时实现数据完整性校验与身份认证，确保数据由指定方发出且未被篡改。

3 ~> HTTPS 加密方案演进与缺陷

3.1 方案 1：仅使用对称加密

• 思路：通信双方使用同一密钥对全部 HTTP 数据加密解密。
• 致命缺陷：首次密钥同步无法安全完成 —— 密钥明文传输会被中间人截获，加密密钥本身又无法用对称加密传输，陷入 “先有鸡还是先有蛋” 的死循环，完全不可行。

3.2 方案 2：仅使用单向非对称加密

• 思路：服务器下发公钥，客户端用公钥加密请求后发送，只有服务器私钥能解密。
• 缺陷：
  • 仅保证客户端→服务器的单向安全，服务器→客户端方向用私钥加密时，公钥是公开的，中间人可直接解密；
  • 非对称加密运算速度极慢，无法支撑高频 HTTP 通信。

3.3 方案 3：双向非对称加密

• 思路：客户端与服务器各自生成公私钥对，先交换公钥；发送数据时用对方公钥加密，只有对方私钥能解密，实现双向安全。
• 缺陷：
  • 未解决公钥身份认证问题，中间人仍可替换公钥；
  • 全程非对称加密，运算效率极低，工程上不可用。

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

• 思路：
  • 服务器持有非对称公私钥对，先向客户端下发公钥；
  • 客户端本地随机生成对称密钥，用服务器公钥加密该对称密钥后发送；
  • 服务器用私钥解密得到对称密钥；
  • 后续全部 HTTP 数据均使用该对称密钥加密传输。
• 优势：仅密钥协商阶段使用非对称加密，后续通信使用高效的对称加密，兼顾安全与性能。
• 遗留缺陷：无法证明下发的公钥确实来自目标服务器，中间人可在公钥传输阶段替换公钥，实现全程窃听与篡改。

4 ~> 中间人攻击（MITM）原理

4.1 攻击前提

攻击者处于通信链路中间（如公共 WiFi、恶意路由器、运营商节点），可截获并转发双方的全部数据包，且客户端无法识别公钥的归属。

4.2 针对混合加密方案的攻击流程

1. 服务器持有公私钥 S/S’，中间人持有自己的公私钥 M/M’；
2. 客户端发起请求，服务器返回公钥 S，中间人截获后保存 S，将响应中的公钥替换为自己的公钥 M，发给客户端；
3. 客户端误以为 M 是服务器公钥，生成对称密钥 X，用 M 加密后发送；
4. 中间人截获密文，用自己的私钥 M’ 解密得到 X，再用服务器公钥 S 加密 X 后转发给服务器；
5. 服务器解密得到 X，客户端与服务器均认为密钥安全，实则中间人已掌握对称密钥 X，可全程解密、篡改所有通信数据。

4.3 核心漏洞本质

客户端无法甄别收到的公钥是否属于目标服务器，无法区分公钥来自合法服务器还是中间人。

5 ~> CA 证书与身份认证体系

5.1 数字证书的结构与本质

• 本质：携带数字签名的服务器身份明文信息，相当于网站的 “身份证”。
• 明文信息（INFO）：包含域名、申请者信息、服务器公钥、证书有效期、签发机构等；
• 数字签名（Sig）：CA 机构对明文信息做 Hash 得到摘要，再用 CA 私钥加密摘要，生成签名。
• 公式：Sig = Encrypt_CA_Private( Hash(INFO) )

5.2 CA 机构与证书签发流程

1. 服务器生成本地公私钥对，将公钥、域名、企业资质等信息提交给 CA 机构；
2. CA 机构审核申请者身份，确认域名归属与企业合法性；
3. CA 对证书明文信息计算摘要，用自身私钥加密摘要生成签名；
4. CA 将明文信息 + 数字签名组合为正式证书，颁发给服务器；
5. 服务器将证书部署在服务端，客户端请求时直接返回证书。

5.3 客户端证书校验逻辑

操作系统与浏览器会内置全球可信 CA 机构的公钥，校验流程：

1. 拆分证书中的明文信息与数字签名；
2. 对明文信息使用相同 Hash 算法重新计算摘要 D1；
3. 用内置的 CA 公钥解密数字签名，得到原始摘要 D2；
4. 对比 D1 与 D2：一致则证书未被篡改，服务器公钥可信；不一致则证书无效。
5. 额外校验：验证证书域名与访问域名是否一致、证书是否在有效期内、是否被吊销。

5.4 防篡改与防掉包原理

• 防局部篡改：中间人篡改证书明文（如替换公钥）后，无法生成匹配的数字签名 —— 签名需要 CA 私钥，中间人不持有，客户端校验时摘要比对必然失败。
• 防整体掉包：中间人可申请自己的合法证书，但证书中的域名与目标网站域名不一致，客户端校验域名时会直接识别异常；且申请证书需要实名资质，中间人无法冒用目标域名申请证书。

6 ~> HTTPS 完整工作流程（含方案5）

方案5=非对称加密（证书认证） + 非对称加密（密钥协商） + 对称加密（数据传输）

6.1 握手与通信全步骤

1. 证书下发：客户端发起 HTTPS 请求，服务器返回自身数字证书；
2. 证书校验：客户端使用内置 CA 公钥验证证书合法性，校验域名、有效期；校验失败则弹出安全警告并终止连接；
3. 对称密钥协商：校验通过后，客户端本地随机生成对称密钥 R，用证书中的服务器公钥加密 R，发送给服务器；
4. 密钥确认：服务器用自身私钥解密，得到对称密钥 R；
5. 加密通信：后续所有 HTTP 请求与响应，均使用对称密钥 R 进行加密解密传输。

6.2 全程三组密钥的分工

HTTPS 共涉及三组密钥，各司其职：

核心逻辑：CA 非对称密钥保障服务器公钥可信，服务器非对称密钥保障对称密钥安全传输，对称密钥保障业务数据的高效加密。

6.3 常见证书异常场景

• 证书过期：证书超出有效期限，浏览器提示风险；
• 域名不匹配：证书域名与访问网站域名不一致，疑似中间人掉包；
• 证书不可信：签发机构不在系统受信任 CA 列表中，或证书为自签名证书；

以上场景均为浏览器的安全防护机制，未用户确认前禁止建立加密连接。

结尾

uu们，本文的内容到这里就全部结束了，艾莉丝在这里再次感谢您的阅读！

艾莉丝努力练剑 C/C++ & Linux 底层探索者 | 一个正在努力练剑的技术博主 👀【关注】跟随我一起深耕技术领域，见证每一次成长。 ❤️【点赞】让优质内容被更多人看见，让知识传递更有力量。 ⭐【收藏】把核心知识点存好，在需要时随时查、随时用。 💬【评论】分享你的经验或疑问，评论区一起交流避坑！ 不要忘记给博主“一键四连”哦！ “今日练剑达成！” “技术之路难免有困惑，但同行的人会让前进更有方向。”

结语：希望对学习Linux相关内容的uu有所帮助，不要忘记给博主“一键四连”哦！

往期回顾：

【Linux网络·加餐】HTTPS协议：从密码学基础到安全机制

🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡૮₍ ˶ ˊ ᴥ ˋ˶₎ა