HTTPS 协议原理

Linux：HTTPS 协议原理 | CSDN（荐）

LINUX 网络基础 [六] - HTTPS 协议 | CSDN

先简单回顾一下 TCP/IP 四层模型（视频剩余部分可作为了解）：http 和 https 有什么区别吗？(SSL 协议) | B 站。

1. 概念准备

1. HTTPS 是什么？

HTTPS（HyperText Transfer Protocol Secure）是一个 应用层协议，可以理解为是 HTTP 协议的“安全版”。

• 核心区别：在 HTTP 协议的基础上引入了一个 加密层。
• 原因：标准的 HTTP 协议是 明文传输 的，这意味着传输的数据（如账号、密码、个人信息）在经过路由器、运营商等网络设备时，很容易被“劫持”或“篡改”（例如“运营商劫持”下载链接）。
• 目的：通过加密，保证用户的信息安全，防止数据在传输过程中被窃取或篡改。

2. 什么是加密？

• 加密：将要传输的原始信息（称为 明文）通过一系列数学变换，生成一段不可读的、看似随机的文本（称为 密文）的过程。
• 解密：将 密文 通过一系列变换，还原成原始 明文 的过程。
• 密钥：在加密和解密过程中，需要用到一个或多个关键数据，这个数据就叫做 密钥。它是加密算法的核心，决定了加密和解密的具体方式。

3. 为什么要加密？

主要原因是为了应对网络传输中的安全威胁，特别是 中间人攻击（Man-in-the-Middle Attack, 简称 MITM 攻击）。

• 明文传输的风险：HTTP 的明文数据在传输过程中会经过多个物理节点（路由器、运营商等）。任何能接触到这些节点的人都可以 窃取 我们的隐私信息（如登录密码、支付信息），甚至可以 篡改 传输的内容（如将运营商设备篡改下载链接等等）。
• 加密的作用：通过对信息进行加密，即使数据被劫持，黑客看到的也只是无法理解的密文，从而保护了信息的机密性和完整性。

4. 常见的加密方式

下面这些视频我认为讲的非常好，虽然标题各式各样的，但是内容和我们要讲的基本一致，超出的知识就当扩展了，如果后面的文字讲解难懂，建议先看视频 👉：

HTTPS 是什么?原理是什么？用公钥加密为什么不能用公钥解密？ | B 站

HTTPS 是什么？加密原理和证书。SSL/TLS 握手过程 | B 站

HTTPS 真的安全吗，一个动画秒懂！ | B 站

白话 HTTPS，如何在全世界的眼皮子底下安全密谋？ | B 站

https 真安全么？ 抓包解密 https 的两种原理+实战 开源软件 mitmproxy 与 wireshark 如何抓包 https | B 站

数字签名和 CA 数字证书的核心原理和作用 B 站

12 分钟弄懂 HTTPS 概念与原理 / HTTPS 入门教程 | B 站

1. 对称加密

• 原理：使用 同一个密钥 进行加密和解密。这个密钥必须由通信双方共同持有。
• 特点：
  • 优点：算法公开、计算量小、加密速度快、效率高。
  • 缺点：最大的问题是 密钥的分发。如何安全地把这个“共享密钥”告诉对方？如果通过网络明文传输密钥，那么密钥本身就会被截获，整个加密就形同虚设。
• 常见算法：DES、3DES、AES 等。
• 简单示例：按位异或（XOR）操作。用密钥 key 对明文 a 加密得到密文 b（a ^ key = b），再用同一个密钥 key 对密文 b 解密就能得到明文 a（b ^ key = a）。

2. 非对称加密

• 原理：使用 一对 密钥，一个 **公钥 ** 和一个 私钥。公钥和私钥是成对生成的，它们之间有特殊的数学关系。
• 工作方式：
  • 用 公钥 加密，只能用对应的 私钥 解密。
  • 用 私钥 加密（这通常称为“签名”），只能用对应的 公钥 解密（这通常称为“验证”）。
