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

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

引用

CSDN

1.

https://blog.csdn.net/Dreaming_TI/article/details/143209155

HTTPS（超文本传输安全协议）是现代互联网通信中保障数据安全的重要技术。本文将从加密基础、HTTPS工作原理到中间人攻击防护等多个维度，深入解析HTTPS的核心机制，帮助读者全面理解这一关键技术。

1. 基础概念

1.1 什么是HTTPS

HTTPS（超文本传输安全协议）是在HTTP协议的基础上引入了一个加密层，用于保障数据传输的安全性。与HTTP协议不同，HTTPS协议的内容不是以明文方式传输的，而是经过加密处理的，这样可以防止数据在传输过程中被窃取或篡改。

1.2 加密的基本概念

• 加密：将明文（要传输的信息）通过一系列变换生成密文的过程。
• 解密：将密文再通过一系列变换还原成明文的过程。
• 密钥：在加密和解密过程中使用的中间数据，用于辅助完成加密和解密过程。

1.3 常见的加密方式

对称加密

• 定义：采用单钥密码系统，同一个密钥可以同时用于信息的加密和解密。
• 常见算法：DES、3DES、AES、TDEA、Blowfish、RC2
• 特点：算法公开、计算量小、加密速度快、加密效率高

非对称加密

• 定义：需要两个密钥：公开密钥（Public Key）和私有密钥（Private Key），公钥和私钥是成对存在的。
• 常见算法：RSA、DSA、ECDSA
• 特点：算法强度复杂，安全性依赖于算法与密钥，加密和解密的速度通常比对称加密要慢得多。

1.4 数据摘要（数据指纹）

• 定义：利用单向散列函数（Hash 函数）对信息进行运算，生成一串固定长度的数字摘要。
• 常见算法：MD5、SHA1、SHA256、SHA512
• 特点：与加密算法的区别在于，摘要严格意义上不是加密，因为没有解密的过程。从摘要反推原始信息非常困难，通常用于数据对比。

1.5 一个小问题

对HTTP进行对称加密可以提高数据的保密性和完整性，但仅靠对称加密无法解决所有的数据通信安全问题，比如：密钥管理、没有内置的认证机制、不支持非否认性、易受重放攻击。因此，为了安全性，依然需要依靠HTTPS，其结合了对称加密、非对称加密和认证机制，最大限度地确保了网络安全。

2. HTTPS工作流程探究

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

如果通信双方都各自持有同一个密钥X，且没有第三方知道密钥内容，通信双方的通信安全是可以保证的（除非密钥被破解）。但对于一个服务器来说，一般会同时服务很多客户端，且每个客户端的密钥不能相同（更加安全），此时服务器就需要维护更多的关联信息；（费时费力！）此时如果在客户端和服务器建立连接时，双方就协商确定密钥内容呢？显然为了安全考虑，就需要对密钥的传输再次进行加密，这就成为了一个不可解问题。

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

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

但根据上图，很明显可以看出，服务器到客户端的路线无法保证安全；当服务器私钥加密数据传给客户端，这个数据不但能被客户端解密，同时中间人也可以解密并篡改该。（公钥是公开的）

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

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

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

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

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

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

3. 中间人攻击

Man-in-the-Middle Attack，简称“MITM 攻击”

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

很显然，这种方法对上述的方案二三均适用、即在最开始交换公钥的时候就进行篡改；造成这种问题的原因是什么？本质上因为客户端无法确定收到的含有公钥的数据报文，属于目标服务器；此时就需要依靠证书。

4. 证书引入

4.1 CA认证

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

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

4.2 数据签名与数据验证

数字签名的过程即：

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

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

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

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

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

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

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

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

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

上图的过程也是我们分析证书认证以及签名与验证的过程；对于客户端，当客户端获取到证书后，会对证书进行校验（防止证书是伪造的）：

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

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

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

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

5. 部分问题

1. 为什么签名不直接加密，而要先hash形成摘要？

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

2. 中间人是怎么操作的？

• ARP欺骗：在局域网中，黑客通过收到ARP Request广播包，能够偷听到其他节点的(IP, MAC)地址。
• ICMP攻击：由于ICMP协议中有重定向的报文类型，我们可以伪造一个ICMP信息，然后发送给局域网中的客户端，伪装成一个更好的路由通路。
• 假Wi-Fi & 假网站等

6. 总结

6.1 HTTPS总体流程

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

6.2 HTTPS涉及的三组密钥

1. 第一组（非对称加密）：用于校验证书是否被篡改

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

2. 第二组（非对称加密）：用于协商生成“对称加密的密钥”，客户端用收到的公钥给“随机生成的对称加密的密钥”加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。

3. 第三组（对称加密）：该对称密钥负责客户端和服务器后续数据的传输

第一组是连接层面的，用于校验证书安全，为了让客户端拿到第二组非对称加密的公钥；第二组是面向密钥的（加密对称加密的密钥），为了让客户端把这个对称密钥传给服务器；第三组是最后双端通信时使用的密钥。通过这些流程，既可以保证通信安全，也可以保证效率。