【网络】应用层——HTTPS协议

🐱作者：一只大喵咪1201
🐱专栏：《网络》
🔥格言：你只管努力，剩下的交给时间！

🍉HTTP的不安全性

前面本喵讲解并演示了HTTP协议，在比较POST和GET方法的时候，本喵说这两个方法都不安全，虽然POST的提交的表单内容在请求正文中，无法在地址的url中看到，但是它仍然是不安全的。

本喵服务器上的html代码中，提交表单的方式采用的是POST的方法。

使用浏览器请求服务端时，在得到的响应网页中填入姓名和密码，如上图所示，然后点击登录。

此时在服务端的请求正文中就看到了在浏览器表单中输入的姓名和密码。这很正常，因为这是服务端，能看到客户端的姓名和密码是理所当然的。

• 但是别人也能看到！！！

使用一个工具Fiddler，各位小伙伴可以自行百度下载，该工具是用来抓HTTP请求和响应的包的。

如上图所示便是使用Fillder抓到的前面浏览器的请求包，同样可以看到客户端输入的姓名和密码。

Fiddler是运行在Windows系统上的一个软件，浏览器是另一个运行在Windwos上的软件，而服务端是本喵使用的腾讯云服务器，和本喵的电脑都不在一个局域网中。

使用了Fillder后，浏览器向服务端发送的请求就被Fillder抓取到了一份。

• HTTP协议传输的数据都是明文传送的。

只要拿到浏览器发送的请求包，就可以看到请求包中的内容，所以可以看到Fillder抓取的请求正文中的姓名和密码。

如上图所示，Fiddler就是一个中间人，它位于Client客户端和Server服务端的中间，客户端发送给服务端的请求以及服务端发送给客户端的响应，它都能抓取到。

HTTP协议传输的内容又是明文传送，所以无论是请求还是响应，Fiddler都可以看到。

如果这个中间是一个黑客，是一个不法份子，那么他拿到请求和响应后就可能对我们造成一定的不良影响，尤其是像账号密码这样的私密内容。

🍉认识HTTPS协议

HTTP协议不安全的主要原因就是它传输的数据是明文传输，为了让传输的数据更安全，就需要将请求和响应中的数据进行加密，尤其是账号和密码等私密数据。

• HTTPS协议就是在HTTP协议的基础上引入了一个加密层。

如上图所示网络通信协议栈示意图中，蓝色线条表示HTTP协议传输数据，绿色线条表示HTTPS协议传输数据。

• HTTP：应用层→传输层→网络层→数据链路层→数据链路层(对端)→网络层(对端)→传输层(对端)→应用层(对端)
• HTTPS：应用层→加密层→传输层→网络层→数据链路层→数据链路层(对端)→网络层(对端)→传输层(对端)→加密层(对端)→应用层(对端)

HTTPS协议只是比HTTP协议多经过一个加密层，在经过之前仍然是HTTP协议，经过之后就成了HTTPS协议。

• 加密层也是位于软件层，具体的有ssl和tls。
• HTTP经过加密层中的加密算法后就变成了HTTPS协议，在到达对端后，需要经过对端加密层中的算法解密后变成HTTP协议，对端才能获取到传输的内容。

🍓加密解密

• 加密：把明文(要传输的信息)进行一系列变换，生成密文。
• 解密：把密文再进行一系列变换，还原成明文。
• 密钥：在加密解密的过程中，往往需要一个或多个中间数据辅助这个过程，这样的数据就称为密钥。

本喵再举一个例子来帮助大家理解：

如上图所示，客户端Client要发送一个数据int a = 100到服务器Server上，将a=100放入HTTP协议中后，此时这个数据是明文的，然后经过加密层加密形成密文int b = a ^ key，此时就变成了HTTPS协议。

• int key = 200中的这个key值就被叫做密钥。

当使用HTTPS协议将数据传输到服务器后，服务器首先拿到的是加密后的数据b，然后经过ssl/tls进行解密得到明文a = b ^ key = 100，此时就又变成了HTTP协议，服务端就可以直接拿到数据a了。

说明：