• 特点：
  • 优点：解决了密钥分发问题。公钥可以公开给任何人，而私钥自己严格保密。即使公钥被截获，没有私钥也无法解密。
  • 缺点：算法复杂，加密和解密速度比对称加密慢很多。
• 常见算法：RSA、DSA、ECDSA 等。
• 生活中的例子：公钥就像一把 锁，可以公开分发。任何人想给你发秘密文件，就把文件放进盒子并用这把“锁”锁上。只有你拥有对应的“钥匙”（私钥），才能打开盒子取出文件。

3. 数据摘要 && 数据指纹

摘要 就是把 任意长度的数据，通过 Hash 函数 变成一个 定长的“指纹”或“身份证”（对原始数据进行单向哈希运算后得到的一串固定长度的字符串），能用来验证数据完整性；数据指纹类似，也是通过算法提取数据特征，可用于识别和区分不同数据，它们都像数据的独特 “标识”。

数据摘要的特点：

• 不可逆：从摘要推不回原文。
• 雪崩效应：原文哪怕改 1 个字节，摘要都会完全不同。
• 长度固定：无论原文多大，都能快速生成摘要，摘要结果都是固定长度（比如 256 位）。
• 确定性：相同输入 → 相同输出。
• 抗碰撞性：极难找到两个不同内容生成相同摘要（防伪造）。

数据摘要可以理解为：原文 = 一大堆内容，摘要 = “身份证号” 或 “指纹”（唯一标识这个内容，改了就对不上）。

• 原理：利用 单向散列函数（Hash 函数，如 MD5、SHA1、SHA256）对任意长度的数据进行计算，生成一个 固定长度 的、唯一的“数字指纹”或“摘要”。
• 关键特性：
  • 定长：无论输入多长，输出的摘要长度是固定的。
  • 分散：输入数据哪怕只改变一个比特，生成的摘要也会发生巨大变化。
  • 不可逆：无法从摘要反推出原始数据。
  • 防碰撞：理论上不同的数据可能产生相同的摘要（碰撞），但概率极低。
• 用途：严格来说，这不是加密，因为它没有解密过程。它主要用于 验证数据的完整性。接收方可以自己计算收到数据的摘要，然后与发送方提供的摘要进行比对。如果一致，说明数据在传输过程中没有被篡改。

4. 数字签名（后面细说）

• 原理：数字签名 = 数据摘要 + 非对称加密。
  1. 对原始数据（明文）计算一个 数据摘要。
  2. 使用发送方的 私钥 对这个 摘要 进行加密，得到的结果就是 数字签名。
• 验证过程：
  1. 接收方收到原始数据和数字签名。
  2. 用发送方的 公钥 解密数字签名，得到一个摘要值（我们称之为 摘要A）。
  3. 接收方自己用相同的哈希算法对收到的原始数据计算摘要（我们称之为 摘要B）。
  4. 比较 摘要A 和 摘要B。如果相等，则说明：
     • 数据完整性：数据未被篡改（因为摘要匹配）。
     • 身份认证：签名确实是由持有对应私钥的人生成的（因为只有他的公钥才能成功解密）。
• 作用：数字签名解决了“我是谁”和“内容是否被改过”的问题。

2. HTTPS 的 5 种方案探究

• 对称加密：加密和解密使用同一个密钥。速度快，适合大量数据加密。

• 非对称加密：有一对密钥 —— 公钥（可公开）和私钥（必须保密）。公钥加密的数据，只有私钥能解密；私钥签名的数据，公钥可验证。优点：不怕公钥被截获；缺点：速度慢，不适合大数据加密。

• 中间人攻击（MITM）：攻击者在通信双方中间截获、篡改、伪造信息。

方案 1：只使用对称加密

1. 场景

客户端和服务器约定用同一个密钥（比如 “123456”）来加密通信。

2. 密钥如何传输？

