https>https://img-blog.csdnimg.cn/223620bce48e4e36859828df866921f7.png" alt="在这里插入图片描述" />

前言

前面一篇博客讲的是HTTP，HTTP 协议内容都是按照⽂本的⽅式明⽂传输的，这就导致在传输过程中容易出现⼀些被篡改的情况。

HTTPS 也是⼀个应⽤层协议. 在 HTTP 协议的基础上引⼊了⼀个加密层，所以HTTPS是一种保证数据安全的协议。

如果屏幕前的你还不了解HTTP，可以先看看我前一篇的HTTP协议：【网络】用代码讲解HTTP协议

正式开始

安全

HTTP中用POST方法上传数据时只会保证私密性，而安全并没有得到很好的保障，数据还是明文的在发送。

真正的安全是要对数据做加密的，那么有加密也必定要解密，二者是同时存在的。

那么如何理解安全呢？
网络通信的时候，真正考虑的安全是数据在网络转发过程中是否安全，也就是网络安全。

这里给安全一个定义：破解成本远大于破解收益时，就是安全的。比如说破解一个数据需要花费1000元，但是获取到的收益只有两三毛，那么这种数据破解起来收益太少了，成本过高。或者说对一个数据加密只需要几号秒，但是破解出来需要几十年，也是时间耗费太高了。

不过目前主流的通信方式都是安全的。

HTTP和HTTPS的关系

网络协议栈分四层（不考虑物理层）：
https>https://img-blog.csdnimg.cn/2e8278cef7444fcaa7564b6554801ee6.png" alt="在这里插入图片描述" />

其中Socket接口时处于应用层和传输层之间的，所以上一篇中能够对http进行简单封装，让浏览器帮我们进行解析并显示到浏览器中。

再把各个层经典的协议给出来：
https>https://img-blog.csdnimg.cn/cb4ae91e739a48fd9edf81e76f47bc86.png" alt="在这里插入图片描述" />

其中HTTP所在的应用层还可以添加一个小的模块：

https>https://img-blog.csdnimg.cn/575d9bb7ea794f6486657f6b8b630448.png" alt="在这里插入图片描述" />

其中这个TLS/SSL是可选的。

如果HTTP直接往传输层走就是上一篇中的HTTP，但如果HTTP 和 TLS/SSL一块的话就是本篇中的HTTPS：
https>https://img-blog.csdnimg.cn/3be619c12560403ca65ebafaea23adff.png" alt="在这里插入图片描述" />

那么二者传输数据的时候就是这样：
https>https://img-blog.csdnimg.cn/85fa3f6245e442e29c27ac261f1364ae.png" alt="在这里插入图片描述" />

HTTPS传输和发送都要经过那一小块加密和解密，相当于是又在应用层和传输层又加了一层安全层，所以在网络中传输的数据是一定经过加密的，当有恶意分子拿到数据后也干不了什么操作，除非是进行破解。这就是HTTPS的一个概况。

什么是加密和解密

加密就是把 明⽂ (要传输的信息)进⾏⼀系列变换，⽣成 密⽂。
解密就是把 密⽂ 再进⾏⼀系列变换, 还原成 明⽂。

在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为 密钥，就是帮助加密/解密的东西。

来个例子。

下面这两张图是一部电影中的，83 版 <<⽕烧圆明园>> , 有⼈要谋反⼲掉慈禧太后. 恭亲王奕䜣给慈禧递的折⼦. 折⼦内容只是扯⼀扯家常, 套上⼀张挖了洞的纸就能看到真实要表达的意思。
https>https://img-blog.csdnimg.cn/198e2f64bd764980841a6ce5f3172604.png" alt="" />
https>https://img-blog.csdnimg.cn/22f283748a9a487ebb94ff5ec59b7c7c.png" alt="在这里插入图片描述" />

这里：
明⽂: “当⼼肃顺, 端华, 戴恒” (这⼏个⼈都是当时的权⾂, 后来被慈禧⼀锅端).

