探究 HTTPS 的工作过程

1. HTTPS 协议原理

1.1. 为什么要有HTTPS协议

1.2. 如何理解安全

1.3. HTTPS 协议是什么

2. HTTPS 的前置概念

2.1. 什么是加密 && 解密

2.2. 为什么要加密

2.3. 常见的加密方式

2.3.1. 对称加密

2.3.2. 非对称加密

2.4. 数据摘要 && 数据指纹

2.5. 数据签名

2.6. 中间人攻击

2.7. 理解链 (承上启下)

3. HTTPS的工作过程探究

3.1. 方案一：只使用对称加密

3.2. 方案二：只使用非对称加密

3.3. 方案三：通信双方都使用非对称加密

3.4. 方案四：使用对称加密 + 非对称加密

3.5. 证书的认识

3.5.1. CA认证

3.5.2. 申请CA证书的流程 (了解)

3.5.3. CA机构如何签发证书的

3.6. 方案五：对称加密 + 非对称加密 + 证书认证

3.6.1. 情景一：修改证书明文

3.6.2. 情景二：修改证书明文 + 数据签名

3.6.3. 证书能否整体掉包

3.6.4. 总结

3.7. 常见问题

3.7.1. 为什么数据摘要在网络传输的时候一定要加密形成签名？

3.7.2. 如何成为中间人 (了解)

1. HTTPS 协议原理

1.1. 为什么要有HTTPS协议

在 HTTP 文章中，我们谈过，HTTP在传输网络数据的时候，是明文传送的，信息容易被窃听甚至被篡改，因此它是一个不安全的协议。

在当今网络环境中，数据安全至关重要 (例如你的支付密码、各种私密信息等等)，因此，为了解决这一问题，HTTPS 协议诞生了。HTTPS（Hyper Text Transfer Protocol Secure）在 HTTP 的基础上加入了 SSL/TLS 加密机制，通过对传输的数据进行加密，确保数据在传输过程中是安全的，从而有效防止信息被窃听和篡改的风险，确保用户数据的安全性，是目前互联网上应用最广泛的安全传输协议。

因为 HTTP 是明文传输数据的，即 HTTP 不会对数据进行保护 (加密/解密)，那么另一层意思就是： HTTP 在传输数据时，会做更少的事情，因此它的效率是比 HTTPS 高的。

因此，一般情况下，如果网络环境比较安全，例如在公司的内网中传输数据，可能会优先使用 HTTP，以提高数据传输的效率和降低传输延迟。

当然，如果对数据机密性和完整性要求非常高的话，那么还是优先使用 HTTPS 协议，确保数据在传输过程中受到保护。

总而言之，使用 HTTP 或者 HTTPS 需要根据场景而定。

在学习 HTTP 的时候，我们也说过，无论是 GET 或者 POST 方法传输网络数据时，都是不安全的， POST 只不过数据具有隐秘性 (因为它是在请求正文中的)，但隐秘性不等同于安全性。

那么问题来了，什么是安全呢？

1.2. 如何理解安全

首先，传输网络数据要具有安全性，是需要对数据进行加密的，而加密自然也要伴随着解密的工作。即对数据加密，数据才是安全的。

可是，什么是安全呢？难道说，对数据按照特定逻辑对其加密后，别人永远无法破译，才叫安全吗？

首先，在我们这个世界中，没有绝对的安全，就算有，也是短暂的，随着各项技术的发展 (比如算力的发展)，任何加密算法都一定会有漏洞的产生。

因此，我们在这里为安全下一个定义： 对数据进行加密后，破解这个数据的成本远远大于破解的收益，我们就称之为它是安全的。比如，对数据加密的成本只有一元钱，但破解它需要一个亿，我们称这就是安全的；再比如，对数据加密只用了一秒钟，但破解它需要一千年，这也是安全的。

1.3. HTTPS 协议是什么

在应用层添加一个模块，这个模块我们称之为 TLS/SSL，这一层是可选的，一般负责对数据进行加密和解密。如图所示：

简而言之，在网络通信中，当 HTTP 协议使用 TLS/SSL 协议进行加密和解密数据时，就形成了 HTTPS 协议。

简单了解一下 TLS && SSL