• 异或(^)支持交换律，如key ^ a ^ key = a ^ key ^ key = a。
• 相同的两个数相异或的结果为0。
• 任何一个数和0相异或都是数本身。

所以在上面数据传输过程中，加密后的数据成为b = a ^ key，在解密的时候，b ^ key = a ^ key ^ key = a就恢复到了明文。

当然真正的密钥不可能只是一个key值这么简单，它由有一个或者多个数据经过一定的逻辑运算。

🍓加密的原因

假设现在要下载一个“天天动听”软件：

正常情况下，弹出的下载界面如上图所示，下载的是一个apk的应用包，网址对应的是天天动听服务器的网址，使用的是HTTP协议。

上图是不正常的情况，下载的内容是名为qqbrowser的包，也就是QQ浏览器，网址对应的是QQ浏览器的服务器，使用的也是HTTP协议。

• 这就是臭名昭著的“运营商劫持”。

如上图所示，当客户端发起下载天天动态的请求时，请求被传输到了运营商设备或者公网中，此时运营商设备发现这是一个HTTP下载天天动态的请求，它悄悄的将这个请求变成了下载qq浏览器的请求。

原本应该传送到天天动态的下载请求没有传递到天天动听的服务器，如上图红色虚线所示，反而是将下载qq浏览器的请求传递到了qq浏览器的服务器上，如上图绿色线条所示。

此时qq浏览器就会返回一个下载链接，运营商设备再将这个链接返回给客户端。

如果客户端没有注意到下载框中的内容就点击了下载，那么最后下载下来的软件就是qq浏览器。

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

如上图所示，中间人存在于客户端和服务端之间，客户端和服务端之间的网络请求和响应他都能进行监听和篡改。

想想你下载软件的时候，一不小心就下载了一个全家桶。之所以会存在中间人，主要是因为：

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

• 试想⼀下，如果⿊客在用户登陆⽀付宝的时候获取到账户余额，甚至获取到用户的支付密码…

• 在互联⽹上，明⽂传输是⽐较危险的事情!!!。

🍉常见的加密方式

对称加密：

• 采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，也叫做单密钥加密。
• 特征：加密和解密所用的密钥是相同的。

对称加密其实就是通过同⼀个"密钥"，把明⽂加密成密⽂，并且也能把密⽂解密成明⽂。就像本喵在前面介绍加密解密的时候，那个key值就是密钥。

• 常见的对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等。
• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼。

非对称加密：

• 需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥(private key，简称私钥)。
• 特征：用私钥加密，必须用公钥解密，用公钥加密，必须用私钥解密。

公钥和私钥必须成对存在，一个用来加密，一个用来解密。就像古时候大臣给皇帝上的密折，大臣将折子放入一个箱子里并且锁上，然后将这个箱子通过特定途径给到皇帝，皇帝手里有一把钥匙可以打开这个箱子，只有大臣和皇帝手里有钥匙，别人即使拿着箱子也打不开。

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

⾮对称加密要⽤到两个密钥，⼀个叫做"公钥"，⼀个叫做"私钥"。公钥和私钥是配对的，最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多。

• 网络通信中，要解决的问题主要是：数据被监听，以及数据被篡改。

所以在进行正常的加密数据通信之前，先解决密钥如何能被对方安全收到的问题。

🍓只使用对称加密

建议：以下内容对照着图片阅读文字，图片的顺序是从上到下的，文字描述也是从上到下描述。

• 只有客户端有一把对称密钥C。

如果只使用对称加密，也就是客户端和服务端用一把密钥来进行加密和解密，第一步要做的事情就是让通信双方都知道密钥是什么。

如上图所示，当客户端将密钥发送给服务端的时候，由于此时发送的密钥是明文传输，也就是用的HTTP协议，中间人同样可以得到这个密钥。

此时即使服务端拿到密钥后，双方使用密钥进行加密通信也没有意义，因为密钥中间人手里也有，他可以进行解密，甚至篡改后再加密。

• 发送密钥只能使用HTTP协议进行明文传输，如果给密钥加密的话，那么第一把密钥怎么传过去的呢？此时就成了一个鸡生蛋蛋生鸡的问题了。