密⽂: 奏折全⽂

密钥: 挖了洞的纸

明文就那么几个字，加密之后就变成了信，解密的就是挖洞的纸（秘钥）。

加密解密到如今已经发展成⼀个独⽴的学科: 密码学.
⽽密码学的奠基⼈, 也正是计算机科学的祖师爷之⼀, 艾伦·⻨席森·图灵
https>https://img-blog.csdnimg.cn/22fab995637e4c9e87f8d50f2faab40f.png" alt="在这里插入图片描述" />

对⽐我们另⼀位祖师爷冯诺依曼
https>https://img-blog.csdnimg.cn/cd426f3ebfcf45e094fd2e116d13206a.png" alt="在这里插入图片描述" />

图灵的头发有点多。

可惜图灵⼤佬年少有为，但是因为⼀些原因遭到英国皇室的迫害, 41岁就英年早逝了。

计算机领域中的最⾼荣誉就是以他名字命名的 “图灵奖”。

为什么要加密

我记得我小时候上网下载东西的时候，那时候啥都不懂，想下载什么就随便搜一下进一个野鸡网站，看见有下载就点，但是总是偶尔下载出来全家桶，非常恶心，后来慢慢了解了点，下载的时候长了点心眼，那种全家桶就没再见过了。

不过有一次我爸下载啥东西的时候下了一堆游戏的全家桶，什么传奇啥的，还是开机自动启动的，重启都没用，那会电脑直接卡的鼠标挪半天挪不动，还好电脑打开稍微缓一段时间鼠标能动了，然后我直接用任务管理器把那些游戏先全关掉再卸载，只能说非常费劲。这种搞全家桶的行为真的非常的恶心。

运营商劫持

来个例子。

这里没有被劫持的状态，点击下载，弹出正确的下载链接：
https>https://img-blog.csdnimg.cn/49970b6eb3bd4f7284ebb2ba525a31d0.png" alt="在这里插入图片描述" />

如果被劫持了：
https>https://img-blog.csdnimg.cn/22dd0ba1afc4463fad3f8b9826178715.png" alt="在这里插入图片描述" />

看见没，就变成了QQ浏览器。

由于我们通过⽹络传输的任何的数据包都会经过运营商（电信、移动、联通等）的⽹络设备(路由器, 交换机等), 那么运营商的⽹络设备就可以解析出你传输的数据内容, 并进⾏篡改。

点击 “下载按钮”, 其实就是给服务器发送了⼀个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载天天动听, 那么就⾃动的把交给⽤⼾的响应给篡改成 “QQ浏览器” 的下载地址了。

https>https://img-blog.csdnimg.cn/3bbc11a1baa142eabd0c135b6848deeb.png" alt="在这里插入图片描述" />

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

中国互联网发展早期，用的协议都是HTTP协议，因为方便快速，所以就容易出现上方的情况。现在应该很少了。

但是现在还有什么安全下载，又给你下什么360浏览器、安全卫士啥的，很恶心。

导致我现在看到这种图就烦：
https>https://img-blog.csdnimg.cn/26799b0c16af4308882799bd8bc7861e.png" alt="在这里插入图片描述" />

思考下, 为啥运营商要进⾏劫持?
因为到了儿，有钱能使鬼推磨嘛。

不⽌运营商可以劫持, 其他的 ⿊客 也可以⽤类似的⼿段进⾏劫持, 来窃取用户隐私信息, 或者篡改内容。

中间人

客户端和服务端发送的数据要经过谁，谁就是中间人。

关于数据泄漏的问题95%以上都是中间人攻击造成的。

你的手机打开热点，此时你的手机就相当于一个路由器，连上热点的人传输的数据一定会经过你的手机，如果你手机上有抓包的软件且连接你手机的人传输数据时采用的协议是HTTP，那么你就能拿到TA所发送的数据，此时你就是一个中间人，不过没有进行攻击。

