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

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

引用

CSDN

1.

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

HTTPS（超文本传输安全协议）是现代互联网通信中保障数据安全的重要技术。本文将从加密机制的基础知识开始，逐步深入解析HTTPS的工作原理，包括对称加密、非对称加密、数据摘要等核心技术，以及如何通过证书认证和数字签名来防范中间人攻击。

1. 前言

1.1. 什么是HTTPS

HTTPS（超文本传输安全协议）是在HTTP协议的基础上引入了一个加密层的应用层协议。HTTP协议的内容都是按照文本的方式明文传输的，这可能导致在传输过程中被篡改。

1.2. 什么是加密

加密就是把明文（要传输的信息）进行一系列变换，生成密文；解密就是把密文再进行一系列变换，还原出明文。在这个过程中，通常需要一个或多个密钥作为辅助。

由于HTTP的内容是明文传输的，可能会经过多个物理节点，包括路由器、Wi-Fi热点、通信服务运营商、代理服务器等。如果信息被劫持，传输的内容就会完全暴露。这种情况被称为中间人攻击。

1.3. 常见的加密方式

① 对称加密

对称加密是一种采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密。常见的对称加密算法包括DES、3DES、AES等。其特点是算法公开、计算量小、加密速度快、加密效率高。

② 非对称加密

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

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

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

1.5.1 一个小问题

对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. 中间人获取了服务器发送的公钥S，并给客户端返回自己的公钥M
2. 此时客户端加密密钥C，中间人截取密文，由于客户端使用的是公钥M进行加密，中间人可以通过自己的私钥M’进行解密，此时就获取了密钥C
3. 随后中间人将正常通信时的密文发送给服务器，通信双方此时都认为通信安全，但实际上密钥C已经泄露了
4. 中间人就可以对整个通信过程进行监听、泄露、篡改

造成这种问题的原因是什么？本质上因为客户端无法确定收到的含有公钥的数据报文，属于目标服务器。此时就需要依靠证书。

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 - 非对称加密 + 对称加密 + 证书认证

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

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

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

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

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

不可以：

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

5. 部分问题

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

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

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

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

6. 总结

6.1. HTTPS 总体流程

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

6.2. HTTPS 涉及的三组密钥

1. 第一组（非对称加密）：用于校验证书是否被篡改
2. 第二组（非对称加密）：用于协商生成“对称加密的密钥”
3. 第三组（对称加密）：负责客户端和服务器后续数据的传输

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