TLS（传输层安全性协议）和SSL（安全套接层协议）是用于保障网络通信安全的加密通信协议。SSL 是较早的版本，而 TLS 则是SSL的继任者，目前主要使用的是TLS协议。
TLS/SSL 协议通过在通信双方之间建立加密连接，确保数据在传输过程中不被窃听、篡改或伪造。它们使用加密算法对数据进行加密和解密，同时通过数字证书来验证通信双方的身份，保证通信的安全性和可靠性。
TLS/SSL 协议广泛应用于Web浏览器和服务器之间的安全通信（HTTPS）、电子邮件系统、聊天应用以及其他需要加密保护的网络通信场景。TLS/SSL协议的使用可以有效防止中间人攻击、数据泄露和篡改等安全威胁，是保障网络通信安全的重要工具。因此，TLS/SSL 协议在网络安全领域扮演着非常关键的角色。

2. HTTPS 的前置概念

2.1. 什么是加密 && 解密

加密：将明文进行一系列变换，生成密文；

解密：将密文进行一系列变换，生成明文；

在加密和解密的过程中，往往需要一个或者多个中间数据，辅助这个过程，这样的数据我们称之为密钥。

2.2. 为什么要加密

由于 HTTP 协议传输的数据是明文传输的 (在互联网上，传输明文数据是比较危险的)，明文数据会经过路由器、wifi 热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就被泄露了，甚至劫持者可能会篡改传输的数据且不被双方察觉到，而这就是中间人攻击，因此为了避免上面的问题，我们需要对网络传输中的数据进行加密。

2.3. 常见的加密方式

2.3.1. 对称加密

对称加密是采用单钥密码系统的加密算法，即用同一个密钥对信息进行加密和解密，这种方式也称之为单密钥加密；
对称加密的特征是加密和解密所用的密钥是相同的；
常见对称加密算法 (了解)：DES、3DES、Blowfish、AES、TDEA等等；
特点： 算法公开(不是密钥公开)，计算量小， 加密效率高；
密钥需要私有，不能公开；

对称加密本质上就是通过同一个密钥，将明文加密成密文，同时也能将密文加密成明文。

一个简单的对称加密：按位异或。在C我们学习过，不使用第三方变量，如何交换两个整数，这本质上就是一个对称加密。

int a = 10;
int b = 20;
std::cout << "a = " << a << ", " << " b = " << b << std::endl;a = a ^ b;
b = a ^ b; // b = (a ^ b) ^ b = a
a = a ^ b; // a = a^ b = a ^ (a ^ b) = b
std::cout << "a = " << a << ", " << " b = " << b << std::endl;

上面的代码本质上是下面这个思路：

a 就相当于明文数据， c 就相当于密文数据， b 就相当于一把密钥。

a 这个明文数据通过密钥 b 加密成了c，就是一个加密的动作；

c 这个密文数据再通过密钥 b 解密成了a，就是一个解密的动作。

因此，这里的 b 实质上是一个对称密钥。

2.3.2. 非对称加密

非对称加密需要两个密钥来进行加密和解密，这两个密钥分别是公开密钥 (public key，简称公钥) 和私有密钥 (private key，简称私钥)。

对外公开的密钥就是公钥，自己私有的密钥就是私钥；
公钥和私钥必须配对使用；
常见非对称加密算法 (了解)：RSA、DSA、ECDSA；
特点：算法强度复杂，安全性依赖于算法和密钥，但是由于算法复杂，使得加密和解密速度没有对称密钥快，效率比对称密钥慢；
没有强制谁必须加密，谁必须解密。但要求一方负责加密数据，那么另一方就需要负责解密数据；
比如，如果是用公钥对明文进行加密形成密文，那么就必须用私钥对密文进行解密形成明文，同时，由于私钥是私有的，故只有持有这个私钥的人才能进行解密，得到明文；
如果用私钥对明文加密形成密文，那么就必须用公钥对密文进行解密形成密文，同时，由于公钥是对外公开的，故实际上，这个数据也是对外公开的；

2.4. 数据摘要 && 数据指纹

数据摘要也称之为数字指纹，其基本原理是利用单向散列函数 (Hash函数) 对信息进行运算，生成一固定长度的数字摘要。

数字摘要并不是一种加密机制，因为，如果是加密，那么必然要有解密，而哈希是无法逆推的，一旦对原始文本经过 Hash 形成数据摘要，很难 (几乎不可能) 根据数据摘要逆推原始文本；
数字摘要主要用来判读数据有没有被篡改；
摘要常见算法：有MD5、SHA1、SHA256、SHA512等；
这些 Hash 算法有个特点：任意的文本，经过 Hash 形成的摘要，都是不一样的，哪怕之更改一点点内容所形成的数据摘要也是千差万别的，因此碰撞概率非常低；
这里的数据摘要就可以理解为原始文本形成的指纹，因此我们也称之为数据指纹；

