HTTPS

一、https是什么

相比于默认不加密的http协议，HTTPS协议在 HTTP 的基础上加入了加密层，确保数据在传输过程中不会被窃取或篡改。

为什么要选择加密，加密是为了防止数据在传输过程中被窃听、篡改或冒充，保护用户的隐私和安全。

例如运营商劫持：

常见的加密形式

1. 对称加密

一句话定义 ：加密和解密使用同一个密钥的加密方法。

• 常见算法：AES、DES、3DES、RC2 等。

• 优点：算法公开、计算量小、加密速度快、效率高，适合加密大量数据。

• 缺点：密钥必须安全地传递给对方，如果密钥在传输过程中被截获，加密就失效了。

• 生活类比：用一把锁锁上箱子，再把这把锁的钥匙寄给朋友，朋友用同一把钥匙开锁。

---

2. 非对称加密

一句话定义 ：使用一对密钥------公钥 （可公开）和私钥（保密），公钥加密时只能用私钥解密，私钥加密时只能用公钥解密。

• 常见算法：RSA、DSA、ECDSA 等。

• 优点：无需传输私钥，安全性高，且可用来实现数字签名。

• 缺点：算法复杂，加解密速度比对称加密慢很多。

• 生活类比：朋友寄来一把打开的锁（公钥），我把文件放进箱子用这把锁锁上，只有朋友手里保留的钥匙（私钥）才能打开。

---

3. 数据摘要（数据指纹）

一句话定义 ：通过哈希函数将任意长度的数据压缩成固定长度的短字符串，不可逆、防篡改。

• 常见算法：MD5、SHA-1、SHA-256 等。

• 特点：

  • 不可逆：无法从摘要反推原文。

  • 雪崩效应：原文哪怕改一个字，摘要也会完全不同。

  • 可能碰撞：不同原文生成相同摘要的概率极低，但不为零。

• 用途：校验文件完整性、存储用户密码（存摘要而非明文）、为数据生成"指纹"。

• 生活类比：一份文件的"数字指纹"------文件变了，指纹就变了，但指纹本身无法还原文件内容。

---

4. 数字签名

一句话定义 ：对数据的摘要 用发送者的私钥 进行加密，得到的结果就是数字签名，用于验证数据的完整性 和来源真实性。

• 原理：

  1. 发送方对原文计算摘要（哈希值）。

  2. 用发送方的私钥加密这个摘要 → 得到数字签名。

  3. 接收方用发送方的公钥解密签名，得到摘要1；再对收到的原文计算摘要2。

  4. 比较摘要1和摘要2：如果相同，说明文件未被篡改且确为发送方所签。

• 特点 ：同时提供不可否认性 （只有私钥持有者能生成）、真实性 和完整性。

• 生活类比：在纸质合同上盖一个无法伪造的私章（签名），对方用我的公印（公钥）验证这章确实是我盖的，且合同内容没被改过。

HTTPS的加密过程

先直接给出结论，目前主流的https加密形式是采用非对称加密+对称加密+证书认证的形式。

加密组合

根据上面的加密方式，我们可以得到只使用对称加密、只使用非对称加密、双方分别使用非对称加密、非对称加密+对称加密这几种加密形式。

1. 只使用对称加密

工作原理 ：

通信双方预先共享同一个密钥，发送方用该密钥加密数据，接收方用同一个密钥解密。

优点：

• 加解密速度快，适合大量数据。

• 算法简单，计算开销小。

缺点：

• 密钥分发困难：双方如何安全地获得同一个密钥？如果通过网络传输密钥，容易被拦截。

• 扩展性差：与 N 个不同的人通信需要 N 个不同密钥，管理复杂。

• 无法提供身份认证：无法确定对方是否真的是你希望通信的人。

---

2. 只使用非对称加密

工作原理 ：

每个用户拥有一对密钥（公钥和私钥）。公钥公开，私钥保密。发送方用接收方的公钥 加密数据，接收方用自己的私钥 解密。

（也可以反过来，用私钥加密、公钥解密，但那常用于数字签名，而非保密通信。）

优点：

• 无密钥分发问题：公钥可以公开传输，不需要安全通道。

• 可提供身份认证：私钥签名可证明身份。

• 简化密钥管理：只需维护自己的私钥和对方的公钥。

缺点：

• 速度极慢：比对称加密慢几个数量级（通常慢 100--1000 倍），不适合加密大量数据。

