今天我们来聊一聊HTTPS加密那点事
我们知道HTTP协议是明文传输的，这就可能存在信息泄露的风险。那如何才能规避这样的问题呢？
简单，可以用对称加密啊，那么问题来了：
啥是对称加密？
对称加密：加密和解密使用相同的秘钥。也就是说，这种方法需要你（客户端）先将秘钥发送给对方（服务器），然后对方才能使用该秘钥解密你的密文。
缺点：显然，秘钥使用明文发送的，就是说攻击者可以在你发送秘钥的过程中将其窃取，然后就能使用该秘钥**你发的密文了。
既然对称加密不安全，那可咋办？别急，这不非对称加密就来了。
啥是非对称加密啊？
非对称加密：加密和解密使用不同的秘钥，公钥加密，对应的私钥解密，私钥加密，对应的公钥解密。公钥可以随意发布，而私钥只能自己持有。比如你想给对方发信息，你先用对方发给你的公钥把信息加密，然后在把密文发给对方，对方收到后用自己的私钥解密即可。攻击者即使截获了你发送的密文，他没有对应的私钥也解不开。
缺点：你得承认，非对称加密很牛批，但是由于它多了很多加密解密操作，因此实际使用时效率较低，比对称加密的方式要慢很多。
那怎么整才能进一步优化非对称加密呢？
我们知道，对称加密的缺点就是无法将秘钥安全的交给目标方。那我们是不是可以用对称加密+非对称加密结合的方法来解决这个问题呢？具体操作如下：
你要跟对方通信，对方先明文方式给你发来了他的公钥，你收到后，自己先生成一把秘钥（等会对称加密用的），然后用对方的公钥对这把秘钥加密，之后再把加密后的秘钥发送给对方，对方用自己的私钥对其解密，拿到你刚才自己生成的秘钥，此时你们俩都有同样的秘钥了，就可以进行对称加密了。
偷偷告诉你，其实，HTTPS就是采用了这种混合加密的方法，将对称和非对称加密的优势结合起来（又快又安全）。牛批呀！
有了非对称加密你以为就万事大吉了么？那就大错特错了，为啥这么说？
相信聪明的你已经看出非对称加密也存在安全问题：
那就是公钥的准确性无法保证，即你无法确定你收到的公钥是不是真的属于你要发信息的目标方，公钥可能被攻击者篡改。就像下面这样：
可以看出，上述过程中的攻击者拿到了对称加密的**，在之后服务器和客户端的对称加密传输中，加密的数据对攻击者来说也就不在是秘密了。
既然非对称加密也不安全，那能咋办？这就需要数字证书登场了。
通过上述分析可知，非对称加密不安全是因为客户端不知道公钥是否属于服务器，因此就需要有一种方法来证明这把公钥确实是属于服务器的，而不是被冒充的。怎么证明呢？用数字证书。那么问题来了，数字证书是啥？如下：
前提是需要有一个有公信力的证书认证机构(CA，Certificate Authority)，认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上，如威瑞信（VeriSign）。然后，服务器向CA提交公钥、服务器个人信息并申请认证，然后CA经过各种方法对信息审核，如果审核通过，最后会给申请者（服务器）颁发数字证书。证书内容包含了服务器的公钥、服务器相关信息、一个数字签名等。
那么问题又来了，数字证书是怎么形成的？
首先，CA把服务器公钥以及其相关信息通过Hash算法生成信息摘要。像这样：
接着，为了避免这个信息摘要被攻击者调换，CA利用自己的私钥对该信息摘要进行加密形成数字签名。像这样:
最后，CA还会把数字签名和最开始没经过Hash处理的服务器信息、公钥合并在一起，形成一个数字证书发送给服务器。像这样：
客户端拿到服务器发给它的这个数字证书后，会先用CA提供的公钥解密证书里的数字签名从而获得信息摘要，然后对数字证书里服务器的公钥和服务器信息进行Hash得到新的一个信息摘要。最后将这两个信息摘要做对比，如果相同，则证明这个服务器是真实的，否则不是。像这样：
可能你还会问了，客户端是如何拿到CA的公钥呢？其实，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开**。哈哈，想不到吧！
至此，就可以保证服务器的公钥安全发给客户端了，它们就可以愉快的通信了。
最后，简单总结一下HTTPS通信过程：
行了，今天就说这些吧，大伙儿明没明白？明白了吧。