2.5. 数据签名

数据摘要经过加密，就得到了数据签名。

2.6. 中间人攻击

中间人攻击（Man-in-the-Middle Attack，简称MITM攻击）是一种网络攻击手段，其中攻击者插入自己在通信双方之间，以获取或篡改双方之间传输的信息。在HTTP/HTTPS中，中间人攻击可能发生在通信的任何环节，导致通信双方被欺骗以为他们正在直接通信。

2.7. 理解链 (承上启下)

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

为什么要用非对称加密？

为什么不全用非对称加密？

为了解决上面的疑问，我们需要对 HTTPS 的工作过程进行探究；

3. HTTPS的工作过程探究

经过上面的分析，我们能明白一点：要保证网路传输的数据是安全的，那么就需要对数据进行加密。
换句话说，网络传输不能直接传输明文数据，而应该传输加密后的密文数据。
加密的方式很多，但是整体都可以分为两大类，对称加密 && 非对称加密；

3.1. 方案一：只使用对称加密

如果通信双方都持有同一个密钥X，且没有其他人知道，那么此时双方通信数据的安全就可以保证，如下：

由于此时这把对称密钥只有通信双方知道，因此，即使中间人截取了这个请求，因为不知道密钥，也无法对其进行解密，也就无法监听篡改内容了。

但是，事实上，由于服务端是可能为多个客户端提供服务的，因此，一般情况下，每个客户端所用的对称密钥都应该是不同的 (如果是相同的，那么太容易扩散了，中间人可以轻而易举的获取到)。

因此，服务器就需要维护每个客户端和每个密钥的关系。

但是，现在问题就来了，这么多客户端和密钥，服务端如何得知客户端使用的是哪一把密钥呢？

那么是不是需要服务端将自己的密钥传输给客户端，让客户端使用特定的密钥和我通信呢？

可是，如果用网络传送这个密钥，那这个密钥不就可以被劫持了吗？因为我这把密钥是用来保护后续网络传输信息的安全，可是，谁来保护我这个密钥的安全呢？如果密钥都泄露了，那后续的信息，就无法保证安全性了。这就是一个典型的鸡生蛋，蛋生鸡的问题了。

因此，上面问题的关键不在于谁提供这一把密钥，最主要的问题是持有密钥的一方，如何让另一方安全的获得这把密钥呢？

我们可以发现，上面的问题本质：持有对称密钥的一方，如何让对方安全获得这把密钥？即这把密钥也是需要加密传输 (安全性) 的。

因此，只用对称密钥无法解决上面的问题。

3.2. 方案二：只使用非对称加密

前提条件：

服务端具有非对称公钥S，私钥S'；

