This article today, speaking in the form of dialogue, so that you know the Deep, Why Https is safe.
A symmetric encryption
A Zen: before each sending real data, Mr. servers into a key, the key first and then transmitted to the client. After the server sends real time data to the client, the data will be encrypted using this key, after the client receives the encrypted data is decrypted with a key just received. Figure:
Of course, if the server sends the client data to give, also uses this key to encrypt, here for convenience, I use the form of one-way transmission
White: What if you key in the process of transmission intercepted by others how, right?
E.g:
If the server key with clear text transmission to the client, then the key is to capture the middleman, and then encrypted transmission server after the client process intermediary may be decrypted by the key he captured. In this case, the encrypted data in clear text and intermediaries seems no different
Second, asymmetric encryption
A Zen: This is to allow the client and the server has two keys, one key is public (the world that does not matter), we call the public; another key is kept secret (only own people know this), we call the private key. And this, with the public key to encrypt data, only the corresponding private key can decrypt; data encrypted with the private key, only the corresponding public key can decrypt .
In this way, the server to the client in the process of transmission of data, you can use the customer expressly give his public key to encrypt the end, and then the client receives, then his private key to decrypt it. When the client sends data to the server to take this way too. Thus maintaining the security of data transmission. Draw a map to understand this:
一禅：处理方式就是结合 对称加密+非对称加密这两种方式，我们可以用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据了。具体是这样子的：
服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全着得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。
小白：例如：
服务器以明文的方式给客户端传输公钥的时候，中间人截取了这把属于服务器的公钥，并且把中间人自己的公钥冒充服务器的公钥传输给了客户端。
之后客户端就会用中间人的公钥来加密自己生成的密钥。然后把被加密的密钥传输给服务器，这个时候中间人又把密钥给截取了，中间人用自己的私钥对这把被加密的密钥进行解密，解密后中间人就可以获得这把密钥了。
最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。如图：
毫无疑问，在这个过程中，中间人获取了对称加密中的密钥，在之后服务器和客户端的对称加密传输中，这些加密的数据对中间人来说，和明文没啥区别。
数字证书登场
在刚才的讲解中，我们知道，之所以非对称加密会不安全，是因为客户端不知道这把公钥是否是服务器的，因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的。
解决这个问题的方式就是使用数字证书，具体是这样的：
我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。
服务器在给客户端传输公钥的过程中，会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。如图
为了防止信息摘要被人调换，服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名。如图:
并且，最后还会把原来没Hash算法之前的个人信息以及公钥 和 数字签名合并在一起，形成数字证书。如图
当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。如图：
这样，就可以保证服务器的公钥安全着交给客户端了。
其实，(有些)服务器一开始就向认证中心申请了这些证书了(有没有看过没有证书的网站在地址栏会被标出警告？)，而客户端是，也会内置这些证书。如图：
当客户端收到服务器传输过来的数据数字证书时，就会在内置的证书列表里，查看是否有解开该数字证书的公钥，如果有则…，如果没有则…
看完有收获？那么希望老铁别吝啬你的三连击哦
1、点赞，可以让更多的人看到这篇文章
2、关注我的原创微信公众号『苦逼的码农』，第一时间阅读我的文章。公众号后台回复『电子书』，还送你一份电子书大礼包哦。
3、也欢迎关注我的博客哦。
作者简洁
作者：帅地，一位热爱、认真写作的小伙，目前维护原创公众号：『苦逼的码农』，以写了150多篇文章，专注于写 算法、计算机基础知识等提升你内功的文章，期待你的关注。
转载说明：务必注明来源（注明：来源于公众号：苦逼的码农， 作者：帅地）