必须提前“共享”密钥。比如：客户端和服务器事先约定好密钥（不现实，互联网用户千千万），或者，客户端第一次访问时，服务器“明文发送”密钥给客户端。

3. 风险在哪里？

密钥在传输过程中被截获！ 比如：客户端请求：“请给我密钥”，服务器回复：“密钥是 123456” ← 被黑客监听到，之后所有通信，黑客用 123456 解密 → 完全裸奔！

4. 产生的问题

密钥无法安全传递（除非物理见面，不现实），每个用户都要不同密钥？服务器怎么管理？一旦密钥泄露，所有通信都暴露。

就像我们和朋友约好用同一把钥匙开保险箱，但我们必须先把钥匙寄给他 —— 快递员（黑客）偷了钥匙，就能开你的保险箱。

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

1. 场景

服务器有公钥和私钥。客户端用服务器的公钥加密数据，服务器用自己的私钥解密。

2. 密钥如何传输？

服务器把自己的 公钥 发给客户端（公钥不怕被截获）→ 客户端用公钥加密数据 → 服务器用私钥解密。

3. 风险在哪里？

性能问题 + 无法双向加密：

1. 性能极差：非对称加密计算量大，传个网页都要几秒，用户体验爆炸。
2. 服务器无法加密发给客户端：客户端没有私钥，服务器如果想加密数据发给客户端，必须知道客户端的公钥 —— 但客户端没有公私钥对！如果让客户端也生成公私钥，那就变成方案 3 了。

就像每次寄信都要用特制保险箱（非对称加密），寄一封信要花 10 分钟打包，收件人还要花 10 分钟拆 —— 寄 100 封信？系统崩溃！

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

1. 场景

客户端和服务器各自生成自己的公私钥对。互相交换公钥，然后用对方的公钥加密数据发给对方。

2. 密钥如何传输？

客户端生成公私钥，把公钥发给服务器 → 服务器生成公私钥，把公钥发给客户端 → 双方用对方公钥加密，用自己的私钥解密。

3. 风险在哪里？

中间人攻击（MITM）！ 黑客可以这样干：

1. 客户端 → “我要和服务器通信，请给我公钥”。
2. 黑客截获，伪造自己是服务器，把自己的公钥发给客户端。
3. 客户端 → 用“假公钥”加密数据 → 黑客收到后用自己的私钥解密 → 再用真服务器的公钥加密转发。
4. 服务器 → 回复，黑客同样截获 → 用客户端的假公钥加密再发回去。

客户端和服务器以为在安全通信，其实所有数据都被黑客看到并转发！

4. 产生的问题

• 无法确认“公钥是谁的” —— 公钥被掉包都不知道！
• 性能依然差（非对称加密慢）
• 管理复杂（每个会话都要生成密钥对）

就像我们和朋友交换“加密信箱钥匙”，但快递员偷偷把自己的钥匙塞给我们，说“这是我朋友的”。我寄信给他，他全都能看，再模仿我朋友回信 —— 我们完全被蒙在鼓里！

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

方案 4 在 TLS 1.2 里常见，但 TLS 1.3 已经弃用。现在都用 ECDHE（椭圆曲线 Diffie-Hellman Ephemeral） 做 密钥协商，这样即使服务器长期私钥泄露，历史流量也解不开（前向保密）。换句话说：对称密钥不是传输过来的，而是双方独立算出来的。

1. 场景

用非对称加密来 安全传递对称密钥，之后用对称密钥加密通信数据。

2. 密钥如何传输？

1. 客户端连接服务器，服务器发送自己的 公钥（比如通过证书）
2. 客户端生成一个随机的 对称密钥（如 AES 密钥）
3. 客户端用服务器的 公钥 加密这个对称密钥 → 发送给服务器
4. 服务器用自己的 私钥 解密 → 得到对称密钥
5. 之后所有通信，都用这个对称密钥加密/解密！

3. 风险在哪里？

如果公钥是假的，对称密钥就会被黑客截获！ 还是中间人攻击：

