【网络编程】九、详解 HTTPS 加密原理

Ⅰ. 初识HTTPS

1、HTTPS 的概念

​ 早期互联网公司大多使用的应用层协议都是 HTTP，而 HTTP 无论是用 GET 方法还是 POST 方法传参，都是没有经过任何加密的，也就是明文传输，因此早期很多的信息都是可以通过抓包工具抓到的。

​ 比如说 HTTP 可能出现以下三个风险：

• 窃听风险：比如通信链路上可以获取通信内容，用户号容易没。
• 篡改风险：比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
• 冒充风险：比如冒充淘宝网站，用户钱容易没。

​ 为了解决这个问题，于是出现了 HTTPS 协议，HTTPS 实际就是在应用层和传输层协议之间加了一层协议：SSL/TLS（安全套接字层/运输层安全），这层加密层本身也是 属于应用层 的，它会对用户的个人信息进行各种程度的加密。

​ HTTPS 在交付数据时先把数据交给加密层，由加密层对数据加密后再交给传输层。它可以很好地解决了以下问题：

• 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
• 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

​ 当然，通信双方使用的应用层协议必须是一样的，因此对端的应用层也必须使用 HTTPS，当对端的传输层收到数据后，会先将数据交给加密层，由加密层对数据进行解密后再将数据交给应用层。

​ HTTPS 协议保障了数据在网络中的安全。我们可以 根据其所绑定的端口号来区分是 HTTP 协议还是 HTTPS 协议。可见，只要自身不做恶，SSL/TLS 协议是能保证通信是安全的。

2、HTTP 与 HTTPS 的区别

1. HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题；HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
2. HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输；而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
3. 两者的默认端口不一样，HTTP 默认端口号是 80；HTTPS 默认端口号是 443。
4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

Ⅱ. 加密和解密

1、简单理解加密和解密的过程

​ 首先我们得了解两个概念：