所以一些地方的免费WiFi连的时候要谨慎，能不连就不连，人家一抓一个准。

所以在互联⽹上, 明⽂传输是⽐较危险的事情!!!
HTTPS 就是在 HTTP 的基础上进⾏了加密, 进⼀步的来保证用户的信息安全~

常⻅的加密⽅式

对称加密

• 采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的

• 常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等

• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼

对称加密其实就是通过同⼀个 “密钥” , 把明⽂加密成密⽂, 并且也能把密⽂解密成明⽂.

⼀个简单的对称加密, 按位异或：
假设 明⽂ a = 1234, 密钥 key = 8888
则加密 a ^ key 得到的密⽂ b 为 9834.
然后针对密⽂ 9834 再次进⾏运算 b ^ key, 得到的就是原来的明⽂ 1234.
(对于字符串的对称加密也是同理, 每⼀个字符都可以表⽰成⼀个数字)
当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使⽤按位异或.

⾮对称加密

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

• 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA

• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。

⾮对称加密要⽤到两个密钥, ⼀个叫做 “公钥”, ⼀个叫做 “私钥”。

公钥和私钥是配对的. 最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多.
• 通过公钥对明⽂加密, 变成密⽂
• 通过私钥对密⽂解密, 变成明⽂

也可以反着⽤
• 通过私钥对明⽂加密, 变成密⽂
• 通过公钥对密⽂解密, 变成明⽂

这里不会讲非对称加密的相关计算细节，这里涉及到数学方面的知识，博主能力有限，不详谈加密的计算细节，对于我们普通程序员来讲，不懂怎么加密计算是没有关系的，以后真正工作的时候可以说是碰不到HTTPS的。

这里只要记住非对称加密需要两个秘钥就行，一个公钥一个私钥，公钥对外，私钥不对外，公钥私钥都可进行加密，也都可进行解密，但是公钥加密就要用私钥解密，私钥加密就要用公钥解密。

数据摘要

数据摘要，也叫做数据指纹。是指将原始发送的文本经过hash算法，得到的一段固定长度的字符串，这个字符串就是数据摘要。

摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）。可以认为不同的原始文本经过hash后得到的摘要都是不一样的，就算是改一个标点结果都会差很多。

得到的摘要无法逆向成原始数据，想变回原始数据的话也非常困难。

这里说一个生活中的例子。
百度网盘应该都用过，其中有一个秒传的功能，就是你上传数据的时候根本不需要进行等待，直接就能传上去。这里就用到了摘要，看图：

https>https://img-blog.csdnimg.cn/9d665e8954b1450faf07340e7a1c4a60.png" alt="在这里插入图片描述" />

你在上传数据前，会先对你的数据hash形成摘要：
https>https://img-blog.csdnimg.cn/5de9992dc22a4a05b22f4324d8e3db77.png" alt="在这里插入图片描述" />
用百度网盘的人非常多，每个人都可以向服务器上传资源，可能你今天想要上传的数据在以前已经被别人上传过了，而且是一模一样的数据，网盘的服务器中会有不同数据hash后形成的摘要放到一块。所以在传输数据前会先将摘要传给服务器，把你的数据形成的摘要在服务器中查找一下，如果找到了，那么就直接在你所对应的服务器路径下搞一个软链接指向之前已经上传过的数据（大多数公司的服务器也是用Linux搞的），这就是秒传，创建一个软连接就是简单的创建一个文件，所以会非常快。如果说你的数据形成的摘要没找到，那么就会按照每秒几MB慢慢传。
https>https://img-blog.csdnimg.cn/64bad67683924bd0b4bd9bff3356c54b.png" alt="在这里插入图片描述" />

再来个例子，一般公司里面注册用户，用户的密码在公司中是一定不能被他人看到的，所以公司的数据库中一般不会直接保存用户的密码，而是保存密码摘要，登录的时候对密码采用hash算法形成摘要，然后再拿着用户名和密码摘要到数据库中查找。