所以只使用对称加密的方式是无法保证数据传输的安全的。

🍓只使用非对称加密

• 只有服务端一对密钥，公钥S和私钥S’。

从上往下看，首先客户端在发起请求之前向服务端发起密钥协商。服务端收到客户端的密钥协商后，将自己的公钥推送给客户端(明文传输)。此时中间人也能拿到这个公钥，因为它是明文传送的。

客户端拿到公钥后，将要发送的请求使用公钥加密，然后发送给服务端，此时中间人即使拿到这个加密的请求也无法进行解密，因为他没有私钥。

服务端拿到加密了的请求后，使用私钥进行解密，就得到了请求的原文，然后根据具体的请求构建响应。

• 先假设服务端用公钥加密响应，然后发送出去，此时中间人虽然拿到了响应，但是由于没有私钥就无法解密。同样的客户端拿到公钥加密的响应后，也没有私钥，也就无法解密拿到原文，所以通信失败。
• 再假设服务端用私钥加密响应，然后发送出去，此时中间人拿到了响应，由于再密钥协商阶段中间人也拿到了公钥，所以就可以用公钥解密得到原文，从而进行监听或者篡改。同样通信失败。

• 公钥和私钥只有一对，在上图所示的过程中，全世界只有服务端有私钥，其他人都没有，公钥是全世界公开的，谁都知道。

• 上面所示的过程中，起码从客户端到服务端是安全的(暂时)，中间人即使拿到使用公钥后加密的数据也无法解密。

所以只是用非对称加密是无法保证通信安全的。

🍓双方都使用非对称加密

• 服务端有一对密钥，公钥S和私钥S‘。
• 客户端有一对密钥，公钥C和私钥C’。

客户端向服务端推送自己的公钥C，中间人也可以拿到，服务端收到公钥C后，向客户端推送自己的公钥S，中间人也能拿到。

客户端将自己的请求使用公钥S进行加密形成请求密文，然后发送给服务端，此时即使中间人拿到密文也无法解密，因为没有私钥S’。

• 服务端收到请求密文后，使用自己的私钥S’解密，得到请求原文。

服务端根据请求构建出响应，使用客户端的公钥C进行加密形成响应密文，然后发送给客户端，此时中间人拿到密文同样无法解密。

• 客户端收到响应密文后，使用自己是私钥C’解密，得到响应原文。

在上面客户端和服务端通信过程中，中间人能拿到明文的两把公钥C和S，但是没有私钥C’和S’，当客户端和服务端使用对方的公钥进行加密通信时，中间人没有任何办法，只能看着密文从眼皮下溜走。

可以看到，双方都使用对称加密是可以保证数据传输的安全的，但是依旧存在一个问题：效率太低。

非对称加密的效率相比于对称加密要低很多，而双方都使用对称加密，就会导致网络通信的速度奇慢，效率极低。

🍓非对称加密 + 对称加密

• 服务端有一对密钥，公钥S和私钥S’。
• 客户端有一把对称密钥C。

客户端向服务端发起公钥S请求，服务端收到请求后将自己的公钥S返回给客户端，中间人同样能拿到公钥S。

客户端再将自己的对称密钥C使用公钥S加密形成密文发送给给服务端，中间人也可以拿到密文，但是没有私钥S’无法解密得到对称密钥C。

服务端收到密文后用私钥S’解密得到对称密钥C，然后用对称密钥C加密响应形成响应密文发送给客户端，中间人仍然可以拿到密文，但是没有对称密钥C，无法解密。

客户端收到密文后，用对称密钥C解密，得到响应原文，表明服务器已经得到对称密钥C。

• 此后，客户端和服务端就可以使用对称密钥C进行加密和解密，即使中间人拿到密文也毫无办法。

对称密钥 + 非对称密钥的方式，既满足了通信的安全，又满足了高效的要求。

但是此时这种方式真的安全了吗？如果中间人从一开始就发起攻击呢？

• 服务端有一对密钥，公钥S，私钥S’。
• 客户端对称密钥C。
• 中间人有一对密钥，公钥M，私钥M’。

