HTTPS详解：加密机制、工作流程、CA证书与中间人攻击防护

文章目录

[1. 前言](#1. 前言)
- [1.1. 什么是HTTPS](#1.1. 什么是HTTPS)
- [1.2. 什么是加密](#1.2. 什么是加密)
- [1.3. 常见的加密方式](#1.3. 常见的加密方式)
- - [① 对称加密](#① 对称加密)
  - [② 非对称加密](#② 非对称加密)
- [1.4. 数据摘要（数据指纹）](#1.4. 数据摘要（数据指纹）)
- - [① 实例：软件分发中的数据摘要](#① 实例：软件分发中的数据摘要)
- [1.5.1 一个小问题](#1.5.1 一个小问题)
[2. HTTPS 工作流程探究](#2. HTTPS 工作流程探究)
- [2.1. 方案1 - 只使用对称加密](#2.1. 方案1 - 只使用对称加密)
- [2.2. 方案2 - 只使用非对称加密](#2.2. 方案2 - 只使用非对称加密)
- [2.3. 方案3 - 双方都使用非对称加密](#2.3. 方案3 - 双方都使用非对称加密)
- [2.4. 方案4 - 非对称加密 + 对称加密](#2.4. 方案4 - 非对称加密 + 对称加密)
[3. 中间人攻击](#3. 中间人攻击)
[4. 证书引入](#4. 证书引入)
- [4.1. CA认证](#4.1. CA认证)
- [4.2. 数据签名与数据验证](#4.2. 数据签名与数据验证)
- [4.3. 方案5 - 非对称加密 + 对称加密 + 证书认证](#4.3. 方案5 - 非对称加密 + 对称加密 + 证书认证)
[5. 部分问题](#5. 部分问题)
[6. 总结](#6. 总结)
- [6.1. HTTPS 总体流程](#6.1. HTTPS 总体流程)
- [6.2. HTTPS 涉及的三组密钥](#6.2. HTTPS 涉及的三组密钥)

1. 前言

1.1. 什么是HTTPS

同HTTP协议，HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层；

HTTP 协议内容都是按照文本的方式明文传输的，就导致在传输过程中可能会出现被篡改的情况；

1.2. 什么是加密

加密就是把明文（要传输的信息）进行一系列变换，生成密文；
解密就是把密文再进行一系列变换, 还原出明文；

在这个加密和解密的过程中, 通常需要一个/多个中间数据，辅助进行该过程，这个数据被称为密钥

由于 HTTP 的内容是明文传输的，明文数据会经过多个物理节点，包括：

路由器、Wi-Fi 热点、通信服务运营商、代理服务器

在传输过程中，如果信息被劫持，传输的内容就会完全暴露。劫持者不仅可以窃取这些信息，还可能篡改传输的内容，而双方在不知情的情况下仍然继续交流。这种情况被称为 中间人攻击。

因此，我们需要对信息进行加密，以保护数据的安全性和完整性。

比如多数人都遇到过的情况：

当我想在浏览器下载一个软件A时，但是获取下载链接的请求被窃取了，中间人就篡改了服务器的响应内容，从而变成了，下载软件A结果却下载了软件B（运营商想让用户从软件B下载）

如果上述这种情况发生到了实际情况，其危险性是很大的。

1.3. 常见的加密方式

以下是经过格式化的关于对称加密的文本：

① 对称加密

定义：
- 对称加密是一种采用单钥密码系统 的加密方法，同一个密钥可以同时用作信息的加密和解密。这种加密方法也称为单密钥加密，其特征是加密和解密所用的密钥是相同的。
常见对称加密算法（了解）：
- DES、3DES、AES、TDEA、Blowfish、RC2
特点：
- 算法公开、计算量小、加密速度快、加密效率高

对称加密其实就是通过同一个 "密钥" 将明文加密成密文，并且也能将密文解密回明文。

下面举一个简单的加密算法的例子：

对于明文 HELLO，密钥为 3，加密的过程为把每一位向后移3位，则：

HELLO ------> KHOOR

解密的过程同理，反过来向左移动即可；

② 非对称加密

定义：
- 非对称加密需要两个密钥：公开密钥 （Public Key，简称公钥）和 私有密钥（Private Key，简称私钥）。
- 公钥和私钥是成对存在的。
常见非对称加密算法（了解）：
- RSA、DSA、 ECDSA
特点：
- 算法强度复杂，安全性依赖于算法与密钥。
- 由于算法复杂，加密和解密的速度通常比对称加密要慢得多。
加密与解密过程：
1. 通过公钥对明文加密，得到密文。
2. 通过私钥对密文解密，得到明文。
或者反向使用：
1. 通过私钥对明文加密，得到密文。
2. 通过公钥对密文解密，得到明文。

非对称加密的实现逻辑一般较为复杂，涉及数学思想，这里了解其是怎样工作的：

小明想给朋友小红发送一封私密邮件。

生成密钥对：小红首先生成一对密钥------一个公钥和一个私钥。公钥可以分享给任何人，而私钥则要保密。
发送公钥：小红把公钥发送给小明。小明可以将这个公钥视作一个锁。
加密邮件：小明写好邮件后，用小红的公钥（锁）对邮件内容进行加密。只有拥有相应私钥的人才能打开这个锁。
发送邮件：小明把加密后的邮件发送给小红。
解密邮件：小红收到邮件后，用自己的私钥（钥匙）解锁邮件，读取内容。

即使其他人截获了加密的邮件，因为没有小红的私钥，他们也无法解读邮件内容。

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

数字指纹，也称为数据摘要，其基本原理是利用单向散列函数（Hash 函数）对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可用其判断数据是否被篡改。

常见的摘要算法
- MD5 、SHA1 、SHA256 、SHA512

这些算法将无限的输入映射到有限的输出，因此可能会发生碰撞（即两个不同的信息可能产生相同的摘要，尽管这种情况的概率非常低）。

摘要特征
与加密算法的区别在于，摘要严格意义上不是加密，因为没有解密的过程。
从摘要反推原始信息非常困难，通常用于数据对比。

下面举一个数据摘要的使用场景实例：

① 实例：软件分发中的数据摘要

场景描述：

在软件分发过程中，开发者通常需要确保用户下载的软件包没有被篡改或损坏。为了确保软件包的完整性和安全性，开发者会生成该软件包的摘要（哈希值），并将其与软件包一起提供给用户。

数据摘要的过程

生成软件包：
- 开发者打包软件并生成一个安装文件，例如 example_1.0.zip。
计算哈希值：
- 使用哈希算法（如 SHA-256）计算软件包的摘要：
  bash 复制代码
```
sha256sum example_1.0.zip > example_1.0.zip.sha256
```
- 这将生成一个文件 example_1.0.zip.sha256，其中包含软件包的 SHA-256 摘要，例如：
  bash 复制代码
```
3f4d3c1a8ebdbe9ee30e4b4be2b840df0ed5c91c75c6b8792bc4c36e76fdd16a  example_1.0.zip
```
发布软件和摘要：
- 将 example_1.0.zip 和 example_1.0.zip.sha256 一同发布到网站上。
用户下载软件：
- 用户从网站上下载 example_1.0.zip 和 example_1.0.zip.sha256。
验证下载的完整性：
- 用户下载后，使用相同的哈希算法计算自己下载的 example_1.0.zip 文件的 SHA-256 摘要，并与 example_1.0.zip.sha256 文件中的摘要进行比较：
  bash 复制代码
```
sha256sum -c example_1.0.zip.sha256
```
检查结果：
- 如果计算的哈希值与存储在 example_1.0.zip.sha256 文件中的值匹配，则说明下载的文件没有被篡改，用户可以安全地安装软件。

作用

根据这个例子，我们可以分析出数据摘要的作用：

数据完整性：确保用户下载的软件文件没有被损坏或篡改。任何修改都会导致摘要不匹配，用户能够及时发现问题。
安全性：在分发软件时，通过提供摘要可以防止恶意软件的插入。如果攻击者试图修改软件包，哈希值的变化将使用户注意到潜在的安全风险。
用户信任：通过提供数据摘要，开发者可以增强用户对软件的信任，因为用户可以验证所下载的软件确实是官方发布的版本。

总结

在软件分发过程中使用数据摘要是一种有效的方式来保证数据的完整性和安全性。通过计算和验证哈希值，用户可以放心地下载和使用软件，降低了受到恶意篡改的风险。

1.5.1 一个小问题

根据上面对加密的了解，不妨思考下面的问题：

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

对 HTTP 进行对称加密可以提高数据的保密性和完整性，但仅靠对称加密无法解决所有的数据通信安全问题，比如：密钥管理、没有内置的认证机制、不支持非否认性、易受重放攻击；

所以为了安全性，依然需要依靠https，其结合了对称加密、非对称加密和认证机制，最大限度的确保了网络安全。

2. HTTPS 工作流程探究

根据上面的内容，我们知道在网络传输的过程中，要依靠加密将明文转为密文，加密方式具体采用什么？

2.1. 方案1 - 只使用对称加密

我们知道，如果通信双方都各自持有同一个密钥 X，且没有第三方知道密钥内容，通信双方的通信安全是可以保证的（除非密钥被破解）

但对于一个服务器来说，一般会同时服务很多客户端，且每个客户端的密钥不能相同（更加安全），此时服务器就需要维护更多的关联信息；（费时费力！）

此时如果在客户端和服务器建立连接时，双方就协商确定密钥内容呢？显然为了安全考虑，就需要对密钥的传输再次进行加密，这就成为了一个不可解问题；

2.2. 方案2 - 只使用非对称加密

只是用非对称加密的加密过程如下图：

如果服务器先把公钥以明文方式传给客户端，之后客户端向服务器传数据前，都先用这个公钥加密好再传。由于必须有私钥才能解密这个数据，且只有服务器有私钥，这条路基本可以保证安全（客户端->到服务器），（其实依旧存在安全问题，后文讲到）

但根据上图，很明显可以看出，服务器到客户端的路线无法保证安全；

当服务器私钥加密数据传给客户端，这个数据不但能被客户端解密，同时中间人也可以解密并篡改该。（公钥是公开的）

2.3. 方案3 - 双方都使用非对称加密

服务端拥有公钥 S 与对应的私钥 S'，客户端拥有公钥 C 与对应的私钥 C'
客户和服务端交换公钥
客户端给服务端发信息 ：
- 先用 S 对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'
服务端给客户端发信息 ：
- 先用 C 对数据加密，再发送，只能由客户端解密，因为只有客户端有私钥 C'

但这种方法依然有安全风险，与方案二（客户端->服务器）一样，在方案五中会介绍

2.4. 方案4 - 非对称加密 + 对称加密

服务器采用非对称加密，客户端采用对称加密；
通信前，服务器先将公钥S发送给客户端，客户端再利用S将自己的密钥C进行加密
服务器通过私钥S'将密文解密，获取密钥C，此时除了通信双方，没有人知道密钥的内容
随后可以进行正常通信，且对称加密效率高，速度快

这个方案看似安全了，但存在与方案2、方案3 同样的问题

3. 中间人攻击

Man-in-the-MiddleAttack，简称"MITM 攻击"

首先我们尝试对方案四的方法进行攻击，我们选择在通信时获取公钥阶段就进行攻击
中间人获取了服务器发送的公钥S，并给客户端返回自己的公钥M
此时客户端加密密钥C，中间人截取密文，由于客户端使用的是公钥M进行加密，中间人可以通过自己的私钥M'进行解密，此时就获取了密钥C
随后中间人将正常通信时的密文发送给服务器，通信双方此时都认为通信安全，但实际上密钥C已经泄露了
中间人就可以对整个通信过程进行监听、泄露、篡改；

很显然，这种方法对上述的方案二三均适用、即在最开始交换公钥的时候就进行篡改；

造成这种问题的原因是什么？本质上因为客户端无法确定收到的含有公钥的数据报文，属于目标服务器；

此时就需要依靠证书。

4. 证书引入

4.1. CA认证

为什么依靠证书（与数字签名）就可以解决之前的问题，首先看定义：

服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给客户端，客户端再从证书里获取公钥，证书用于证明服务端公钥的权威性；

可以把证书理解为结构化的串，包含了一些必要信息：

证书发布机构、证书有效期、公钥、证书所有者、签名

4.2. 数据签名与数据验证

上图展示了证书的使用过程，具体的加密需要用上数据签名：

通过上图，可以看出来，数字签名的过程即：

先将数据通过散列函数转为散列值
再通过签名者（CA机构）的私钥将散列值进行加密
将加密后的散列值与认证加到数据上，形成最终数据

当对方接收到数据后，最重要的点就是判断这个数据是否是目标服务器发来的数据，即需要进行验证：

通过上图，验证的过程即：

将获取的数据拆成两份，数据以及加密的签名
分别通过散列函数与解密，获取两份散列值
如果两份散列值相同，则接收到的数字签名有效，也即数据是安全的

总结上面数据签名与验证的过程，作为签名者的CA机构形成数字签名的过程有：

CA 机构拥有非对称加密的私钥 A 和公钥 A'
CA 机构对服务端申请的证书明文数据进行 hash（散列函数），形成数据摘要（散列值）
对数据摘要用 CA 私钥 A'加密，得到数字签名 S

服务端申请的证书明文和数字签名 S 共同组成了数字证书，这样一份数字证书才可以发送给给服务端；

4.3. 方案5 - 非对称加密 + 对称加密 + 证书认证

通过上面的内容，最后总结出一个安全的方案：

上图的过程也是我们分析证书认证以及签名与验证的过程；

对于客户端，当客户端获取到证书后, 会对证书进行校验（防止证书是伪造的）：

判定证书的有效期是否过期
判定证书的发布机构是否受信任（操作系统中已内置的受信任的证书发布机构）
验证证书是否被篡改（数据验证的过程）

中间人能不能将整个证书掉包？

不可以：只有被信任的 CA（证书颁发机构）能够颁发有效的证书，有效的私钥是必要的，伪造的私钥形成的证书通不过验证，即以下三点：

信任链：只有被信任的 CA 能够颁发有效的证书。客户端会验证证书的签名，以确保它来自一个可信的 CA。
私钥的必要性：有效的证书依赖于 CA 的私钥进行签名。中间人无法获取 CA 的私钥，无法生成有效的伪造证书。
验证过程：当客户端接收到证书时，它会使用 CA 的公钥来验证签名。如果中间人尝试掉包证书，签名将不匹配，客户端会拒绝该证书。

5. 部分问题

为什么签名不直接加密，而是要先 hash 形成摘要?

缩短签名密文的⻓度，加快数字签名验证时的运算速度。

中间人是怎么操作的？

ARP 欺骗

在局域网中，黑客通过收到 ARP Request 广播包，能够偷听到其他节点的 (IP, MAC) 地址。例如，黑客收到两个主机 A 和 B 的地址，并告诉 B（受害者）自己是 A，使得 B 发送给 A 的数据包都被黑客截取。
ICMP 攻击

由于 ICMP 协议中有重定向的报文类型，我们可以伪造一个 ICMP 信息，然后发送给局域网中的客户端，伪装成一个更好的路由通路。这样，目标所有的上网流量都会发送到我们指定的接口上，达到与 ARP 欺骗相同的效果。
假 Wi-Fi & 假网站等

6. 总结

6.1. HTTPS 总体流程

通过上面的所有分析，最后可以总结出HTTPS的总体工作流程：

6.2. HTTPS 涉及的三组密钥

第一组（非对称加密）

用于校验证书是否被篡改：

公钥：由服务器生成，并公开给所有用户。用户在建立 HTTPS 连接时，使用这个公钥来加密数据
私钥：服务器私有，保存在服务器上。只有服务器能够解密用其公钥加密的数据。

第二组（非对称加密）

用于协商生成 "对称加密的密钥"，客户端用收到的公钥给 "随机生成的对称加密的密钥" 加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.

第三组（对称加密）

该对称密钥负责客户端和服务器后续数据的传输

第一组是连接层面的，用于校验证书安全，为了让客户端拿到第⼆组非对称加密的公钥

第二组是面向密钥的（加密对称加密的密钥），为了让客户端把这个对称密钥传给服务器

第三组是最后双端通信时使用的密钥

通过这些流程，既可以保证通信安全，也可以保证效率；