数字签名

摘要经过加密，就得到数字签名（后⾯细说）。

数据摘要严格意义上讲不叫加密，因为能加密就得要能解密，但是摘要后无法解密，无法逆向退出原始数据。

数据摘要和加密算法的区别是，摘要严格意义不是加密，因为没有解密，因为从摘要很难反推原信息，所以摘要通常⽤来进⾏数据对⽐。

HTTPS 的⼯作过程

既然要保证数据安全, 就需要进⾏ “加密”.

⽹络传输中不再直接传输明⽂了, ⽽是加密之后的 “密⽂”.

加密的⽅式有很多, 但是整体可以分成刚刚说过的两⼤类: 对称加密 和 ⾮对称加密

⽅案 1 - 只使⽤对称加密（不可靠）

如果通信双⽅都各⾃持有同⼀个密钥X。

首先得让服务器和客户端都能确定同一个秘钥。

来画画图：
https>https://img-blog.csdnimg.cn/9c683ff4b3ea47269c3340e38a3bf428.png" alt="在这里插入图片描述" />

先让一方定下来一个对称秘钥x，就让服务端确定，客户端来获取。

https>https://img-blog.csdnimg.cn/11320843a56640df8a658d481fe803e1.png" alt="在这里插入图片描述" />

但是这种方法没用。

因为黑客可以在中间截取到服务端发给客户端包含秘钥的报文，并在报文中提取到秘钥x。
https>https://img-blog.csdnimg.cn/afe3cb86faf54bafa274a33b30951806.png" alt="在这里插入图片描述" />

所以这种方式不可靠。

⽅案 2 - 只使⽤⾮对称加密（不可靠）

还是让服务端确定一对公钥和私钥：

https>https://img-blog.csdnimg.cn/66320fa58c614bacb9aa73a9f98f91a0.png" alt="在这里插入图片描述" />

然后让客户端获取：
https>https://img-blog.csdnimg.cn/28f0a5cc30fa489a8139ec65c3004544.png" alt="在这里插入图片描述" />

后续通信就通过这一对公钥和私钥加密解密：
https>https://img-blog.csdnimg.cn/e1d7cf1e8aba46f39294cfd4e4829bee.png" alt="在这里插入图片描述" />

但是不行，黑客可以在开头获取公钥S。这样服务端的数据就不保了。

https>https://img-blog.csdnimg.cn/7f4e24cec3ed4c6d812637540ced5aa0.png" alt="在这里插入图片描述" />

所以不可靠。

⽅案 3 - 双⽅都使⽤⾮对称加密（不可靠）

服务端和客户端都产生一对公钥和私钥。

服务端和客户端都公开其公钥。

https>https://img-blog.csdnimg.cn/a8e6dd1dada049c9898376e46f4e0e26.png" alt="在这里插入图片描述" />

获取对方公钥：
https>https://img-blog.csdnimg.cn/d739cec2ba164e95afeecf5e5d127185.png" alt="在这里插入图片描述" />

此时客户端有: C, C’, S；服务端有: S, S’, C。若后续用私钥进行加密，那么自身的公钥也就没什么用了，除掉自身公钥。

客户端：C’, S
服务端：S’, C

那么后续通信时，客户端发送数据通过C’加密，服务端接收后用C解密。服务端发送数据时用S’加密，客户端接受后用S解密。如图：
https>https://img-blog.csdnimg.cn/f1c76cc8e84a45e19f767d7094d9ded5.png" alt="在这里插入图片描述" />

但是这样也不行，黑客还是能在最开始的时候获取到所有的公钥。

https>https://img-blog.csdnimg.cn/32c0a7c376284cc2ba65b991dad43eb3.png" alt="在这里插入图片描述" />

所以也不可靠。