客户端发起 HTTPS 请求；
服务端收到后，将自己的公钥S 附加到响应中，传输给客户端 (服务端有自己的私钥S'，且只有服务端知道)；
客户端收到响应后，提取公钥S，通过公钥S对数据进行加密，形成密文，向服务端传输密文。
因为被公钥加密的数据，在这个世界上，只有拥有与之匹配的私钥的人才能够解密，因此，即使此时中间人来了，就算他拿到了公钥S以及网络传输的密文，他也无法对其进行解密，信息也无法被监听篡改。
服务端收到之后，通过私钥S'对其传输的信息进行解密，就会得到明文数据。

上面的过程好像已经保证了数据在传输是安全的 (真的吗？) 。

可是上面的场景只能满足客户端向服务端发送信息是安全的，可是服务端向客户端发送消息呢，此时还是安全的吗？

服务端向客户端发送消息 (密文)，该消息是被私钥加密的。
客户端收到后，用公钥对消息进行解密，得到了服务端发送的明文数据。
可是，有问题啊，这把公钥不是对外公开的吗？换言之，中间人完全可以拿到这把公钥啊，如果服务端在发送数据的时候，中间人劫持了数据，并通过公钥对其进行解密，这不就导致信息被泄露了吗？这如何能体现安全呢？

因此，只使用非对称加密也是无法保证客户端和服务端互相通信时信息的安全性，最多只能保证单向通信的安全。

不仅于此，方案二还有一个隐藏的安全问题，这个问题在方案二、三、四都存在，我们在方案四解释。

3.3. 方案三：通信双方都使用非对称加密

前提条件：

服务端具有非对称公钥S，私钥S'；

客户端具有非对称公钥M，私钥M'；

客户端向服务端发起请求 (明文)，将自己的公钥M传给服务端。
服务端收到请求后，并向客户端发起响应 (明文)，将自己的公钥S传给客户端。
此时，客户端有自己的私钥M'以及服务端的公钥S (当然也有自己的公钥M，在这就不考虑了)；服务端有自己的私钥S'以及客户端的公钥M。
当然，中间人经过上面的网络传输完全可以获得到客户端和服务端的公钥。
客户端向服务端发送信息 (密文)，该信息是通过服务端的公钥S进行加密的，经过网络，发送给服务端，此时就算中间人获得了这个数据，也无法对其进行解密，因为中间人没有服务端的私钥S'。
服务端收到之后，用服务端的私钥S'对其进行解密，得到了客户端发送的明文。
同理，服务端向客户端发送信息 (密文)，该信息需要被客户端的公钥M进行加密，通过网络传输给客户端，客户端收到之后，利用客户端的私钥M'对其进行解密。就得到了服务端发送的明文数据。

此时，服务端和客户端都采用对称加密的方案，并在通信之前，交互双方的公钥，然后后续就可以保证双方信息传输的安全性。

看似没有任何问题，但实际上，依旧存在着一个安全问题 (这个问题和方案二隐藏的问题一模一样)，这个隐患我们在方案四解释。

但是我们知道，非对称加密算法复杂，潜台词就是它比对称加密所做的工作更多，即加密和解密的效率更低，那么在这里双方都是用非对称加密，那么效率太低了，能不能在保证安全的前提下，提高效率呢？

3.4. 方案四：使用对称加密 + 非对称加密

先解决效率问题。

前提条件：

服务端采用非对称加密 (公钥S，私钥S')；

客户端采用对称加密，密钥M；

客户端向服务端发起请求；
服务端收到请求后，并向客户端发送响应 (明文)，将自己的公钥S传输给客户端。当然，中间人完全可以获得服务端的公钥S。
客户端收到服务端的公钥S之后，因为客户端采用的是对称加密，有一把密钥M，因此，客户端就用服务端传过来的公钥S对客户端自己的密钥M进行加密，加密之后，通过网络传输给服务端。由于中间人没有服务端的私钥S'，因此，无法对网络传输的信息进行解密。
服务端收到加密后的信息，用自己的私钥S'对其进行解密。就得到了客户端的唯一的公钥M。
此时，就达到了一种目的，客户端的这把密钥M，只有客户端和服务端双方知道，因此后续双方就可以通过这把密钥M对数据进行加密解密，保证数据传输的安全性。
由于对称加密的加密解密成本低，因此，此时既保证了传输数据的安全也提高了效率。

总结：

通过非对称加密保证对称密钥的安全，让这把对称密钥安全的让另一方得到，这个阶段我们称之为密钥协商阶段；

后续通过这把对称密钥安全地进行网络传输数据，我们称之为数据通信阶段；

这样就好了吗？就一定安全了吗？

首先，我们要知道，中间人不仅可以读数据，还可以写数据，换言之，它是有可能对数据进行篡改的。

实际上，方案二、三、四都存在一个潜在的问题，如果最开始的时候，中间人就开始攻击了呢？即中间人在密钥协商的过程中就开始攻击了呢？此时就出现问题了。

中间人攻击 Man-in-the-MiddleAttack，简称 MITM 攻击；

我们就以方案四举例：

前提条件：

服务端采用非对称加密 (公钥S，私钥S')；

中间人采用非对称加密 (公钥K，私钥K')；

客户端采用对称加密，密钥X；

客户端向服务端发起请求；
服务端明文传输公钥S给客户端；
注意：此时，中间人劫持了数据报文，得到公钥S，并保存好，其次，中间人还将公钥S替换成自己的公钥K，并将伪造后的报文发送给客户端。
客户端收到报文，对于客户端而言，他并不知道自己收到的报文已经被篡改过，他依旧认为自己获得的是服务端发送的原始报文，提取公钥，得到的是公钥K (已被篡改)，客户端形成自己的对称密钥X，通过公钥K对其进行加密，形成报文发送给服务端。
中间人又劫持了该报文，因为中间人是有私钥K'的，因此，可以对这个报文进行解密，得到通信的对称密钥X，并在通过第一次劫持数据报文获得的服务端公钥S对对称密钥X进行加密，将报文推送给服务端。
服务端拿到报文之后，用自己的私钥S'对其进行解密，得到了对称密钥X。
此时，对于服务端和客户端而言，他们认为只有他们双方知道这把对称密钥X，因此认为，未来通过这把对称密钥X进行网络传输是安全的。
但实际上， 这把对称密钥X还有第三方知道，即中间人也知道这把对称密钥X。
因此，未来服务端和客户端在进行网络传输数据时，中间人可以通过这把对称密钥X随意劫持数据，进行窃听甚至修改。

因此，无论是方案二、三、四都存在这个隐藏的安全问题，无法保证双方通信是的数据安全。

那么该如何解决这个问题呢？

我们发现，只要通信双方已经交换了密钥了 (密钥协商)，中间人来了就晚了，而中间人在最开始的时候 (在密钥协商完成之前)，就可以进行监听篡改数据。

中间人之所以能够成功的本质：中间人可以对数据进行篡改 && 客户端无法验证收到的公钥是合法的 (服务端的公钥)。

有没有一种方式确定，客户端收到的公钥就是服务端传输的公钥，中间人一旦进行篡改，客户端就会判别出来。

因此，我们需要引入证书。

3.5. 证书的认识

为了解决上面的问题，客户端需要对服务器公钥的合法性进行认证。

3.5.1. CA认证

服务端在使用HTTPS之前，需要向CA机构申请一份数字证书，数字证书里包含了申请者信息、服务端的公钥等等。

服务器把证书传输给浏览器，浏览器从证书里获取服务端的公钥就行了，证书就如同现实生活中的身份证，身份证标明一个人的合法性，而CA证书，就标明了服务端公钥的合法性。

如果需要用证书来证明服务端公钥的合法性，那么就必须要有：

一个权威机构，CA机构，它是一个全球性的机构；
CA机构需要颁发相关证书， CA证书。

有了证书之后，我们的问题就发生变化了。

以前我们的问题是：保证服务端公钥的合法性。

现在问题就是：保证证书的合法性。

证书里面包含的公钥，就是上面服务端给客户端要推送的公钥，也就是服务端的公钥。

未来，服务到和客户端在进行密钥协商之前，服务端推送的是证书，不仅仅是服务端的公钥，通过证书确保服务端公钥的合法性。

只要证书是合法的，那么证书里面的公钥就一定是服务端的公钥。

因为证书也有可能被造假，甚至整体掉包，因此客户端需要证明证书是合法的，这里的合法不仅指的是这个证书是真的，还需要证明这个证书是客户端需要的证书；

3.5.2. 申请CA证书的流程 (了解)

上面的证书可以理解成一个结构化的字符串，里边包含了如下信息：

证书发布机构
证书有效期
公钥 (服务端的公钥)
证书所有者
签名
......

需要注意的是：申请证书的时候，需要在特定平台生成查，会同时生成一对密钥对，即服务端的公钥和私钥。

其中公钥会随着CSR文件，一起发给CA进行权威认证，私钥服务端自己保留，用来后续进行通信 (其实主要就是用来交换客户端生成的对称秘钥)；

3.5.3. CA机构如何签发证书的

理解数据签名

数据签名是基于非对称加密算法的，对数据摘要进行加密就得到了数据签名。

当服务端申请CA证书的时候， CA机构会对该服务端进行审核，并专门为服务端形成数字签名，过程如下：

CA机构拥有非对称加密的公钥S和私钥S'；
CA机构对服务端申请的证书明文数据进行Hash，得到数据摘要。
CA机构用自己的私钥S' 对形成的数据摘要进行加密得到数据签名M。

此时，服务端申请的证书明文和数字签名M共同组成了数字证书，这样的一份数字证书就可以颁发给服务端了。

3.6. 方案五：对称加密 + 非对称加密 + 证书认证

前提条件：
服务端采用非对称加密，公钥X，私钥X'；

CA机构采用非对称加密，公钥Y，私钥Y'；

中间人采用非对称加密，公钥H，私钥H'；

客户端采用对称加密，密钥Q；

客户端和服务端刚建立连接的时候 (密钥协商之前)，服务端返回给客户端一个证书，证书包含了服务端的公钥，也包含了网站的身份信息。

如果在传输证书的时候，中间人来截获证书了呢？

首先，由于证书是以明文传输的，中间人完全可以截获这个证书。

因此，客户端在密钥协商阶段之前，必须对证书进行验证。
在这里，我们列出中间人攻击的情景：

3.6.1. 情景一：修改证书明文

服务端向客户端明文发送证书，被中间人截获；
中间人修改了证书明文，客户端收到后对其进行认证；
由于中间人修改了证书明文，因此，客户端再认证的时候，证书明文所形成的数据摘要一定有了变化；
客户端在用CA机构的公钥Y解密数据签名得到数据摘要；
此时这两个数据摘要一定不相等，故客户端判断，证书已被篡改，从而终止向服务端传输信息，防止将信息泄露给中间人；

首先，我们要知道：

其一：证书里面的数据签名是由CA机构的私钥Y'加密得到的，而CA机构的私钥Y'，只有CA自己知道，中间人不可能知道。

其二：客户端 (浏览器) 一般是会内置CA机构的公钥Y的。

在情景一中，中间人只对证书明文做了修改，而由于CA机构的公钥Y是对外公开的，因此，中间人完全可以通过CA的公钥Y解密数据签名，得到数据摘要，即也可以篡改数据摘要。

基于上面的理解，我们推出情景二：

3.6.2. 情景二：修改证书明文 + 数据签名

服务端向客户端明文发送证书，被中间人截获；
此时，中间人不仅修改了证书明文，并对修改后的证书明文重新 Hash 得到新的数据摘要；
且通过自己的私钥H'对新的数据摘要进行加密得到新的数据签名；
同时，中间人还将自己的数据签名把CA机构形成的数据签名替换。
那么此时客户端可以识别出来吗？
客户端当然可以识别，因为客户端不会用中间人的公钥来验证证书是否合法，客户端也不想知道中间人的公钥，客户端只会用浏览器内置的CA机构的公钥Y来验证证书是否合法，因此，即便中间人篡改了证书明文，也篡改了数据签名，但客户端依旧能够识别出来。
一旦客户端识别到证书被篡改，就会终止向服务端传输信息，防止将信息泄露给中间人；

因此，我们的总结：

中间人只要篡改了证书，客户端一定可以识别出来，因此，只要客户端验证了证书是合法的，那么就能间接证明证书里的公钥一定是服务端的公钥。

由于中间人无法合法的篡改证书，那么也无法将证书中的服务端的公钥给替换成自己的公钥，也就解决了方案二、三、四中的问题。

3.6.3. 证书能否整体掉包

既然中间人不能合法的篡改证书，那能否整体掉包呢？

中间人无法合法篡改证书：由于中间人没有CA私钥，因此无法创建一个由CA机构签发的合法证书，因此中间人只能自己伪造证书，但这些伪造的证书将不会被客户端信任，因为它们的签发者不是可信的CA机构；
客户端能够识别证书被整体掉包：由于中间人无法制作合法的证书，因此，中间人只能向CA机构申请合法证书，用自己申请的合法证书进行整体掉包，虽然能够做到证书的整体掉包，但是证书可不仅仅只包含数据签名，它还包含一些与服务端相关的信息，如域名等。因此，如果证书被整体掉包了，客户端也会识别出来；
验证成功的证书一定包含服务端公钥：在SSL/TLS握手过程中，客户端会验证服务器提供的证书。如果验证成功，那么客户端会获得服务器的公钥，用于加密通信中的对称密钥；

总而言之，不管中间人对证书做如何篡改，客户端都能识别出来；

最后，在强调一点，中间人没有CA私钥，因此，无法对任何证书进行合法篡改，包括中间人自己的证书。

3.6.4. 总结

HTTPS通常采用的是混合加密机制，包括非对称加密（公钥加密）、对称加密和证书认证。

非对称加密（公钥加密）：在连接的初始阶段 (密钥协商阶段之前)，服务器会将其公钥以数字证书的形式发送给客户端。客户端使用服务器的公钥来加密一个对称密钥，并将其发送给服务器。这一过程确保了通信的机密性，因为只有服务器拥有相应的私钥才能解密这个对称密钥。
对称加密：一旦客户端和服务器之间建立了共享的对称密钥，之后的通信将使用对称加密算法来加密和解密数据。对称加密的优势在于其高效性，因为相对于非对称加密，对称加密的加密解密速度更快。
证书认证：数字证书用于验证服务器的身份。客户端会检查服务器发送的数字证书，验证其是否由受信任的证书颁发机构签发，以及证书中的信息是否与连接的实际服务器匹配。如果证书验证成功，客户端就可以信任服务器的身份。

证书的作用：证书的作用是用来验证服务器的身份，并确保通信的安全性。如果证书被篡改，客户端通常会发出警告或者直接拒绝连接，从而防止中间人攻击的发生。

HTTPS 工作过程中涉及到的密钥有三组：

第一组(非对称加密，CA的公钥和私钥)：用于签发和验证数字证书，防止中间人篡改证书。CA机构用自己的私钥对数据摘要加密形成数据签名，其与证书明文共同组成数字证书；服务端在客户端请求后，返回携带签名的证书，客户端通过 CA 机构的公钥进行证书验证，保证证书的合法性 (确保证书中的公钥是服务端的公钥)，进一步保证证书中携带的服务端公钥的权威性。
第二组(非对称加密，服务端的公钥和私钥)：用于密钥协商，对客户端的对称密钥进行加密。客户端用收到的CA证书中的公钥 (也就是服务端的公钥 ) 给客户端随机生成的对称加密的密钥加密，传输给服务器，服务器通过自己的私钥解密获取到对称密钥。
第三组(对称加密)：客户端和服务器后续传输的数据都通过这个对称密钥加密解密，保证数据安全。

其实一切的关键都是围绕这个对称加密的密钥，其他的机制都是辅助这个密钥工作的。

第二组非对称加密的密钥 (服务端的公钥和私钥) 是为了让客户端把这个对称密钥安全地传给服务器；

第一组非对称加密的密钥 (CA的公钥和私钥) 是为了让客户端安全地拿到第二组非对称加密的公钥 (服务端的公钥)；

3.7. 常见问题

3.7.1. 为什么数据摘要在网络传输的时候一定要加密形成签名？

常见的摘要算法有：MD5 和 SHA 系列；
以 MD5 为例，我们不需要研究具体的计算签名的过程，只需要了解 MD5 的特点。

定长：无论多长的字符串，计算出来的 MD5 值都是固定长度(16字节版本或者32字节版本)；
分散：源字符串只要改变一点点，最终得到的 MD5 值都会差别很大；
不可逆：通过源字符串生成 MD5 很容易,但是通过 MD5 还原成原串理论上是不可能的；

正因为 MD5 有这样的特性，我们可以认为如果两个字符串的 MD5 值相同，则认为这两个字符串相同。

为什么不对数据直接进行加密形成数据签名，而是要先Hash形成数据摘要？

减小签名长度：直接对数据进行加密形成签名可能会导致签名长度较长，而使用哈希函数生成数据摘要后再签名可以大大减小签名的长度。这是因为哈希函数通常将任意长度的输入映射为固定长度的输出，因此无论输入数据有多长，生成的摘要长度都是固定的。这样做不仅有利于减小存储和传输的开销，也更方便处理。

提高性能：对数据进行哈希形成数据摘要后再签名可以加快数字签名的运算速度。因为哈希函数通常具有高效的计算性能，而且生成的数据摘要长度较短，因此签名的计算速度更快。相比之下，直接对数据进行加密可能需要更多的计算资源和时间。

安全性考虑：通过使用哈希函数生成数据摘要，可以将签名过程与具体的加密算法隔离开来，从而提高安全性。哈希函数的特性使得难以从摘要反推出原始数据，因此即使签名被截获，攻击者也无法通过分析签名来获取原始数据的信息。

3.7.2. 如何成为中间人 (了解)

ARP欺骗：在局域网中，hacker经过收到 ARP Request 广播包，能够偷听到其它节点的(IP, MAC)地址。例，黑客收到两个主机A，B的地址，告诉B(受害者)，自己是A，使得B在发送给A的数据包都被黑客截取；
ICMP攻击：由于 ICMP 协议中有重定向的报文类型，那么我们就可以伪造一个 ICMP 信息然后发送给局域网中的客户端，并伪装自己是一个更好的路由通路。从而导致目标所有的上网流量都会发送到我们指定的接口上，达到和ARP欺骗同样的效果；
假wifi && 假网站等；

感言