1. 黑客伪造服务器，把自己的公钥发给客户端
2. 客户端生成对称密钥，用“假公钥”加密 → 黑客用自己的私钥解密 → 得到真实对称密钥
3. 黑客再用真服务器的公钥加密对称密钥发给服务器
4. 之后所有通信，黑客都能用对称密钥解密！

问题根源：客户端无法确认收到的公钥是不是真的属于目标服务器！

4. 优缺点

1. 优点：

   • 对称加密快，适合大数据

   • 非对称只用于传密钥，计算量小

2. 缺点：

   • 公钥真实性无法保证 → 需要“身份认证”

就像我们用防弹车（非对称加密）把保险箱钥匙（对称密钥）送到朋友家，但送错了地址（假服务器），钥匙被坏人拿到，之后我们寄的所有东西他都能打开！

方案 5（最终方案）非对称加密 + 对称加密 + 数字证书（HTTPS 真实方案）

1. 场景

在方案 4 基础上，加入 数字证书 来验证服务器公钥的真实性！

2. 密钥如何传输？

1. 客户端发起 HTTPS 请求 → 服务器返回 数字证书（包含服务器公钥 + 服务器身份信息 + CA 签名）
2. 客户端验证证书：
   • 用操作系统/浏览器内置的 CA 公钥 验证证书签名是否合法
   • 检查证书是否过期、域名是否匹配等 → 如果验证失败，浏览器弹出警告
3. 客户端生成随机对称密钥（如 AES-256）
4. 客户端用证书里的服务器公钥加密对称密钥 → 发送给服务器
5. 服务器用自己的私钥解密 → 得到对称密钥
6. 之后所有通信都用对称密钥加密（高效、安全）

3. 如何防御中间人攻击？

数字证书由可信第三方（CA）签名，黑客无法伪造合法证书！黑客即使拦截通信，也无法伪造一个被 CA 签名的证书（除非攻破 CA，极难），客户端会校验证书，发现域名不符或签名无效 → 直接终止连接！

4. 补充安全机制（了解）

• 前向保密（PFS）：每次会话生成临时密钥，即使服务器私钥未来泄露，历史会话也无法解密。（通过 ECDHE 等密钥交换算法实现）
• 证书吊销机制（CRL/OCSP）：应对私钥泄露或证书被盗用。

5. 小结

之前看到的一个很形象、易理解的比喻：想象你要和朋友安全通信：

• 方案 1：你俩约好用同一把钥匙，但你得先寄给他 → 快递员偷了钥匙 → 完蛋。
• 方案 2：每次说话都用特制密码机，太慢 → 聊两句就卡死。
• 方案 3：你俩交换密码机的“公开使用说明”，但快递员把自己的说明书冒充你朋友的 → 你按他的说明书操作，他在偷听。
• 方案 4：你寄一把普通钥匙，但用朋友的“防伪密码箱”寄 → 但如果“防伪密码箱”是假的（快递员给的），钥匙还是被偷。
• 最终方案：朋友的“防伪密码箱”上有 公安局盖章认证（CA 证书）→ 你一看盖章是真的，才放心寄钥匙 → 安全！

1. 为什么 HTTPS 最终选择这个方案？

1. 效率高：对称加密处理海量数据。
2. 安全强：非对称加密保护密钥传输。
3. 身份可信：CA 证书防止公钥被伪造。
4. 可扩展：支持前向保密、吊销、多域名等。

2. 附加：密钥被攻击的几种真实场景

1. 私钥泄露（服务器被入侵）→ 攻击者可解密历史通信（除非启用前向保密）。
2. CA 被攻破 → 攻击者可签发任意假证书（极罕见，如 DigiNotar 事件）。
3. 用户忽略证书警告 → 主动接受假证书 → 中间人攻击成功。
4. 弱随机数生成器 → 生成的对称密钥可预测 → 被破解。

6. 理解链 - 承上启下