客户端请求公钥S，服务端收到以后返回公钥S，中间人可以拿到公钥S。

• 中间人将服务端的公钥S保存下来，将自己的公钥M返回给客户端。

客户端收到公钥M以后，并不知道已经被中间人掉包了，认为还是服务端的公钥，所以会使用公钥M加密自己的对称密钥C形成密文，然后再发送给客户端，中间人可以拿到密文。

• 中间人拿到密文后，使用自己的私钥M’解密得到对称密钥C，然后用截取下来的服务端公钥S加密对称密钥C形成密文，再将密文发送给服务端。

服务端拿到密文后，用自己的私钥S’解密得到对称密钥C，然后再用对称密钥C加密响应形成密文发送给客户端。

客户端收到响应密文后，认为服务端已经知道了对称密钥C，所以双方之后都使用对称密钥C进行通信。

• 但是通信双方并不知道，中间人也拿到了对称密钥C，中间人可以进行数据监听和数据篡改。

这样一看，采用非对称加密 + 对称加密的方式也并不安全，不安全的原因是客户端无法识别公钥的合法性。

• 双方都采用非对称加密的方式进行通信也会存在中间人提前攻击的问题。

也就是说，如果客户端在收到服务端发来的公钥后，能够验证这个公钥是服务端的公钥S，而不是中间人的公钥M，如果是中间人的公钥M就停止通信，如果是服务端的公钥S就继续通信。这样一来就能够保证通信的安全了。

该如何保证公钥的合法性呢？

🍉引入证书

🍓数据摘要(数据指纹)

• 数字指纹(数据摘要)：其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算，⽣成⼀串固定⻓度的数字摘要。
• 数字指纹并不是⼀种加密机制，但可以⽤来判断数据有没有被窜改。

如上图所示，有一个非常大的文本文件，该文件中的内容经过一个Hash算法后，形成一个长度固定的字符串，该字符串就被叫做数据摘要，也叫数据指纹。

• 有点像压缩文件的意思，但是生成的是一个数字摘要。

• 数字摘要可以做到，文件中只要有微小的改动，即使只是改变了一个标点符号，对应的数据摘要都会发生很大的变换。
• 文件内容和数字摘要是一一对应的。

• 摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）。
• 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常⽤来进⾏数据对⽐。

可以理解为，形成数据摘要使用的Hash方法是不可逆的。

用处：

那么数据摘要有什么作用呢？拿百度网盘的“秒传来举例”：

如上图所示，用户A有一部电影《战狼2》，把它上传保存在了百度网盘上，这个过程会耗费较长时间。

• 在上传之前，会先形成数据摘要，按照数据摘要在百度网盘的服务器中查找，如果没有相同的数据摘要，说明服务器中不存在，然后将用户资源保存在磁盘中。

此时用户B也有一部《战狼2》电影，也要上传到百度网盘中，这次上传就不用耗费很多时间。

• 在上传之前，《战狼2》同样会形成一个数据摘要，然后按照数据摘要在百度网盘的服务器中查找，发现有相同的数据签名，说明磁盘中有《战狼2》这部电影了。
• 此时就不会再上传，而是将用户A的《战狼2》保存位置返回给用户B，所以这次的上传速度就很快。

• 百度网盘并不是说你可用的空间有40GB就给你预留40GB等你来用，而是在你用的时候再给你分配空间。
• 如果遇到你上传的资源已经存在了，就不会再上传了，而是将已存在资源的路径给你，方便下次访问，这样做是为了节省内存，提高效率。

数据摘要的意义主要在于判读，因为两个大文本是不方便进行比较的，而两个固定长度的数据摘要比较起来很方便。

🍓数据签名

• 数据签名：将数据摘要用签名者的私钥加密，形成的密文就是数据签名。
• 注意，⽬前暂时和https没有关系，不要和https中的公钥私钥搞混了。

如上图所示形成数据签名的过程，数据先经过Hash函数生成数据摘要，然后用签名者的私钥对数据摘要加密，形成的密文就是数据签名。