而且双方都用非对称加密，效率会很低。

⽐较理想的做法, 就是能在客户端和服务器建⽴连接的时候, 双⽅协商确定这次的密钥是啥。
https>https://img-blog.csdnimg.cn/19f8477e019f482c91b183aa9fd5e566.png" alt="在这里插入图片描述" />
但是如果直接把密钥明⽂传输, 那么⿊客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.
因此密钥的传输也必须加密传输!

但是要想对密钥进⾏对称加密, 就仍然需要先协商确定⼀个 “密钥的密钥”. 这就成了 “先有鸡还是先有
蛋” 的问题了. 此时密钥的传输再⽤对称加密就⾏不通了。

⽅案 4 - ⾮对称加密 + 对称加密（不可靠）

• 服务端具有⾮对称公钥S和私钥S’
• 客户端发起https>https请求，获取服务端公钥S
• 客户端在本地⽣成对称密钥C, 通过公钥S加密, 发送给服务器.
• 由于中间的⽹络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密
钥
• 服务器通过私钥S’解密, 还原出客户端发送的对称密钥C. 并且使⽤这个对称密钥加密给客户端返回
的响应数据.

https>https://img-blog.csdnimg.cn/b0c885cce79b4007bb2b57c57a6da618.png" alt="在这里插入图片描述" />

上面的这个阶段就叫做秘钥协商阶段。

那么此时客户端和服务端都确定了对称秘钥X。

https>https://img-blog.csdnimg.cn/d3bc3651b96d4e188d9eb00a2fd27043.png" alt="在这里插入图片描述" />

后面这里就是通信阶段。

后续通信时即使黑客获取到了公钥S，也没法用S对SX进行解密，那就获取不到X了，这样就安全了吗？

并没有，黑客能获取到服务端的公钥S，获取到之后，黑客还可以自己搞一套公钥K和私钥K’，然后
将报文中的S改为K，再将发送给客户端，这样客户端以为自己得到了服务端的公钥S，但其实是黑客的公钥K。
https>https://img-blog.csdnimg.cn/b11e4b392ad3484a815fd5068c8cc6a3.png" alt="在这里插入图片描述" />
所以说还是不安全。

虽然上⾯已经⽐较接近答案了，但是依旧有安全问题。

只要已经交换了秘钥，中间人来了就完了，此时就可正常通信。

但是只要中间人在最开始的时候就可以篡改替换，就没法通信了。

上面的四种方法都不行，这种中间人攻击能够成功，本质上是中间人能对数据做篡改并且client端无法验证收到的公钥是目标服务器的公钥还是黑客的公钥。

那么必须得解决这两个问题：

1. 不要让中间人篡改
2. 客户端能够验证服务端的公钥是否有效。

引⼊证书

啥是证书？
说说日常生活。

某天，大街上，有警察巡逻。

此时街上有一个长得贼眉鼠眼的，走路很猥琐，此时经常快步上前盘问此人，警察第一句有效的话术是什么？

应该是请出示你的证件。也就是身份证。

那么如果此人拿了一张身份证，警察就会对比对比长相，验证一下身份证。

如果核验通过了，那么就可以放此人离开；但是如果核验没通过，此人就走不了喽。

为什么有效证件是身份证？不是其他的驾照啥的，医保卡啥的？
因为身份证是用于证明居住在中华人民共和国境内的公民身份证明文件。要是政府都没法相信的话，那就没啥可信的了。

警察相信身份证，本质上是相信颁发身份证的机构。

所以颁发一个证书，需要一个权威机构，而这里要说的权威机构就是CA机构，是一个全球性的机构。

CA认证

CA机构会为需要HTTPS的企业/公司/组织/个人颁发CA证书。

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。证书就如⾝份证，证明服务端公钥的权威性。

https>https://img-blog.csdnimg.cn/cc67b89ee2fd4f5b865bb91455e70f0f.png" alt="在这里插入图片描述" />

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