• 受限于消息长度：非对称加密能加密的明文长度有限（例如 RSA 最多加密密钥长度大小的数据）。

---

3. 双方分别使用非对称加密（双向非对称加密）

工作原理 ：

通信双方各自生成一对密钥（Alice: 公钥 A_pub, 私钥 A_priv；Bob: 公钥 B_pub, 私钥 B_priv）。

发送消息时，Alice 用 自己的私钥 签名（可选），并用 Bob 的公钥 加密消息。Bob 收到后，先用 自己的私钥 解密，再用 Alice 的公钥 验证签名。

"双方分别使用"强调的是：通信双方都可以向对方发送加密消息，每条消息都使用对方公钥加密，且（通常）使用自己私钥签名，实现双向安全通信。

优点：

• 双向安全性：Alice 发给 Bob 的消息只有 Bob 能解密；Bob 发给 Alice 的消息只有 Alice 能解密。

• 提供防抵赖和身份认证（如果加上签名）。

缺点：

• 性能问题加倍：每条消息都要执行两次非对称操作（加密/解密）以及可能的签名/验签，速度更慢。

• 公钥分发仍需可信渠道：虽然公钥可以明文传输，但需防止中间人攻击（需要证书或凭信任第一次使用）。

---

4. 非对称加密 + 对称加密（混合加密系统）

工作原理 ：

这是目前几乎所有安全通信协议（HTTPS、SSH、PGP、IPsec 等）采用的标准模式：

1. 握手阶段 ：使用非对称加密（或密钥协商算法，如 Diffie‑Hellman）安全地协商出一个临时对称密钥。

   • 典型做法：客户端生成一个随机数，用服务器的公钥加密后发送；服务器用私钥解密得到该随机数，双方用该随机数派生出对称密钥。

2. 数据传输阶段：用协商好的对称密钥加密所有实际数据，保证速度和安全性。

优点：

• 集两者之长：非对称解决了密钥分发和身份验证的问题；对称保证了高性能。

• 前向安全性（使用 DHE/ECDHE 时）：即使服务器的长期私钥泄露，过去的会话也无法被解密。

• 自动密钥更新：每次会话可以独立生成临时对称密钥，互不影响。

缺点：

• 实现复杂度高：需要同时处理证书、密钥协商、加密套件协商等。

• 仍需证书体系：保证服务器的公钥真实可信（否则会遭受中间人攻击）。

中间人攻击

1. 客户端 → 中间人

   • 客户端本以为自己在直接连接服务端，但实际首先到达的是攻击者（中间人）。

   • 图中标注 "伪造公钥 M"：表示中间人将自己伪造的公钥 M 发给了客户端（而不是服务端的真实公钥 S）。

2. 中间人 ↔ 服务端

   • 中间人同时与真正的服务端建立连接，获取服务端的 "原公钥 S"。

   • 服务端不知道中间人的存在，以为在和客户端通信。

3. 客户端使用假公钥加密

   • 客户端收到伪造的公钥 M 后，生成临时对称密钥 X，并用 M 加密 X，发送给"服务端"（实际到达中间人）。

   • 图中 "M 解密拿到 X"：中间人用自己的私钥 M' 解密，得到 X。

4. 中间人重新加密并转发

   • 中间人用之前拿到的服务端真实公钥 S 重新加密 X。

   • 然后将加密后的报文发送给真正的服务端。

   • 图中 "S 重新加密 X" 即指这一步。

5. 服务端解密并通信

   • 服务端用自己的私钥 S' 解密得到 X，以为双方已完成安全协商。

   • 此后客户端与服务端之间看似加密的通信（图中 "加密通信"），实际全部经过中间人转发。

6. 全程窃听/篡改

   因为中间人已经掌握了对称密钥 X，所以它可以**"全程窃听/篡改"** ：

   • 甚至完全伪造消息。

   • 修改数据后再重新加密发送（篡改）。

   • 解密每一包数据（窃听）。

CA认证

CA 认证 （Certificate Authority，数字证书认证机构）是解决"中间人攻击"中身份验证问题 的关键基础设施。它的核心作用就是：为公钥的真实性提供第三方担保。

CA 的工作流程

1. 网站申请证书

   网站运营者（比如 bank.com）向 CA 机构提交身份资料（如域名所有权、营业执照等），并上传自己的公钥 S。