要想获得该数据的数据摘要，只能使用签名者的公钥对数据签名解密，才能得到数据摘要。

• 这里的签名者拥有一对非对称密钥，一个私钥用来形成数据签名，一个公钥是公开的。

为什么数字签名不直接对证书原文加密，⽽是要先hash形成摘要呢？

• 这是为了缩小数字签名密⽂的⻓度，加快数字签名的验证，以及数字签名的运算速度。

🍓CA认证

• CA机构：它是采用PKI（Public Key Infrastructure）公开密钥基础架构技术，专门提供网络身份认证服务，CA可以是民间团体，也可以是政府机构。
• 作用：专门负责签发和管理数字证书，且具有权威性和公正性的第三方信任机构。
• 它的作用就像我们现实生活中颁发证件的公司，如护照办理机构。国内的CA认证中心主要分为区域性CA认证中心和行业性CA认证中心。

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

服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的合法性。

• 形成数据签名时候的签名者就是CA机构，他手里有一对非对称密钥，私钥只有他自己知道，公钥全世界公开。

证书申请：

如上图所示，服务器在申请证书的时候，先将信息填好，如上图所示的步骤1，包括公钥与私钥对，域名/申请者/公钥等信息，不包含服务端私钥S。

填好信息以后向CA机构提交，等待CA机构审核，如上图所示步骤2。

审核通过以后CA机构向服务端签发证书，如上图所示步骤3，证书中包含数据签名和申请信息等内容，其中申请信息这些内容都是明文信息，谁都可以看到，中间人也能拿到。

证书可以理解成为一个结构化的字符串，包含以下信息：

• 证书发布机构
• 证书有效期
• 服务端公钥
• 证书所有者
• …
• 数据签名

申请证书的时候，需要在特定平台⽣成，会同时⽣成⼀对⼉密钥对⼉，即服务端公钥和私钥。

其中公钥会随着CSR⽂件，⼀起发给CA进⾏权威认证，私钥服务端⾃⼰保留，⽤来后续进⾏通信。

填好信息后，点击生成CRS文件后，会有这样一个页面，分别是下载生成的私钥和CRS文件，其中私钥服务端自己保留，CRS文件用来提交CA审核认证。

证书如何保证服务端公钥不被掉包？

如上图所示，服务端在向CA机构提交证书申请以后，CA机构会生成一份证书，并且将证书的内容通过Hash函数形成数据摘要。

• 哈希函数是公开的，全世界都知道。

然后CA机构用自己的私钥给数据摘要加密，形成数字签名，最后再将数字签名附在证书上签发给服务端。

当客户端向服务端发起密钥请求后，服务端就会将附有数字签名的证书返回给客户端，此时中间人也能拿到这个证书。

• 证书中包含公钥信息，而且是公开的。

如上图所示，当客户端拿到服务端返回的带有数字签名的证书后，会进一步进行验证。

• 将证书和数字签名分开，并且将证书内容使用公开的Hash方法形成数据摘要1。
• 再使用CA机构公开的公钥，将数字签名进行解密，得到数据摘要2。

然后进行判断，如果数据摘要1 = 数据摘要2，那么说明证书是合法的，是由服务端发送来的，证书中的公钥S也是合法的，就可以将对称密钥C通过公钥S加密后发送给服务端，然后进行通信了。

如果此时中间人截取了服务端给客户端返回的带有数据签名证书，并且对其中的服务端公钥S进行了替换，然后又转发给了客户端。

当客户端收到被篡改的带了数字签名的证书后，进行验证，通过公开的Hash方法形成的数据摘要1和用CA机构公钥解密数字签名后得到数据摘要2并不相等，就说明证书被篡改了，接下来的通信也就不再进行。

• 由于CA机构的私钥其他人没有，所以CA机构颁发证书中的数字签名一经签发就是独一无二且永不改变的。

所以中间人修改了证书中的内容后，无法使用CA机构的私钥形成新的数据签名。

即使中间人用自己的私钥形成了新的数据签名，但是客户端在验证的时候是使用的CA机构的公钥，无法解密这个数据签名，也会验证失败。

