前言
个人原因最近要离开杭州了，接下来也不知道去哪，其实挺想去深圳发展，但是不知道行情怎么样，有没有深圳的老哥们，介绍一波，哈哈~
好了，废话不多说，本文主要尝试着用简单的语言来解析下HTTPS的原理，或者说HTTPS的实现思想，但并不保证真正的实现过程，老哥们可以自行参考
从一个例子说起
背景
假如你穿越回高中，你和你女朋友在教室遥远的对角落，只能通过传纸条来进行交流（不能直接说话，不然会被抓到早恋，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机构了，客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内
总结
这里再将上面的例子替换成https，总结下大概流程
-
服务端先持有非对称加密的公私钥，将公钥发送给第三方CA机构，CA机构通过自身私钥加密公钥，返回数字证书，服务端将数字证书发送给客户端
-
客户端通过数字证书，通过信任证书列表拿到改机构的公钥进行解密，拿到非对称加密的公钥
-
客户端自身通过随机数算法等等生成对称加密算法私钥，通过第二步拿到的公钥将此私钥进行加密
-
服务端通过本身的私钥进行解密，拿到客户端生成的私钥
-
服务端、客户端通过此私钥，使用对称加密算法进行交互，保证数据安全
总结来说Https是通过对称加密算法+非对称加密算法+第三方CA机构实现的，使用CA结构拿到正确的非对称加密的公钥，使用公钥加密对称加密算法的私钥，最终使用对称加密算法进行消息加解密。
网友评论