为什么HTTP不安全?
1. 明文传输（相当于写明信片）
HTTP 的所有数据（包括你的密码、银行卡号）在网络上都是以明文（Plaintext） 形式传输的
- 风险： 从你的电脑到服务器的路径上，经过的每一个路由器、Wi-Fi 热点、运营商基站，都可以轻易地拦截并“看懂”这些数据 这就像你寄了一张没装信封的明信片，邮递员和路人都能看见内容
2. 无法验证身份（相当于被冒充）
HTTP 协议不验证通信方的身份
- 风险： 你以为你在访问
google.com，但实际上可能是黑客伪造的一个假网站（钓鱼网站） 你发出的请求被黑客拦截，黑客假装成服务器给你回应，你完全无法察觉
3. 数据无法防篡改（相当于被涂改）
因为是明文且无校验，数据在传输过程中很容易被修改
- 风险： 你请求在网页上看新闻，中间人攻击者（Man-in-the-Middle）可以拦截数据包，在里面插入一段恶意的广告代码或病毒脚本，然后再发给你 你收到的页面已经被“加料”了
为什么 HTTPS 可以保证安全？
在 HTTP 的基础上加入了一个安全层：SSL/TLS 协议
1. 只有你能看懂（加密 / Encryption）—— 解决窃听
HTTPS 使用了混合加密机制，结合了非对称加密和对称加密的优点：
- 非对称加密（公钥/私钥）： 在建立连接的初期（握手阶段），服务器把“公钥”给你，你用公钥加密一个“随机数”发给服务器 这把“锁”只有服务器手里的“私钥”能打开 这确保了密钥交换的安全性
- 对称加密（共享密钥）： 一旦双方安全地拿到了同一个“随机数”（会话密钥），之后的实际数据传输就全部用这个密钥进行高效率的对称加密
- 结果： 即使黑客截获了数据包，看到的也是一堆乱码，因为他没有解密的钥匙
2. 只有你是真的（身份验证 / Authentication）—— 解决冒充
怎么证明发给你公钥的服务器就是真的淘宝或谷歌，而不是黑客呢？这就靠 数字证书（Certificate）
- CA 机构背书： 服务器必须向权威的第三方机构（CA，证书授权中心）申请证书 证书里包含了服务器的网址、公钥以及 CA 的数字签名
- 浏览器校验： 你的浏览器和操作系统内置了受信任的 CA 列表 当你访问 HTTPS 网站时，浏览器会检查证书：是不是受信任的 CA 签发的？证书有没有过期？证书上的网址和你要访问的网址一致吗？
- 结果： 如果证书有问题，浏览器会直接报警（显示红色的“不安全”），防止你被钓鱼网站欺骗
3. 只有原装未动（数据完整性 / Integrity）—— 解决篡改
HTTPS 在传输数据时，会给数据加上一个摘要（Digest/Hash）
- 哈希算法： 就像给数据按了一个“指纹”。如果黑客在传输途中修改了哪怕一个标点符号，计算出来的指纹就会完全不同
- 校验机制： 接收方收到数据后，会重新计算指纹并与传送过来的指纹对比。如果不一致，说明数据被篡改了，丢弃该包
- 结果： 确保你看到的内容就是服务器原本发送的内容，没有被运营商劫持插入广告
总结对照表
| 特性 | HTTP | HTTPS |
| 数据形态 | 明文（所有人可见） | 密文（乱码，只有持有密钥者可见） |
| 安全性 | 极低，易被窃听、篡改、劫持 | 高，防窃听、防篡改、防伪装 |
| 连接建立 | 简单，TCP 三次握手后直接传数据 | 复杂，TCP 握手后还需 SSL/TLS 握手 |
| 端口 | 默认 80 | 默认 443 |
| 成本 | 免费 | 需要购买或申请 SSL 证书（也有免费的） |
剧本演绎
C: 我要给你数据，但我怕被劫持
S: 给你个带锁的盒子（公钥），用这个盒子把那个东西”（随机数/密钥）装进去发过来
- (注意：S 说的是只装“那个东西”，先别急着装“数据”！)
C: 我生成了“那个东西”，放进盒子里锁好，发过去（此时真正的数据还在我手里，没发！）
S: 我用钥匙（私钥）打开盒子，拿到了“那个东西”
C, S: 【现在开始】 好，现在我们俩都有“那个东西”了
C: 我把“真正的数据”用“那个东西”加密，发给你
S: 我用“那个东西”解密，看到了数据