HTTPS协议
HTTP传输的隐患
在传统的HTTP协议下，访问网页的数据是明文传输的。这意味着从客户端到服务器的路径上，任何一个中间节点（如路由器、运营商设备）都可以轻易窥探甚至篡改数据。
场景重现：下载站的无奈
本来想下载QQ，当请求经过运营商设备时，运营商发现这是一个下载链接，可能会悄悄把响应包里的下载链接替换成QQ浏览器的安装包。
QQ服务器 运营商设备 (中间人) 客户端 QQ服务器 运营商设备 (中间人) 客户端 发现下载链接！ 篡改响应内容 下载了并不想要的东西 HTTP请求：获取下载链接 转发请求 返回：QQ下载链接 返回：QQ浏览器下载链接
这就是HTTP明文传输的隐患。虽然HTTP协议有URL和Header/Body之分，但在HTTPS登场前，甚至 Referer 这样的头部信息也会被用来追踪或被篡改。为了反制这种劫持，国内厂商开始全面推动从HTTP迁移到HTTPS。
对称加密
对称加密原理
对称加密是双方使用同一把密钥进行加解密。这是速度最快、效率最高的加密方式，适合加密网页内容等大量数据。
服务器 客户端 服务器 客户端 第一步：怎么把密钥安全给对方？ ⚠️ 这个"明文密钥"在网络上传输 任何人都可能截获 把密钥明文发给你
被动窃听
致命缺陷：这把密钥必须让双方都知道，但在网络上一传输，就可能被窃听。如果密钥在传输时被偷走，后面的加密就形同虚设。
服务器 黑客 客户端 服务器 黑客 客户端 场景：客户端想把对称密钥发给服务器 没办法，只能明文发给对方 🔓 直接截获密钥！ ⚠️ 双方以为只有彼此知道密钥 但实际上黑客已拿到 Key 后续所有加密通信都能解密 后续通信（形同虚设） 用 Key 解密，看完内容 甚至可以篡改 再次解密，窃取响应内容 生成对称密钥 Key = 888888 发送：Key = 888888 假装正常转发：Key = 888888 用 Key 加密的数据 篡改后的数据（或不改直接转发） 用 Key 加密的响应 转发响应（或篡改后转发）
非对称加密
非对称加密原理
非对称加密用一对密钥：公钥 （可公开）和私钥（服务器自己藏好）。
核心特性：公钥加密，私钥解密。用公钥加密的内容，只有对应的私钥能解开。
密钥协商过程：
- 客户端向服务器请求公钥。
- 客户端在本地生成一个临时对称密钥（比如
888888）。 - 客户端用公钥 加密
888888，把密文发给服务器。 - 服务器用私钥 解密，得到
888888。 - 之后双方用
888888进行对称加密通信。
服务器 客户端 服务器 客户端 ③ 本地生成临时对称密钥 Key = 888888 ④ 用 pub1 加密 Key ⑥ 用私钥 pri1 解密，得到 Key = 888888 双方都持有 888888，开始对称加密通信 ① 请给我公钥 ② 这是我的公钥（pub1） ⑤ 发送密文（pub1加密后的Key）
中间人攻击
上面的流程有一个逻辑漏洞：客户端无法判断收到的公钥是真还是假。
如果黑客在第一步介入：
- 客户端请求公钥时，黑客截住请求，返回自己的假公钥
pub2。 - 客户端用
pub2加密对称密钥Key并发出去。 - 黑客用自己的私钥
pri2解密，拿到Key。 - 黑客再向服务器索要真公钥
pub1，用pub1加密Key转发给服务器。
结果：客户端和服务器以为在直接对话，实际上中间多了一个能看光所有内容的黑客。
服务器 黑客 客户端 服务器 黑客 客户端 ③ 生成对称密钥 Key ④ 用假公钥 pub2 加密 Key ⑥ 用私钥 pri2 解密，窃取到 Key ⑨ 用真公钥 pub1 重新加密 Key 双方以为在安全通信，实则 Key 已泄露 ① 请求公钥（被黑客截获） ② 假公钥 pub2 ⑤ 发送密文 ⑦ 请求真公钥 ⑧ 真公钥 pub1 ⑩ 转发密文
数字证书
数字证书原理
为了解决怎么确认公钥是真的这个问题，引入了 CA（证书颁发机构） 和 数字证书。
服务器不再直接发送裸公钥，而是去 CA 申请一张证书。证书包含：
- 颁发机构（CA）
- 有效期
- 服务器域名
- 服务器公钥
- 数字签名（CA 用自己的私钥对上述内容做的加密签名）
客户端验证证书的两步操作：
- 自己算一遍 ：对证书的明文部分（域名、有效期、公钥等）用约定的 Hash 算法算出校验和 A。
- 解密比一遍 ：用操作系统内置的 CA 公钥 解密证书中的数字签名，得到校验和 B。
如果 A 等于 B，说明证书没有被篡改，里面的公钥确实来自可信服务器。
证书验证
证书申请
是
否
服务器信息
域名+公钥
计算Hash摘要
CA用自己的私钥加密摘要
生成数字签名
组成数字证书
收到数字证书
拆分为两部分
明文部分
域名/有效期/公钥
数字签名
用相同Hash算法
算出 校验和A
用CA公钥解密
得到 校验和B
校验和A = 校验和B？
✅ 证书可信
取出服务器公钥
❌ 证书被篡改
断开连接
🔍 客户端验证 相当于 你验房产证
🔏 CA签发证书 相当于 政府盖钢印
✅ 相等
❌ 不等
📄 证书明文
房主：张三
地址：XX小区
公钥：889
📏 算字数 Hash
得：375字
🔨 用CA私钥
把 375字 压成钢印
这就是 数字签名
📜 最终证书
明文 + 钢印
📜 收到证书
✂️ 拆成两部分
📄 明文
房主：张三
地址：XX小区
公钥：889
🔏 钢印 数字签名
📏 自己算字数 Hash
得：校验和A = 375
🔎 用CA公钥
看钢印里的隐藏文字
得：校验和B = 375
⚖️ A == B ?
📄 证书可信
张三、889 都是真的
没被涂改过
🚫 证书被篡改
骗子把张三改成了李四
断开连接！
CA的公钥是怎么安全地到我们手上的？
CA机构的公钥不是从网络传输获取的，而是在操作系统出厂时就预置好的。只要不安装被篡改的系统，这一层信任是固化的。
完整的 HTTPS（HTTP+TLS） 握手流程
把以上技术组合起来，就是 HTTPS 建立连接的全过程：
- 防篡改：通过 CA 数字证书体系，确保拿到的公钥是真的。
- 安全传输密钥：用非对称加密，安全地把对称密钥送到对方手里。
- 高效通信：之后切换到对称加密，保证大数据量传输的速度。
CA Server Client CA Server Client 提前准备 TLS 握手阶段 安全传输阶段 提交资料申请证书 颁发含数字签名的证书 发起HTTPS连接 返回数字证书 用内置CA公钥验签 确认公钥可靠 生成临时对称密钥 Key 用服务器公钥加密 Key 并发送 用私钥解密获得 Key 对称加密报文 (使用Key) 对称加密报文 (使用Key)
为什么不全程用非对称加密？
因为非对称加密计算量极大，只适合加密小数据（如对称密钥）。用它加密整个网页，速度会慢到无法接受。
TLS加密了哪些内容？
TLS 加密层
请求/响应行
GET /index.html HTTP/1.1
HTTP/1.1 200 OK
HTTP 头部
Host: example.com
Cookie: session=xxx
User-Agent: ...
Authorization: Bearer ...
请求/响应体
网页内容
表单数据 / JSON / 图片
密码、账号等敏感信息
在 HTTPS 中，整个报文都被加密后放进 TCP 传输，外面能看到 IP 、域名和端口，但看不到里面任何一行内容。