1. 对 HTTP 进行对称加密，是否能解决数据通信安全的问题？问题是什么？

不能完全解决，核心问题：密钥的分发。

假设客户端和服务器都用同一个对称密钥来加密通信，这确实能防止第三方窃听。但是，这个密钥是如何从服务器安全地传递给客户端的呢？如果在连接建立之初，服务器直接把密钥明文发给客户端，那么中间人（黑客）同样可以截获这个密钥。一旦密钥泄露，后续所有的“加密”通信对中间人来说就等于没有加密。这就陷入了“先有鸡还是先有蛋”的困境：为了安全传输密钥，我们需要一个密钥来加密它，但这个“用来加密密钥的密钥”又该如何安全传输呢？

2. 为何要用非对称加密？

为了解决“密钥分发”问题。

非对称加密的特性（公钥加密，私钥解密）完美地解决了这个问题。服务器可以将自己的 公钥 通过明文的方式发送给客户端。客户端用这个公钥加密一个 对称密钥 后发送给服务器。即使中间人截获了这个加密后的对称密钥，他也无法解密，因为他没有服务器的 私钥。只有服务器能用自己的私钥解密，从而安全地获得对称密钥。

3. 为何不全用非对称加密？

主要原因是性能。

非对称加密的算法非常复杂，其 加密和解密的速度远远慢于对称加密。如果整个 HTTPS 通信过程都使用非对称加密，会极大地消耗服务器和客户端的计算资源，导致网页加载速度变慢，用户体验很差。因此，最佳实践是结合两者：使用非对称加密来安全地 协商 一个临时的对称密钥，然后在后续的大量数据传输中，使用这个对称密钥进行高效加密。这就是 HTTPS 的核心工作原理。

4. CA 签名认证 VS 数字证书 VS 数字签名

数字签名、数字证书、CA 签名认证 这三样东西经常被混在一起说，但它们 不是一个东西，而是三个环环相扣的概念：CA 签名认证 → 产生合法的数字证书 → 证书里面包含数字签名。

1. 数字签名： 就是“用私钥对一段数据做的签名”，任何人都能用对应的公钥验证签名是否有效。用途： 保证数据没有被篡改（完整性）、保证数据确实是“私钥持有者”发的（身份认证）。简单例子：

   • 服务器把自己的公钥信息、域名信息打个包 → 用私钥生成一个签名。
   • 客户端用服务器的公钥验证签名，能验证这份数据确实出自服务器本人。
   • 类比：数字签名 = 手写签名/盖章。别人可以看到签名，验证是你签的，但没法伪造。

2. 数字证书： 一份“带身份证明的公钥”，里面包含：服务器的公钥、服务器的域名信息（比如 www.google.com）、有效期、用途等信息、还有一个 数字签名（由 CA 生成的）。

   • 用途： 客户端拿到证书后，不仅知道“这是公钥”，还知道“这个公钥是属于哪个网站的”，解决了“公钥是谁的”这个问题。
   • 类比： 数字证书 = 身份证。身份证上写着你的名字（域名）、照片（公钥），还有公安局的盖章（CA 签名）。

3. CA 签名认证： 就是证书里的“盖章”部分 —— 证书不是服务器自己随便说“这是我的身份证”，而是交给权威机构（CA，证书颁发机构）去验证，然后 CA 用自己的私钥签名，证明这份证书是真的。

   • 流程：

     1. 服务器 → 提交公钥 + 域名信息给 CA。
     2. CA 审核（域名验证、公司验证等）。
     3. CA 用自己的 私钥 对证书做数字签名。
     4. 浏览器内置了各大 CA 的 公钥 → 可以验证证书签名是否有效。

   • 用途： 确保证书是真的，不是黑客自己伪造的，确认公钥确实属于 www.xxx.com。

   类比：CA 签名认证 = 公安局给身份证盖章。别人一看章是真的，就知道身份证不是假造的。

3. 关于 HTTPS 的一些扩展和思考

