Https是如何保证通讯安全的

• 这个问题困扰了很久，最近看了资料，总结一番，总结不到位的地方还请指出
• http是明文传输而https加密传输（http的发展历史及各版本的差异，报文头这里就不介绍了，有兴趣的同学自己查阅资料）这是它们最大的区别。那https是如何达到安全传输的呢，这个需要先了解下http与https的osi层次结构(图来源《图解http》)

很明显https 是在tcp与http之间添加了一层ssl（Secure Sockets Layer）层，俗称安全套接层

• SSL释义：请参看这里博文，有详细讲解：
  https://www.jianshu.com/p/6c981b44293d
• 理解https的安全传输需要先了解两种加密算法，因为在整个https通讯过程使用两种加密算法，一种非对称加密算法，另一种对称加密算法

• 非对称加密算法：这种加密或许理解起来比较困难，这种加密指的是可以生成一对密钥 (k1, k2)。凡是 k1 加密的数据，k1 自身不能解密，而需要 k2 才能解密；凡是 k2 加密的数据，k2 不能解密，需要 k1 才能解密。这种算法事实上有很多，常用的是 RSA，其基于的数学原理是两个大素数的乘积很容易算，而拿到这个乘积去算出是哪两个素数相乘就很复杂了。好在以目前的技术，分解大数的素因数确实比较困难，尤其是当这个大数足够大的时候（通常使用2的10次方个二进制位这么大），就算是超级计算机解密也需要非常长的时间
• 对称加密算法简单来说就是加密与解密使用的密钥是一样的。

有了这两种算法做基础之后对后面的内容就好理解了。我们现在来一步一步揭开https的面纱。
先假设有两台计算机需要通信，它们的情况大致是这样：

如果不进行加密传输，裸传就是http传输了，很容易被拦截。假设计算A与计算机B之间约定使用Key1=(20202020liuhulai)这个密钥对报文内容进行加解密，即发送方使用key1对待发送的内容进行加密处理，接收方使用key1对接收过来的内容进行解密处理，看似已经达到了安全传输的效果，但如何保证计算机A安全的将key1发送给计算机B呢？如果这个阶段被拦截了那么key1就被泄露了，别人就可以假冒发送方 计算机A 向接收方 计算机B 发送信息了，还是没达到安全传输的效果。现在问题是需要保证key1能够安全在网络上传输，很明显不能再使用对称加密来保护这个key1的安全传输了，聪明的人类于是引入了非对称加密：

这种方法就是，让客户端和服务器都拥有两把钥匙，一把钥匙是公开的(全世界知道都没关系)，我们称之为公钥；另一把钥匙则是保密的(只有自己本人才知道)，我们称之为私钥。并且用公钥加密的数据，只有对应的私钥才能解密；用私钥加密的数据，只有对应的公钥才能解密。

于是按照这种方法来保证key1在网络上的安全传输，它的过程大致如下图：

这种方式貌似已经达到了，但是在第一步计算机B明文传输自己的公钥时又存在泄露的风险，被人拦截之后使用假冒的的公钥假设为key2,发送给计算机A,接着计算机A收到这个报文之后，使用key2对 key1 再进行加密传输，中间人拦截到这个报文之后使用自己的私钥进行解密得到key1，然后再伪造一个key1_1通过计算机B的公钥发送给计算机B，于是计算A与计算机B整个通讯过程都暴露在中间人眼皮底下，无异于裸奔，这种现象就是中间人攻击。

导致这个问题的根本原因是计算A无法知道这个公钥是否来自计算机B。

科学是向前发展的，充满智慧的人类总是能克服一个一个困难。因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的。我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。于是就诞生了数字证书。它的具体过程是这样的：
计算机B在给计算机A传输公钥的过程中，会把公钥以及个人信息通过Hash算法生成信息摘要。如图：

为了防止信息摘要也被人调换，计算机B还会用CA提供的私钥对信息摘要进行加密来形成数字签名。如图:

并且，最后还会把原来没Hash算法之前的个人信息以及公钥 和 数字签名合并在一起，形成数字证书（回想下在使用https通信时是不是需要内置一份证书文件）。当计算机A拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。
如图：