目录
[6.HTTPS 的三组密钥](#6.HTTPS 的三组密钥)
1.HTTPS是什么
（1）定义
HTTPS 是在 HTTP 基础上加入 SSL/TLS 协议层 的安全通信协议
-
HTTP 是明文传输，数据在网络上裸奔
-
HTTPS 在应用层和传输层之间插入一个加密/解密层，所有 HTTP 报文在发送前被加密，接收后被解密
┌─────────────────────────────────────────┐
│ 应用层 (HTTP) │
├─────────────────────────────────────────┤
│ 安全层 (SSL/TLS) │ ← 加密/解密
├─────────────────────────────────────────┤
│ 传输层 (TCP) │
└─────────────────────────────────────────┘
（2）解决的问题
| 问题 | HTTP | HTTPS |
|---|---|---|
| 窃听 | 明文，可被截获 | 加密，无法直接读取 |
| 篡改 | 可被中间人修改 | 篡改会被发现 |
| 冒充 | 无法验证服务器身份 | 证书验证身份 |
2.为什么需要HTTPS
（1）运营商劫持
运营商可以在 HTTP 响应中插入广告、弹窗，甚至篡改页面内容，植入恶意代码
（2）中间人攻击场景
假 WiFi ：公共 WiFi 可截获所有 HTTP 流量
恶意路由器：篡改 DNS 或直接劫持连接
（3）问题的本质
客户端无法验证收到的公钥是否真正属于目标服务器
3.HTTPS的加密方案演进
明文 ---> 加密(密钥) ---> 密文 ---> 解密(同一密钥) ---> 明文
| 对比维度 | 密钥（广义） | 公钥 |
|---|---|---|
| 定义 | 加密解密的参数 | 非对称密钥对中可公开的那一半 |
| 包含范围 | 对称密钥、公钥、私钥 | 仅指公钥本身 |
| 是否公开 | 有的公开（公钥），有的保密（对称密钥、私钥） | 公开 |
| 用途 | 加密、解密、签名、认证 | 加密（给别人用）、验签（验证身份） |
| 数量 | 一把（对称）或一对（非对称） | 一把（公钥） |
| 操作 | 过程 | 用途 |
|---|---|---|
| 公钥加密 → 私钥解密 | 用对方的公钥加密，对方用自己的私钥解密 | 加密通信（保证机密性） |
| 私钥加密 → 公钥解密 | 用自己的私钥加密，对方用你的公钥解密 | 数字签名（保证身份认证和完整性） |
（1）仅对称加密
- 通信双方使用相同密钥
- 问题：密钥如何安全约定？一方改密钥，另一方不知道 → 鸡生蛋蛋生鸡
（2）仅非对称加密
-
服务器公钥公开，客户端用公钥加密数据，服务器使用私钥解密
-
问题1：客户端用公钥加密数据，只有服务器能用私钥解密，所以客户端→服务器安全。但如果用公钥加密，客户端没有私钥无法解密 ，使用私钥加密，任何人都可以使用公钥解密
-
问题2：效率低（非对称加密比对称加密慢数百倍）
-
问题3：公钥可能被中间人替换
（3）非对称 + 对称（混合加密）
- 用非对称加密传输对称密钥，后续用对称加密传输数据
- 仍存在的问题：客户端如何确认收到的公钥是服务器的，而不是中间人的
（4）双方都使用非对称加密
-
性能开销巨大：非对称加密算法（如RSA）计算复杂度高，加密和解密速度远慢于对称加密。
-
客户端无法验证收到的公钥是否真实属于目标服务器
（5）简介中间人攻击
中间人攻击的典型流程如下：
- 客户端首次请求服务器时，中间人截获该请求
- 中间人伪造自己的公钥，冒充服务器公钥发送给客户端
- 客户端使用中间人的公钥加密后续通信数据（如对称密钥或请求内容）
- 中间人用自己的私钥解密客户端发来的数据，获取明文，并可随意篡改
- 中间人再用真正的服务器公钥重新加密篡改后的数据，转发给服务器
- 服务器以为在与客户端通信，实际上全程被中间人监听、劫持
（6）非对称+对称+证书
| 阶段 | 核心作用 | 涉及密钥 |
|---|---|---|
| 第一阶段：证书验证 | 客户端验证服务器身份，确保获取的公钥合法 | CA 公钥（内置）、服务器证书（含服务器公钥） |
| 第二阶段：密钥协商 | 客户端生成对称密钥，用服务器公钥加密传输 | 服务器公钥（非对称） |
| 第三阶段：数据传输 | 双方使用对称密钥加密通信内容 | 会话密钥（对称） |
证书包含了服务器公钥，所以现在要相信公钥就是要相信证书是权威机构认证+没有被篡改过
详见第4点的（6）
通过引入 CA 证书体系 ，解决了此前所有方案无法规避的 "首次通信公钥可信性" 根本问题
4.数字证书与CA
（1）CA 是什么
CA（证书颁发机构） 是受信任的第三方机构，负责验证服务器身份并颁发数字证书
拥有 CA 颁发的数字证书是服务器被浏览器认定为"安全"的前提
（2）证书申请流程
- 服务器生成公私钥对，保留私钥
- 服务器创建 CSR（证书签名请求文件），包含公钥、域名、组织信息
- 服务器将 CSR 提交给 CA
- CA 审核身份（不同级别证书审核严格程度不同）
- CA 签发数字证书，安装到服务器
（3）证书的构成
┌────────────────────────────────────────────┐
│ 数字证书 │
├────────────────────────────────────────────┤
│ 明文信息： │
│ - 域名 (CN/SAN) │
│ - 服务器公钥 │
│ - 颁发者、有效期、序列号 │
├────────────────────────────────────────────┤
│ 数字签名： │
│ - 对明文信息进行哈希 → 摘要 │
│ - 用 CA 私钥加密摘要 → 数字签名 │
└────────────────────────────────────────────┘服务器私钥保存在服务器内部，CA使用自身的私钥加密摘要
（4）数字摘要与数字签名
数字摘要（又称数据指纹） 是通过哈希算法（如 SHA-256）对任意长度的数据计算得到的固定长度输出值，具有以下核心特性：确定性 （相同输入必然产生相同摘要）、单向性 （无法从摘要逆推出原始数据）和抗碰撞性（不同数据产生相同摘要的概率极低，可忽略不计）
因其能唯一标识一份数据内容，故被称为"数据指纹"
哈希碰撞概率极低是因为：
- 现代哈希算法（如 SHA-256）输出 256 位，碰撞概率约为 2⁻¹²⁸
- 实际应用中可认为不同的输入必然产生不同的摘要
- 因此，只要摘要比对一致，数据完整性就得到保证
应用场景：
-
数字签名中的摘要
-
Session ID 生成
-
文件去重（如百度网盘秒传）
用户上传文件
↓
计算文件哈希值（数据摘要）
↓
服务端比对数据库中已有文件的哈希
↓
如果已存在 → 不重复存储，建立软链接（秒传）
如果不存在 → 正常上传存储
数字签名 = 数据摘要（哈希值）+ 非对称加密
- 对原始数据（如证书中的明文信息）进行哈希运算，得到固定长度的数据摘要
- 使用发送方的私钥对该摘要进行加密，得到数字签名
- 将数字签名附加在原始数据后面，形成完整的签名数据包
数字签名的核心作用
- 防篡改：数字签名将数据内容与签名结果绑定，任何对原始数据的修改都会导致验证失败
- 防冒充：数字签名使用发送方的私钥加密，而私钥只有发送方本人持有。能够用发送方公钥正确解密的签名，必然是由对应私钥持有者生成的
先哈希再加密的原因
| 维度 | 直接加密 | 哈希+加密 |
|---|---|---|
| 签名大小 | 与原文等大 | 固定长度（如 256 位） |
| 加密速度 | 慢 | 快（仅加密小尺寸摘要） |
| 传输开销 | 大 | 小 |
| 验证效率 | 低 | 高 |
（5）客户端验证证书
证书验证流程：
1. 收到证书，拆分为：明文信息 + 数字签名
2. 对明文信息做哈希（如 SHA-256）→ 得到摘要 A
3. 用浏览器内置的 CA 公钥解密数字签名 → 得到摘要 B
4. 比对摘要 A 与摘要 B
- 相等 → 证书未被篡改
- 不等 → 证书被篡改，拒绝连接
5. 验证其他内容：
- 域名是否匹配
- 证书是否在有效期内
- 证书是否被吊销（CRL/OCSP）摘要内容在网络传输时必须加密形成数字签名 ，核心原因在于只有加密才能保证签名的唯一性与权威性 ：如果仅传输明文的哈希值，中间人篡改证书内容后完全可以重新计算哈希并替换，浏览器无法察觉；而通过 CA 私钥加密哈希形成签名后，由于私钥仅 CA 持有，中间人无法伪造有效签名，浏览器用 CA 公钥解密验证时，任何篡改都会导致哈希比对失败。加密将"谁能生成有效签名"与"谁拥有私钥"绑定，这是数字签名不可伪造的根本保障
证书由明文信息与数字签名两部分组成，这种分离设计的目的在于验证完整性：浏览器对明文信息计算哈希得到 Hash_A，同时用 CA 公钥（浏览器内置）解密数字签名得到 Hash_B，若两者一致则证明证书未被篡改且确由受信任的 CA 签发；反之说明证书已被修改或来源不可信，浏览器会发出安全警告
（6）中间人无法进行有效攻击
| 攻击方式 | 攻击行为 | 防御机制 | 结果 |
|---|---|---|---|
| 只修改明文 | 篡改证书中的域名或公钥 | 浏览器重新计算明文哈希，与解密签名得到的哈希比对 | 哈希比对失败，浏览器报警 |
| 既修改明文又修改签名 | 替换或篡改数字签名 | 签名无法用 CA 公钥正确解密，或解密后与明文哈希不匹配 | 签名验证失败，浏览器报警 |
| 替换成自己的证书 | 用中间人自己的证书冒充 | • 域名不匹配 • 浏览器不信任该证书（除非用户忽略警告） | 浏览器显示"不安全"，阻止连接 |
| 重新签发合法证书 | 试图伪造 CA 签发的证书 | 需要 CA 的私钥才能生成有效签名 | 中间人没有 CA 私钥，无法伪造 |
在 HTTPS 的信任体系中，私钥即权力：浏览器只信任由 CA 私钥签发的证书，而 CA 私钥被严格保护，仅有权威 CA 机构持有；中间人因为没有 CA 私钥，既无法伪造合法证书，也无法通过篡改或替换证书来绕过验证。因此，只有拥有私钥的 CA 才有资格签发证书，这是中间人无法进行有效攻击的根本原因
5.完整流程图
6.HTTPS 的三组密钥
HTTPS 工作过程中涉及三组密钥：
| 序号 | 密钥类型 | 核心作用 |
|---|---|---|
| 第一组 | 非对称密钥（证书） | 确保证书未被篡改，确认服务器身份并传递服务器公钥 |
| 第二组 | 非对称密钥（密钥交换） | 使用服务器公钥加密对称密钥 |
| 第三组 | 对称密钥（会话密钥） | 实际加密传输数据 |
核心思想 ：所有机制都是为了安全地将对称密钥传递给服务器，其他都是辅助
7.HTTPS的安全性边界
- HTTPS 能防止网络层窃听（抓包看不到明文）、中间人篡改（篡改会被发现）、服务器冒充（证书验证）
- HTTPS 不能防止客户端直接攻击服务端（SQL 注入、XSS 等）、服务端漏洞（代码注入、配置错误）、用户主动忽略证书警告（钓鱼网站）、已安装的恶意根证书（企业监控、恶意软件）
- 安全不是绝对的，而是相对的 。当 攻破成本 > 攻破收益 时，该协议可认为是安全的。随着算力提升，旧算法（如 MD5、SHA-1）可能被攻破，SSL/TLS 是公开标准，树大招风，需持续更新版本和加密套件，推荐使用 TLS 1.2 或 TLS 1.3，禁用过时加密套件