1. CA 签名流程是不是先做摘要？

是的。 CA 在给证书签名时，先对证书内容（域名、公钥、有效期等）做 Hash 得到摘要，再用 CA 私钥加密摘要 → 得到 数字签名 → 把签名 + 原始证书信息一起 发送 给客户端。证书 = 明文信息 + 签名，签名 = 用私钥加密“数据的摘要”。浏览器验证时：先用相同算法对证书内容 hash，再用 CA 公钥解密签名得到摘要，两者对比 → 确认证书没被篡改。

2. 为什么数字签名（如 CA 对证书签名）不直接用私钥加密原始数据（如证书或任意文件），而要先对数据做 Hash 生成摘要，再对摘要进行加密签名？

因为直接用私钥加密原始数据 效率极低 —— 非对称加密计算慢，且受数据长度限制，不适合大文件或频繁操作；而先对数据做 Hash 生成固定长度的“摘要”，再加密摘要，既大幅 提升签名速度，又 保证了安全性。更重要的是，Hash 摘要具备“雪崩效应”和抗篡改性：哪怕原文改动一个字节，摘要也会彻底改变，接收方通过比对摘要即可验证完整性。同时，先 Hash 还能 防御“长度扩展攻击”等密码学漏洞，确保签名机制在各种场景下（如证书、文件、消息）都安全、高效、标准化。

所以标准流程：原文 → Hash(摘要) → 用私钥加密(签名)。客户端验证时：收到原文 & 签名 → 原文重新 Hash → 用公钥解密签名 = 摘要 → 两个摘要比对一致 → 证明原文没改、签名有效。

3. 如何成为中间人（MITM）

1. ARP 欺骗

局域网里，电脑通信需要知道对方的 MAC 地址。ARP（地址解析协议）就是负责“IP ↔ MAC 地址绑定”。漏洞：ARP 没有验证机制，谁说自己是某个 IP 就信。攻击方法：黑客冒充别人：

• 主机 A 想访问主机 B → 先广播“B 的 MAC 地址谁知道？”
• 黑客抢答：“我是 B，我的 MAC 是 xxx”
• 结果 A 把流量都发给黑客，黑客再转发给 B → 黑客变中间人。

就像在班里传纸条，A 想传给 B，黑客插话说“我就是 B，把纸条给我” → 再偷偷看一眼转交给真 B。

2. ICMP 重定向攻击

ICMP 协议里有一种“重定向消息”，路由器可以告诉主机：“嘿，这个目标地址，你应该走另一条更好的路”。漏洞：ICMP 没验证，谁都能发。攻击方法：

• 黑客伪造 ICMP 消息，告诉受害者“要访问外网，请经过我这台路由器”。
• 结果受害者的所有流量都经过黑客机器。

就像问路，路人甲（黑客）冒充警察说“你要去市中心？从我家后门穿过去更快” → 结果你绕进了陷阱。

3. 假 WiFi / 假网站

• 假 WiFi（所谓的钓鱼网络）：黑客开个和真 WiFi 同名的热点，用户连上去后，所有流量都经过黑客电脑 → 可以监控/篡改数据。
• 假网站：黑客在局域网或 DNS 劫持，把 www.google.com 映射到自己控制的假服务器 → 用户以为在访问银行，其实是黑客的钓鱼网站。

就像黑客开了一家“假银行”，外观和真的一样，但柜员全是演员，用户输入账号密码就等于都交给了他。本质：中间人就是把流量骗到自己手里，再决定是“只偷听”还是“修改后转发”。

4. HTTPS 中间人（需用户配合或证书漏洞）

原理：伪造 SSL 证书，骗浏览器信任。 操作：黑客作为中间人，拦截 HTTPS 请求 伪造一个“假证书”发给客户端（如自签名或盗用 CA），如果用户点击“继续访问（不安全）”，则攻击成功，防御：浏览器会警告“证书不受信任”，我们用户不点“忽略”就攻不破。