HTTPS详解：加密机制、工作流程、CA证书与中间人攻击防护
HTTPS详解：加密机制、工作流程、CA证书与中间人攻击防护
HTTPS（超文本传输安全协议）是现代互联网通信中保障数据安全的重要协议。本文将从加密基础知识入手，深入解析HTTPS的工作原理，包括对称加密、非对称加密、数据摘要等核心技术，并详细阐述中间人攻击的防护机制。通过本文，你将全面了解HTTPS如何在保障数据传输安全的同时，兼顾通信效率。
1. 前言
1.1. 什么是HTTPS
HTTPS（超文本传输安全协议）是在HTTP协议的基础上引入了一个加密层的应用层协议。HTTP协议的内容都是按照文本方式明文传输的，这可能导致数据在传输过程中被篡改。
1.2. 什么是加密
加密就是把明文（要传输的信息）进行一系列变换，生成密文；解密就是把密文再进行一系列变换，还原出明文。在这个过程中，通常需要一个或多个密钥作为辅助。
由于HTTP的内容是明文传输的，这些数据会经过多个物理节点，包括路由器、Wi-Fi热点、通信服务运营商、代理服务器等。如果信息被劫持，传输的内容就会完全暴露。这种情况被称为中间人攻击。
1.3. 常见的加密方式
① 对称加密
对称加密是一种采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密。常见的对称加密算法有DES、3DES、AES、TDEA、Blowfish、RC2等。其特点是算法公开、计算量小、加密速度快、加密效率高。
② 非对称加密
非对称加密需要两个密钥：公开密钥（Public Key）和私有密钥（Private Key）。公钥和私钥是成对存在的。常见的非对称加密算法有RSA、DSA、ECDSA等。其特点是算法强度复杂，安全性依赖于算法与密钥，加密和解密的速度通常比对称加密要慢得多。
1.4. 数据摘要（数据指纹）
数字指纹，也称为数据摘要，其基本原理是利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的数字摘要。常见的摘要算法有MD5、SHA1、SHA256、SHA512等。
① 实例：软件分发中的数据摘要
在软件分发过程中，开发者通常需要确保用户下载的软件包没有被篡改或损坏。为了确保软件包的完整性和安全性，开发者会生成该软件包的摘要（哈希值），并将其与软件包一起提供给用户。
1.5.1 一个小问题
对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-Middle Attack，简称“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连接时，使用这个公钥来加密数据
- 私钥：服务器私有，保存在服务器上。只有服务器能够解密用其公钥加密的数据。
第二组（非对称加密）：用于协商生成“对称加密的密钥”，客户端用收到的公钥给“随机生成的对称加密的密钥”加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥.
第三组（对称加密）：该对称密钥负责客户端和服务器后续数据的传输
第一组是连接层面的，用于校验证书安全，为了让客户端拿到第二组非对称加密的公钥；第二组是面向密钥的（加密对称加密的密钥），为了让客户端把这个对称密钥传给服务器；第三组是最后双端通信时使用的密钥。通过这些流程，既可以保证通信安全，也可以保证效率。