• 每个浏览器中都内置了CA机构的公钥，解密证书中的数据签名时只能使用这个公钥。

如此一来，客户端就能验证服务端公钥的合法性了，即使服务端的公钥是明文传送的，中间人也没有办法对其进行修改，从而保证了后续网络通信的安全性。

🍓非对称加密 + 对称加密 + 证书认证

根据本喵前面的铺垫讲解，想来大家自己也能知道HTTPS采用的通信方式是什么了，采用的是非对称密钥 + 对称密钥 + 证书认证的方式。

• 非对称加密是为了保证对称密钥的安全性。
• 对称密钥是为了保证通信的高效安全。
• 证书认证是为了保证非对称密钥的合法性。

如上图所示，客户端先向服务端发起密钥请求，服务端收到请求后返回带有数字签名的证书，中间人也能拿到。

客户端收到证书后使用CA机构的公钥来验证证书的合法性，验证通过后是使用证书中的公钥S将自己的对称密钥C加密形成密文，然后发送给服务端。

服务端收到密文后使用自己的私钥S’进行解密得到对应密钥C，然后将收到密钥的响应通过对称密钥C加密形成密文，在发送给客户端。

客户端收到服务端的响应以后，使用自己的对称密钥C加密请求形成请求密文，然后在发送给服务端。

服务端收到请求密文后使用对称密钥C解密得到请求原文，再构建响应并且使用对称密钥C加密响应形成相应密文，然后再发送给客户端。

• 如此来就进行了安全的网络通信，中间人毫无篡改和监听的机会。

证书在我们平时上网的时候一定见过，在使用的浏览器中，点击右上方的三个点，选择"设置"，搜索"证书管理"，即可看到以下界⾯。(如果没有，在隐私设置和安全性->安全⾥⾯找找)

可以看到浏览器中存在着多个证书，这么多证书都是在访问不同的服务器时，服务器发送过来后保存在浏览器中的，方便之后直接通信。

点击某个证书后，会弹出来证书的详细内容，如上图所示，包括序列号有效时期公钥等等内容。

• 绿色框中的16进制数就是对应服务端的公钥S。

有时候我们在访问某些网站的时候，会出现上图所示的提示框，提示我们证书不安全，说明此时浏览器在认证证书的时候没有通过，可能是被篡改，也可能是证书有效时间过了等等原因。

如果继续浏览，浏览器就会继续进行访问通信，但是会有数据被篡改以及监听的风险。

如果点击关闭则结束这次访问，也就不再和服务端进行网络通信了。

如上图就是客户端和服务端使用HTTPS进行网络通信的完整流程。

上面本喵是按照中间人篡改证书内容来分析，得出结论是中间人不能修改，修改了客户端就无法通过认证，进而就不会继续通信。

那么中间人能不能掉包整个证书呢？答案是不能的：

• 因为中间⼈没有CA私钥，所以⽆法制作假的证书，假证书中的数据签名浏览器是无法用CA公钥解密的。

除非中间人向CA机构申请一个真证书，然后用自己申请的证书进行掉包，这样确实能做到整体掉包。

• 但是，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能识别出来域名等信息和要访问的信息不一致。
• 并且CA认证的是实名制的，没有哪个中间人会那么傻。

记住一点：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的。

🍉总结

最后一个话题，难道使用这样的方式中间人就真的没有办法破解了吗？不是的。

• 世界上没有破解不了的加密，只是代价太高了。

只要付出足够大的代价，比如使用有足够高算力的计算机，再花费巨大的人力物力时间成本，任何加密方式都可以破解，包括服务端的私钥S’，客户端的对称密钥C，甚至是CA机构私钥M’都可以破解。

但是这么做就不值得了，中间人付出的代价比他破解后得到的利益还多的多，所以注定这样的事情就没人会去干。

这篇文章中，本喵并没有演示HTTPS协议的通信代码，主要是因为本喵申请不到CA机构的证书。。。文章来源地址https://www.toymoban.com/news/detail-626556.html

到了这里，关于【网络】应用层——HTTPS协议的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！