1. CA机构拥有自己的⾮对称加密的私钥A和公钥A’
2. CA机构对服务端申请的证书明⽂数据进⾏hash，形成数据摘要
3. 然后对数据摘要⽤CA私钥A’加密，得到数字签名S

服务端申请的证书明⽂和数字签名S共同组成了数字证书，这样⼀份数字证书就可以颁发给服务端了。

而客户端操作系统和浏览器中已内置了受信任的证书发布机构，其中就包含了CA机构的公钥。

服务端要向CA机构申请证书。说明什么，一个公司，要向CA机构申请证书，像普通的程序员是不可能接触到的，像大公司，人家早期就搞好了HTTPS，我们后面进去根本就不用管这，像小公司，如果你是一个leader，那有可能会让你负责搞这个申请。反正正常程序员一般不会接触到HTTPS的。

数据签名

刚刚简单提了一嘴数据签名。

原始的数据通过散列获取摘要，摘要再通过加密就是签名。

如图：
https>https://img-blog.csdnimg.cn/07abfa229cd244668d847ba6bf4618db.png" alt="在这里插入图片描述" />

再来添加一点东西：
https>https://img-blog.csdnimg.cn/3a8ca936214f4624a57ea354a13a50e0.png" alt="在这里插入图片描述" />

这里带签名的数据就是服务器要向客户端发送的东西。其中包含了服务器的公钥。

客户端接收到后会进行以下操作：
https>https://img-blog.csdnimg.cn/278b5dee00234afcaf6a257bda5f0467.png" alt="在这里插入图片描述" />

注意两点，浏览器中内置了CA机构的公钥，上图数据中包含了服务器的公钥。

所以整个流程就是这样：
https>https://img-blog.csdnimg.cn/ee2899142be64fbe92fb0bf9a8b3bedc.png" alt="在这里插入图片描述" />

其中就算黑客最开始劫持到了证书，TA也没法修改。如果改了正文不改签名，或者是改了签名不改正文，那么传到客户端后证书就没法验证成功。

就算中黑客自己定义了公钥和私钥k, k’，并将正文中服务端的公钥改为自己的公钥K，但TA改不了签名，因为TA没有CA机构的私钥，客户端在解密签名的时候用的是CA的公钥，就算TA把签名改成了用TA的私钥k’加密的也是没用的，客户端不会用TA的公钥k，而是用CA的公钥解k’加密的签名，那么签名解密后的摘要和TAhash后的摘要是不一样的。

再者说，如果中间人自己开了家公司并且还申请了证书，中间把整个证书替换掉，也没用，因为证书中是有其域名的（前面介绍证书的图中有），全部替换，域名就改了，意思就是客户本来想访问腾讯的官网，但是中间人将整个证书替换，换成了一个长得很像的名字为腾迅的官网，但是根本就不是一个，眼见的同学就发现了，那么就不会被骗。

所以说这里就非常安全了，因为中间人不会得到CA机构的私钥，那么TA就改不了证书。

完整流程

左侧是客户端，右侧是服务端：

https>https://img-blog.csdnimg.cn/972fb2895a4b4e50bb97aa8785d07d95.png" alt="在这里插入图片描述" />

第⼀组(⾮对称加密): ⽤于校验证书是否被篡改. 服务器持有私钥(私钥在形成CSR⽂件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器客户端请求时，返回携带签名的证书. 客户端通过这个公钥进⾏证书验证, 保证证书的合法性，进⼀步保
证证书中携带的服务端公钥权威性。

第⼆组(⾮对称加密): ⽤于协商⽣成对称加密的密钥. 客户端⽤收到的CA证书中服务器的公钥(是可被信任的)给随机⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.

第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实⼀切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥⼯作的.

• 第⼆组⾮对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
• 第⼀组⾮对称加密的密钥是为了让客户端拿到第⼆组⾮对称加密的公钥

到此结束。。。