https是如何保证一台主机把数据安全发给另外一台主机

经过漫画的形式由浅入深带你读懂htts是如何保证一台主机把数据安全发给另外一台主机的

对称加密

一禅：在每次发送真实数据以前，服务器先生成一把密钥，而后先把密钥传输给客户端。以后服务器给客户端发送真实数据的时候，会用这把密钥对数据进行加密，客户端收到加密数据以后，用刚才收到的密钥进行解密。如图：

固然，若是客户端要给服务器发送数据，也是采用这把密钥来加密，这里为了方便，我采用单方向传输的形式

小白：那万一密钥在传输的过程当中被别人截取了怎么吧?

例如：

假如服务器用明文的方式传输密钥给客户端，而后密钥被中间人给捕获了，那么在以后服务器和客户端的加密传输过程当中，中间人也能够用他捕获的密钥进行解密。这样的话，加密的数据在中间人看来和明文没啥两样

非对称加密

一禅：这种方法就是，让客户端和服务器都拥有两把钥匙，一把钥匙是公开的(全世界知道都不要紧)，咱们称之为公钥；另外一把钥匙则是保密的(只有本身本人才知道)，咱们称之为私钥。这且，用公钥加密的数据，只有对应的私钥才能解密；用私钥加密的数据，只有对应的公钥才能解密。

这样，服务器在给客户端传输数据的过程当中，能够用客户端明文给他的公钥进行加密，而后客户端收到后，再用本身的私钥进行解密。客户端给服务器发送数据的时候也同样采起这样的方式。这样就能保持数据的安全传输了。画个图理解一下：

一禅：处理方式就是结合 对称加密+非对称加密这两种方式，咱们能够用非对称加密的方式来传输对称加密过程当中的密钥，以后咱们就能够采起对称加密的方式来传输数据了。具体是这样子的：

服务器用明文的方式给客户端发送本身的公钥，客户端收到公钥以后，会生成一把密钥(对称加密用的)，而后用服务器的公钥对这把密钥进行加密，以后再把密钥传输给服务器，服务器收到以后进行解密，最后服务器就能够安全着获得这把密钥了，而客户端也有一样一把密钥，他们就能够进行对称加密了。

小白：例如：

服务器以明文的方式给客户端传输公钥的时候，中间人截取了这把属于服务器的公钥，而且把中间人本身的公钥冒充服务器的公钥传输给了客户端。

以后客户端就会用中间人的公钥来加密本身生成的密钥。而后把被加密的密钥传输给服务器，这个时候中间人又把密钥给截取了，中间人用本身的私钥对这把被加密的密钥进行解密，解密后中间人就能够得到这把密钥了。

最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。如图：

毫无疑问，在这个过程当中，中间人获取了对称加密中的密钥，在以后服务器和客户端的对称加密传输中，这些加密的数据对中间人来讲，和明文没啥区别。

数字证书登场

在刚才的讲解中，咱们知道，之因此非对称加密会不安全，是由于客户端不知道这把公钥是不是服务器的，所以，咱们须要找到一种策略来证实这把公钥就是服务器的，而不是别人冒充的。

解决这个问题的方式就是使用数字证书，具体是这样的：

咱们须要找到一个拥有公信力、你们都承认的认证中心(CA)。

服务器在给客户端传输公钥的过程当中，会把公钥以及服务器的我的信息经过Hash算法生成信息摘要。如图

为了防止信息摘要被人调换，服务器还会用CA提供的私钥对信息摘要进行加密来造成数字签名。如图:

而且，最后还会把原来没Hash算法以前的我的信息以及公钥 和 数字签名合并在一块儿，造成数字证书。如图

当客户端拿到这份数字证书以后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来获得信息摘要，而后对数字证书里服务器的公钥以及我的信息进行Hash获得另一份信息摘要。最后把两份信息摘要进行对比，若是同样，则证实这我的是服务器，不然就不是。如图：

这样，就能够保证服务器的公钥安全着交给客户端了。

其实，(有些)服务器一开始就向认证中心申请了这些证书了(有没有看过没有证书的网站在地址栏会被标出警告？)，而客户端是，也会内置这些证书。如图：

当客户端收到服务器传输过来的数据数字证书时，就会在内置的证书列表里，查看是否有解开该数字证书的公钥，若是有则...，若是没有则....

有收获?不妨点个赞，让更多的人看到这篇文章！

文章首发于个人公众号「苦逼的码农」，更多精彩文章能够关注下我哦。

后台回复「666」送你一份我整理的电子书单