• 加密就是把明文 (要传输的信息）进行一系列变换后，生成密文。
• 解密就是把密文，再进行一系列变换，还原成明文。

​ 在这个加密和解密的过程中，往往需要一个或者多个中间的数据辅助进行，而这样的数据称为 密钥。 (正确发音 yue 四声，不过大家平时都习惯读作 yao 四声)

​ 下面我们简单理解一下加密和解密的过程，而加密最典型、最简单的例子就是异或运算：

​ 我们用 A 异或 B 得到一个中间值 C，此时如果我们采用 C 异或 B 就能重新得到 A。在这个过程中，A 就相当于通信双方想要交互的数据，B 就相当于对称加密当中的 密钥，C 就相当于被密钥加密后的数据，异或运算实际就是一个简单的加密算法，就是 借用了异或运算的规律得到 的！

2、为什么需要加密和解密

​ 因为 http 的内容是明文传输的，明文数据会经过路由器、wifi 热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被对方察觉，这就是 中间人攻击 ，所以我们才需要对信息进行加密。

​ 比如说，我们在网页中点击 “下载按钮”，其实就是在给服务器发送了一个 HTTP 请求，获取到的 HTTP 响应其实就包含了该 APP 的下载链接。如果说被运营商劫持之后，我们就会发现原本这个请求是要下载天天动听，但是因为被劫持之后，其交给用户的响应给篡改成 “QQ浏览器” 的下载地址了。

​ 不止运营商可以劫持，其他的黑客也可以用类似的手段进行劫持，来窃取用户隐私信息，或者篡改内容。试想一下，如果黑客在用户登陆支付宝的时候获取到用户账号余额，甚至获取到用户的支付密码……

​ 所以说在互联网上，明文传输是比较危险的事情！

​ 而 HTTPS 就是在 HTTP 的基础上进行了加密，进一步的来保证用户的信息安全！

​ 至于运营商为什么要劫持，原因大家应该不难想到……但是没办法，我们要想在互联网上玩，就得经过运营商，好在现在运营商的服务质量也提升了很多！

3、常见的加密方式

① 对称加密

​ 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的。

​ 常见对称加密算法(了解一下)：DES、3DES、AES、TDEA、Blowfish、RC2 等，其特点如下所示：

• 算法公开
• 计算量小
• 加密速度快，效率高

​ 对称加密其实就是通过同一个 “密钥”，把明文加密成密文，并且也能把密文解密成明文。而我们上面所说的按位异或操作就是一个简单的对称加密，不过 HTTPS 中并不是使用按位异或，因为太简单了！

② 非对称加密

​ 需要 两个密钥 来进行加密和解密，这两个密钥是 公开密钥（public key，简称公钥）和 私有密钥（private key，简称私钥）。

​ 常见非对称加密算法（了解即可）比如 RSA、DSA、ECDSA 等等。其特点就如下所示：

• 算法强度复杂、安全性依赖于算法与密钥，但是由于其算法复杂，使得这种加密方式的 速度比【对称加密】要慢很多。
• 公钥和私钥是 配对的。

​ 简单的理解，公钥就相当于是一把锁，而私钥是这把锁的钥匙。锁给谁都行，但 只有持有私钥的人才能打开！

​ 也就是说，如果通过公钥进行加密得到密文，那么就得通过私钥进行解密才能得到明文。反之也是成立的，所以我们可以在公钥和私钥中任选一个作为锁，另一个作为钥匙，切记的是，作为钥匙的那一个，一定要妥善保管！

​ 一般来说，我们都是让公钥作为锁，让私钥作为钥匙！

​ 非对称加密的数学原理比较复杂，涉及到一些数论相关的知识。这里举一个简单的生活上的例子：

​ A 要给 B 一些重要的文件，但是 B 可能不在场。于是 A 和 B 提前做出约定好，**B**说：“我桌子上有个盒字，然后我给你一把锁，你把文件放盒子里用锁锁上，然后我回头拿着钥匙来开锁取文件。

​ 在这个场景中，这把锁就相当于公钥，钥匙就是私钥。公钥给谁都行（因为只要没有要是就不怕泄露），但是私钥只有 A 和 B 持有，也就是说只有 A 和 B 能打开盒子！

4、数据摘要（数据指纹）-- 不可逆

​ 数字摘要（也称为数据指纹），其基本原理是 利用单向散列函数（Hash函数）对信息进行运算，生成一串固定长度的数字摘要，所以一般我们也称其为 hash摘要。

​ 但是数字摘要并不是一种加密机制，但它可以 用来判断两个文件是否为同一个文件，因为如果有人对数据某个地方进行小小的改动，重新生成的哈希摘要和改动前的摘要是大不一样的！

​ 摘要和加密算法的区别是：摘要严格意义不是加密（因为 生成的摘要是不可逆的，即不能从摘要还原成原数据），通常用来进行前后数据的对比，观察数据是否被修改过，而 加密算法则是可逆的！

​ 常见的摘要算法有：MD5、SHA1、SHA256、SHA512 等，算法把无限的映射成有限，因此可能会有碰撞，因为两个不同的信息算出的摘要相同，但是这种概率非常低）

​ 数据摘要也可以用于实现网盘的秒传功能、公司数据库密码存储等功能。

​ 比如说网盘的秒传功能，其实要使用是有前提条件的，就是需要网盘中也存在一样的文件，如果说网盘中不存在该文件的话，那么就不用不了秒传了，如下图所示，一个用户从网盘进行文件的上传，此时发现文件并不在，所以就会进行实际的文件上传：

​ 而如果网盘中存在了相同的资源了，网盘就认为重复上传相同的资源其实就是浪费空间，所以直接就创建一个软链接，指向网盘中已有的相同的资源，从而达到一种秒传的效果，但是本质就是一个软链接指向网盘已有的资源罢了！

​ 这样子的好处是 节省了大量的重复空间资源，仅需要开辟一段空间来记录下这些资源对应的数据摘要，就能达到节省几十几百甚至上千 GB 的空间！

​ 这就是公司数据库密码存储功能，凡是涉及到用户密码的字段，都是要加密的。而一般数据库中的密码字段，长度最好是固定的（便于设计表结构），所以我们 通常会将用户密码进行生成数据摘要，然后每次用户登录时都将转换成数据摘要与数据库的哈希摘要进行对比，所以就算数据库泄露了也不怕，因为那些摘要是不可逆的。

5、数字签名 – 可逆

​ 数字签名（又称公钥数字签名）是 只有信息的发送者才能产生的、别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

​ 它是一种类似写在纸上的普通的物理签名，但是在使用了公钥加密领域的技术来实现的，用于鉴别数字信息的方法。 一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。

​ 而它和数据摘要的关系就是：数据摘要通过加密，就得到了数字签名！而数字签名的形成往往都是 基于非对称加密算法 的。

Ⅲ. HTTPS 的工作过程探究

​ 既然要保证数据安全, 就需要进行 “加密”，也就是说我们要解决两个问题，分别是数据被监听的问题，以及数据被篡改的问题！

​ 所以网络传输中不再直接传输明文了，而是加密之后的 “密文”。而加密的方式有很多，但是整体可以分成两大类：对称加密 和 非对称加密。

方案一：只使用对称加密❌

​ 对称加密的特点就是通信双方持有的密钥是一样的，那么就能保证双方在通信的时候，发送的都是密文，而双方根据持有的相同的密钥，就能完成加密和解密的操作，如下图所示：

​ 即使传输的数据被截获，但由于黑客不知道密钥是啥，因此就无法进行解密，也就不知道请求的真实内容是啥了！

​ 但是问题来了，如何保证在加密通信之前，双方都能持有相同的密钥呢❓❓❓

​ 这个问题在对称加密方式中无法保证，这也说明了，单靠对称加密是无法保证传输数据的安全性的！因为如果双方在交换密钥的时候，此时被黑客窃取到了密钥，那么相当于黑客也能对传输的数据进行加密和解密，那这锁就没有存在的意义了！

​ 换句话说，双方在加密通信之前，是需要进行密钥的传输的，那么密钥的传输也必须是要加密的，这不就变成套娃了吗？所以这种方法无解！

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

​ 既然对称加密不能保证通信的安全性，那么我们就来看看非对称加密的原理，看看它是否如我们所愿！

​ 好像这样子用户传输给服务器的内容就是安全的啦！因为就算黑客窃取了从用户到服务器的密文，但是因为黑客没有服务器的私钥，所以就没办法进行解密啊，也就是没办法知道密文到底是什么内容，这样子一来内容就不会泄露了（但其实存在篡改问题，后面会解决！）

​ 但是服务器到浏览器的这条线路怎么保障安全❓❓❓

​ 无法保障！如果服务器用它的私钥加密数据传给浏览器，那浏览器用公钥可以对数据进行解密，而这个公钥一开始是服务器通过明文传输给浏览器的，若这个公钥被黑客劫持到了，那他就能用该公钥解密服务器传来的信息了，照样还是不安全啊，如下图所示：

​ 也就是说，只使用非对称加密的方式，无法保证从服务器到浏览器的数据传输安全！

方案三：双方都使用非对称加密❌

​ 那既然上面只有一方使用非对称加密的方式行不通，那我们来试试看双方都使用非对称加密的情况！

​ 也就是说，此时 客户端和服务器都有各自的私钥和公钥，那么在一开始请求的时候，客户端和服务器都会将各自的公钥交给对方，然后收到对方的加密的报文之后，会使用各自的私钥进行解密，如下图所示：

​ 这种做法看起来好像解决了方案二的安全问题，但实际上 还是存在有安全问题 的，就是可能黑客在一开始就进行攻击，那这个时候这个办法也是挡不住的，这个情况我们在下面讨论方案四的时候一起指出！

​ 另外还有一个问题，就是因为 非对称加密是一种很慢的方式，更何况这里双方都采用了非对称加密，更要命的是对于双方已经基本保证私钥安全的情况下的通信还是通过非对称加密的，那这个 效率是很低的！一般在稍微大型一点的公司，因为考虑到性能问题，是不会采取这种方式的！

方案四：非对称加密+对称加密😊❌

​ 那既然双方都使用非对称加密这种方式不行，就有大佬提出了另一种方案：非对称加密+对称加密。

​ 首先，这种方案在 很大程度上改善了效率的问题，因为这种方案的优势在于，对交换公钥的操作，使用的是非对称加密；而对加密的通信操作，使用的是对称加密！我们都知道，对称加密的效率其实是比非对称加密高很多的，所以将两种方案结合在一起，取长补短！

​ 此外，虽然说这种方案 还是存在安全问题（后面我们会讲），但是基于这种思想，再加上后面我们引出证书的概念之后，就能完美的解决安全问题了！

​ 下面我们先来看看这种方案是如何工作的：

1. 服务器具有 公钥 和 私钥
2. 客户端发起 HTTPS 请求，获取到服务器的公钥
3. 接着客户端生成一把 对称密钥，然后通过服务器的公钥对这把对称密钥进行加密后，发给服务器
4. 服务器收到后，使用私钥进行解密，得到这把对称密钥
5. 后续的通信过程，服务器和客户端都是通过对称密钥进行对称加密的方式通信！

​ 由于对称加密的效率比非对称加密高很多，因此只是在开始阶段协商密钥的时候使用非对称加密，后续的传输仍然使用对称加密！

​ 虽然上面的方案已经很牛逼了，但是 依旧有安全问题！

中间人攻击 – 针对上述所有场景

​ Man-in-the-MiddleAttack，简称 “MITM攻击”。

​ 在之前的方案中，客户端获取到服务器公钥之后，对客户端形成的对称密钥通过服务器给客户端的公钥进行加密，此时中间人即使窃取到了数据，也确实无法解出客户端形成的对称密钥，因为只有服务器有私钥进行解密！

​ 但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，假设黑客此时成为了双方通信的中间人，那么黑客可以进行 ”狸猫换太子“ 的操作：

1. 首先，服务器具有自己的公钥和私钥，而中间人也提前准备了自己的 公钥M 和 私钥M’

2. 当客户端向服务器发起 HTTPS 请求之后，服务器将公钥发过去给客户端，但是被中间人拦截了

3. 中间人先将服务器的公钥保存下来，然后将自己的 公钥M 发给客户端，相当于 调包了公钥

   

4. 此时客户端拿到中间人的 公钥M 之后，并不知道被调包过，所以用客户端生成的对称密钥对 公钥M 进行加密，然后发送给服务器

5. 但是又被中间人拦截了，中间人将密文拿过来，通过自己的 私钥M’ 进行解密，于是就 得到了客户端的对称密钥。接着中间人又重新将密钥通过之前获取的服务器的公钥进行加密，然后发给服务器！

   

6. 服务器收到密文之后，会用自己的私钥进行解密拿到客户端的对称密钥，但是服务器不知道的是，中间人也拿到了对称密钥，也就是说，之前的过程基本是白做了，更可怕的是服务器浑然不知，此时客户端和服务器之间进行的基于对称密钥的加密通信，中间人都能进行解密获取！

​ 这个问题本质出在哪里呢❓❓❓

​ 很明显，问题出在 客户端无法确定收到的含有公钥的数据报文，是不是目标服务器发送过来的！

💥引入数字证书

1、CA认证

​ 基本说明：https://baike.baidu.com/item/CA%E8%AE%A4%E8%AF%81/6471579?fr=aladdin

​ 证书颁发机构 CA（Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

​ 服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。

​ 下面是申请证书以及通信时验证证书的流程：

这个证书可以理解成是一个结构化的字符串，它是 以明文的方式传输 的，其中包含了以下信息：

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

​ 需要注意的是：申请证书的时候，需要在特定平台生成，我们先要填写申请的内容，然后平台会同时生成一对密钥对，即 公钥 和 私钥。这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。

​ 生成了 CSR 文件之后，我们的公钥会随着 CSR 文件一起发给 CA 进行权威认证，而私钥需要我们下载后，由我们自己保留，用来后续进行通信。（其实主要就是用来交换对称密钥）不过一般认证过程很繁琐，网络各种提供证书申请的服务商，一般真的需要，直接找平台解决就行。

​ 在线生成 CSR 和私钥

2、结合证书，再谈数据签名

​ 前面我们已经讲过数据签名了，其实就是 数据摘要通过加密，就得到了数字签名！而数字签名的形成往往都是 基于非对称加密算法 的。

​ 注意，目前暂时和 HTTPS 没有关系，不要和 HTTPS 中的公钥私钥搞混了！

​ 这里我们结合上面的证书申请流程，重新来理解一下数据签名的意义！首先这里的数据，其实就是我们发起申请认证的证书，然后再经过哈希摘要算法，就得到了一个数据签名，如下所示：

​ 接着，有了数据签名之后，我们将其和原来的申请证书结合起来，就变成了 CA 证书，如下图所示：

​ 其实相当于我们就对上面的申请证书流程进行了详细叙述。问题来了，数据签名在这有什么用❓❓❓

​ 因为数据签名是不可逆的，而一旦有人对原来的数据进行修改，那么数据签名就会变得大不一样！所以我们只要用这个数据签名，并且拿申请证书再次去进行哈希然后再用只有 CA 机构拥有的私钥去加密，得到一个新的数据签名！因为是只有 CA 机构拥有的私钥，所以保证了除了 CA 机构以外，不可能有其他人对这个数据签名进行解密！

​ 客户端只需要判断这个新的数据签名是否和 CA 证书中的数据签名一致即可知道证书是否有效，因为如果证书被人修改了，那么这个数据签名是不可能相同的！

​ 简单地说，数据签名的存在让客户端有了辨识证书是否合法有效的能力！而整个环节中 最重要的也就是使用 CA 机构的私钥进行加密这个操作，因为没有它的保障的话，别人一修改我们就不确定了，而有了 CA 机构的保证，我们就能确定只有它能进行加密操作！

客户端如何判断证书是否合法有效？

​ 其实这个我们在上面提及过，就是 判断证书的明文信息形成的数据签名是否等价于证书中的数据签名！为了更好的理解这个过程，下面我们再来剖析一下这个判断的过程！

​ 这里要强调的是，客户端向服务器发送三次握手的请求之后，才会开始走 HTTPS 协议的内容！具体的建立连接流程后面会专门来讲！

​ 三次握手之后，客户端向服务器发起请求，那么服务器就会给客户端响应一份 CA 证书，此时客户端就要判断证书是否合法有效，那么一开始客户端会将明文信息以及数据签名分开，如下图所示：

​ 接着客户端就会将该明文信息，也就是申请证书进行哈希摘要算法，得到数据摘要！然后，客户端会拿着申请证书中的公钥，也就是 CA 机构的公钥，对数据签名进行解密，得到另一个数据摘要！

​ 接着就是 拿这两个摘要进行对比，如果相同的话，则说明这份证书就是合法有效的，反之则是不合法或者无效（比如过期）的！

​ 注意：每一个浏览器（或者是操作系统）都内置了受信任的证书发布机构的公钥，会拿来与申请证书中的公钥进行对比，如果发现不相同的话，则认为这是无效的证书，所以无须担心这个公钥会被篡改的问题！

客户端如何进行证书的验证？

​ 当客户端获取到这个证书之后，会对证书进行校验（防止证书是伪造的），其过程如下所示：

1. 判定证书的 有效期 是否过期
2. 判定证书的发布机构 是否受信任：通过和操作系统中内置的受信任的证书发布机构进行对比！
3. 验证证书 是否被篡改：
   • 从系统中拿到该证书发布机构的公钥（即申请证书中的公钥），对签名解密，得到数据摘要，将其设为 hash1。然后计算客户端获取到的证书的哈希摘要，将其设为 hash2。然后对比 hash1 和 hash2 是否相等。如果相等，则说明证书是没有被篡改过的。
   • 而 只要证书中公钥判断是合法的，那么也就说明生成该数据签名的私钥，也必须得是合法的，也就是一定得通过 CA 机构的私钥进行加密，如果不是的话，那么这个公钥是无法对数据签名进行解密的！

如果中间人篡改 CA 证书呢？

​ 中间人篡改了证书的明文也就是申请证书，由于他没有 CA 机构的私钥，所以无法进行 hash 摘要算法之后用私钥加密形成数据签名，那么也就 没办法对篡改后的证书形成匹配的签名。

​ 如果中间人强行篡改证书（假证书），并且使用自己的私钥生成数据签名的话，也是会被客户端发现的，因为 合法受信任的证书都被操作系统内置了，客户端只要比对篡改后的证书中的公钥，发现和操作系统内置的证书中的公钥都不同的话，那么也会终止访问操作！

如果中间人将整个证书掉包为真证书呢？

​ 因为中间人没有 CA 的私钥，所以无法制作假的证书（这个我们上一个问题已经解释了），所以中间人只能向 CA 申请真证书（必须是真的 CA 证书，因为假的 CA 证书无法被浏览器内置公钥解密），然后用自己申请的证书来进行掉包！

​ 这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够对比然后识别出不匹配的信息。这对中间人来，基本是杀敌一百，自损一千的做法（一旦被查出来，那么通过真证书的信息很容易查到中间人是谁）！

​ 所以我们只要记住：中间人没有 CA 的私钥，所以对任何证书都无法进行合法修改，包括自己申请的证书也是！

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

​ 因为这样子可以 缩短签名密文的长度，加快数字签名的验证签名的运算速度！

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

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

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

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

​ 接下来我们来理解一下判定证书篡改的过程：

​ 假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算 hash 值（比如 md5），结果为 BC4B2A76B9719D91。如果 hello 中有任意的字符被篡改了，比如变成了 hella，那么计算的 md5 值就会变化很大，结果为：BDBD6F9CF51F2FD8。

​ 然后我们可以把这个字符串 hello 和哈希值 BC4B2A76B9719D91 从服务器返回给客户端，此时客户端如何验证 hello 是否是被篡改过❓❓❓

​ 只需要计算 hello 的哈希值，看看是不是 BC4B2A76B9719D91 即可！

​ 但是还有个问题，就是如果黑客把 hello 篡改了，同时也把哈希值重新计算下，客户端就分辨不出来了呀：

​ 所以被传输的哈希值不能传输明文，需要传输密文！

​ 所以，对证书明文（比如这里的 hello）进行 hash 摘要算法后形成数据摘要，然后 CA 使用自己的私钥加密形成签名，将 hello 和加密的签名合起来形成 CA 证书，颁发给服务端！

​ 当客户端请求的时候，就发送给客户端，就算中间人截获了，因为没有 CA 的私钥，也就无法更改或者整体掉包，就能安全的证明，证书的合法性！

​ 最后，客户端通过 操作系统里已经保存的证书发布机构的公钥 进行解密，还原出原始的数据摘要，再进行校验！

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

​ 整个流程大概如下图所示：

来稍微总结一下，HTTPS 工作过程中涉及到的密钥有三组：

• 第一组（非对称加密）：用于校验证书是否被篡改。服务器持有私钥（私钥在形成 CSR 文件与申请证书时获得），客户端持有公钥（操作系统包含了可信任的 CA 认证机构有哪些，同时持有对应的公钥）。服务器在客户端请求是，返回携带签名的证书。客户端通过这个公钥进行证书验证，保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。
• 第二组（非对称加密）：用于保证客户端生成的对称密钥能安全的被服务器接收。客户端用收到的 CA 证书中的公钥（是可被信任的）给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。
• 第三组（对称加密）：客户端和服务器 后续传输的数据都通过客户端生成的对称密钥进行加密解密。

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

• 第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥
• 第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器

Ⅳ. 如何成为中间人（了解）

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