2. CA 验证身份

   CA 通过各种手段（域名验证、组织验证等）确认申请者确实是该网站的合法拥有者。

3. CA 签发证书

   验证通过后，CA 使用自己的私钥 对网站的公钥 S 以及网站相关信息（域名、有效期等）进行数字签名 ，生成一份 SSL/TLS 证书 。

   这个证书绑定了：网站的身份信息 + 网站的公钥 S + CA 的签名。

4. 网站部署证书

   网站把得到的证书安装在自己的服务器上。

5. 客户端（浏览器）验证证书

   • 浏览器内置了受信任的 CA 的根证书（包含 CA 的公钥）。

   • 当浏览器访问 https://bank.com 时，服务器会把证书发给浏览器。

   • 浏览器用 CA 的公钥去验证证书上的数字签名------如果签名正确，说明证书确实是这个 CA 签发的，且内容未被篡改。

   • 浏览器再检查证书里的域名是不是正在访问的域名、有没有过期等。

   • 验证通过后，浏览器才相信证书里的公钥 S 是真的属于 bank.com，然后用这个公钥进行后续的密钥协商。

CA证书，数字签名

1.生成证书（CA 签名）

• 数据 = 网站的身份信息（如域名 bank.com）+ 网站的公钥 S + 有效期等。

• 散列 → 摘要。

• 签名 = CA 用自己的私钥对该摘要加密。

• 证书 = 数据 + CA 的签名。

2. 验证证书（浏览器）

• 浏览器内置了 CA 的公钥。

• 浏览器收到证书后，提取其中的"数据"部分，做散列得到摘要 A。

• 用 CA 公钥解密证书上的签名，得到摘要 B。

• 对比 A 与 B：

  • 一致 → 证书确实是该 CA 签发且未被篡改，可以信任证书里的公钥 S 属于 bank.com。

  • 不一致 → 证书非法，拒绝连接。

中间人无法伪造证书，原因正在于 数字签名的不可伪造性：

• 攻击者可以替换证书里的"数据"（例如把公钥 S 换成自己的假公钥 M），但一旦修改数据，散列值就会变。

• 要生成新的合法签名，攻击者需要 CA 的私钥 ------ 这是不可能的。

• 攻击者也无法凭空捏造一个证书，因为没有 CA 私钥就无法生成能被浏览器验证通过的签名。

非对称加密+对称加密+证书认证

• 公钥加密，私钥解密 → 保证机密性（只有私钥持有者能读）。

• 私钥签名（签名者用私钥对数据的哈希值进行加密），公钥验签 → 保证身份真实性和数据完整性（谁签名谁负责）。

阶段 1：证书认证（验证服务器身份）

• CA 私钥 （CA 持有）：签名 功能。

  CA 对服务器的"域名 + 公钥 S"等信息进行数字签名，生成证书。

• CA 公钥 （浏览器内置）：验签 功能。

  浏览器用 CA 公钥验证证书上的签名，确认证书没有被篡改且确实是该 CA 签发。

• 结果 ：客户端信任证书里的 服务器公钥 S。

阶段 2：安全传递临时密钥（Pre-Master Secret）

• 服务器公钥 S （从证书中取出）：加密 功能。

  客户端用这个公钥加密 Pre-Master Secret。

• 服务器私钥 S' （服务器保密）：解密 功能。

  服务器用私钥解密密文，得到 Pre-Master Secret。

阶段 3：生成对称会话密钥（没有非对称密钥参与）

• 双方用 Pre-Master Secret + 随机数，通过算法派生出一组对称密钥（用于后续加密）。

阶段 4：对称加密通信

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

这套流程如何防范中间人攻击：

攻击行为	依赖的密钥功能	为什么失败
替换证书中的公钥 S 为自己的公钥 M	攻击者想破坏 CA 私钥签名 → CA 公钥验签 的信任链	修改证书后，CA 签名失效。浏览器用 CA 公钥验签 → 失败 → 拒绝连接
伪造一个假证书	攻击者想冒充 CA 用私钥签名	攻击者没有 CA 私钥，无法生成合法签名
窃听客户端发送的 Pre-Master Secret 密文	攻击者想解密	密文是用服务器公钥 S 加密的。攻击者没有服务器私钥 S' → 无法解密
篡改后续对称加密的数据	对称加密	现代对称加密带完整性校验（如 AES-GCM），篡改会被检测