带你通俗理解https

十年编程老舅

于 2024-07-18 14:58:02 发布

阅读量313

点赞数 3

分类专栏： C++Linux后端文章标签： https 服务器网络协议网络协议栈网络编程网络

本文链接：https://blog.csdn.net/m0_73443478/article/details/140523290

版权

C++Linux后端专栏收录该内容

19 篇文章 2 订阅

订阅专栏

从一个例子说起

背景

假如你穿越回高中，你和你女朋友在教室遥远的对角落，只能通过传纸条来进行交流（不能直接说话，不然会被抓到早恋，hh），但是又不想纸条的内容内中间传递人给看到，那怎么样才能达到这样的效果呢？

STEP ONE

这里我们假设男女对象是A和B，中间传递纸条的人为C

这个时候第一想法就是，使用对称加密的方式，A使用秘钥对消息进行对称加密，然后B也通过同一份秘钥进行解密，这样就算C看到消息，也是密文，但是有个问题，之前也说了A和B是不能直接说话的，那么这个秘钥A怎么告诉B呢，有人说再加密。。那就回到了鸡生蛋蛋孵鸡的问题了

STEP TWO

为了解决上面的问题，我们引出了非对称加密的概念，特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人

那假如B持有公钥，自身生成STEP1中约定加密的私钥（一般使用随机数），然后用公钥将此私钥进行加密，然后A使用非对称加密的私钥进行解密拿到B生成的私钥，然后再用STEP1中的方法进行加解密消息。这样就是C拦截到消息，由于只有A有非对称加密的私钥，也无法解密出协商的私钥

有朋友可能就有疑问了，既然非对称加密可以达到这样的效果，为啥还要用非对称加密来协商出一个私钥，再用对称加密进行消息加密交互，直接用非对称加密加密消息不就行了，这里就涉及到了一个速度以及消耗性能的问题，对称加密会比非对称加密的速度更快，计算量小等优点，详细的老哥们可以深入了解下

STEP THREE

所以现在问题又来了，这个B的非对称加密公钥怎么得到呢？首先第一想到的方案由A给B发送过去，那么不禁就会有疑问，如果C拿到了这个公钥，会不会产生问题呢，不仔细思考的可能觉得没啥问题，毕竟私钥只有一份在A那里，只要B是使用公钥进行加密了，只有A才能解密，C也没啥办法。

但是会出现一个问题，这里假设A那边的公私钥称为X/Y，A将公钥X发送给B，C拦截到消息，但C自己也有一套公私钥，这里称为J/K，C拿到公钥X后，把自己的公钥J发送给了B，这个时候B是不知情的，将数据用C给的公钥J加密后返回，这个时候C又可以通过私钥K进行解密，得到了B的数据，假设C将数据修改后，再通过之前的X公钥进行加密，然后再传递给A，A也可以通过Y进行解密

引用一张图方便帮助大家理解下

STEP FOUR

公钥被掉包的问题，其实也就是身份验证的问题，B无法验证这个公钥到底是A给的还是C掉包之后给的。

所以怎么解决这个问题，再进行加密解密，感觉又要进入到鸡生蛋蛋孵鸡的问题了，所以，A不能够直接将公钥传递给B，通过一个信任的第三方（假如兄弟闺蜜啥的，hh）用私钥将公钥进行加密后，再传递给B，B通过公钥解密出最终A要传递的公钥，如果最终能够解密出来，说明这个公钥是没有经过C给掉包的，假如STEP 3的情况，C使用自己的私钥加密后，B是无法使用第三方的公钥解密的。

那么现在问题也就回到一点，B是怎么获得到第三者的公钥的呢，其实答案是B自己内置了这些第三者的公钥的，可以理解为B是信任这些第三方的，内部会维护一个信任的第三方公钥列表，只要是通过这些信任列表中的加密之后的东西，B是可以通过公钥解密出来的

这里的第三方映射到https的话，也就是CA机构了，客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内