本文将会通过对话的形式展开。
老师:可以讲讲http协议有啥缺点吗?
小白:这种协议没有对数据进行加密,都是明文传输的。
老师:如果让你去改进,你会怎么改呢?
一、对称加密
小白:emm….这个还不简单,我们可以用对称加密的方法对数据进行加密呀!具体的过程如下:
:::info
在每次发送真实数据之前,服务器先生成一副秘钥,然后先把秘钥发送给客户端。
之后服务器给客户端发送数据时,会用这把秘钥对数据进行加密。
客户端在收到加密数据后,用刚才收到的秘钥进行解密。
:::
:::info
当然了,如果客户端要给服务器发送数据,也是采用这把秘钥进行加密。
:::
老师:那我有个小问题,服务器是怎么把秘钥传输给客户端的呢?
小白:密钥的传输当然是采取明文的方式呀!
老师:那万一秘钥在传输过程中被别人截取了怎么办?这样他人也可以对密文进行解密了。
小白:嘶…我倒是没想过这方面。
老师:知道对称加密的问题出在哪里了吗?
小白:问题出在了怎么把密钥安全地传输到客户端。
老师:有想到什么办法吗?
二、非对称加密
小白:我知道了…我们可以采取非对称加密的方法来处理,具体如下:
:::info
让客户端和服务器双方都有两把钥匙,一把为公钥,另一把为私钥(只有自己知道)。
用公钥加密的数据,只有对应的私钥才能解密;用私钥加密的数据,只有对应的公钥才能加密。
:::
服务端在给客户端传输数据的过程中,可以用客户端明文给它的公钥进行加密; 然后客户端收到后,再用自己的私钥进行解密。 客户端发送数据给服务器也是采取一样的方式,这样就能保持数据的安全传输。

老师:还不错还不错…不过你知道这两种方法的区别吗?
小白:好像非对称加密在加密的时候速度特别慢,比对称加密慢了百倍。
老师:确实是这样,可以优化一下吗?
小白:啊?这要怎么优化呀!
老师:我提示一下,对称加密之所以不安全,是因为密钥无法安全到达客户端。
小白:我知道怎么处理了。
三、非对称+对称加密结合
小白:我们可以采用非对称加密的方式来传输对称加密过程中的密钥,之后我们就可以采取对称加密的 方式来传输数据了。
:::info
服务器用明文的方式向客户端发送自己的公钥。
客户端收到公钥后,会生成一把密钥(对称加密用)。
然后用服务器的公钥加密自己的私钥传输给服务器。
服务器收到之后进行解密,最终服务器就能安全得到这把秘钥了。
客户端此时也有一把相同的秘钥,他们就可以进行对称加密了。
:::
老师:其实你知道吗?非对称加密也并非传输安全的。
小白:为啥嘞?
老师:我来给你举个例子。
:::info
服务器以明文的方式给客户端传输公钥时,中间人截取了这把公钥
并把中间人自己的公钥冒充服务器的公钥传输给了客户端。
之后客户端用中间人的公钥加密自己的密钥,然后把被加密的密钥传输给服务器
这个时候中间人又把密钥截取了,中间人用自己的私钥对这把秘钥进行解密,解密后中间人可以获得这把密钥了。
最后中间人再对这把秘钥对刚才的服务器的公钥进行加密,再发送给服务器。
:::
:::info
通过这种方法,中间人可以获取对称加密中的密钥
:::
小白:还有这种操作,那岂不是非对称和对称加密没啥区别?
老师:还是有区别的。非对称加密之所以不安全,是因为客户端不知道这把公钥是否属于服务器的
小白:那该怎么办?
老师:你听说过数字证书吗?
小白:没有
老师:今天让你涨涨知识吧。
四、数字证书
在刚才的讲解中,我们知道,之所以非对称加密会不安全,是因为客户端不知道这把公钥是否是服务器的,因此,我们需要找到一种策略来证明这把公钥就是服务器的,而不是别人冒充的。
解决这个问题的方式就是使用数字证书,具体是这样的:
我们需要找到一个拥有公信力、大家都认可的认证中心(CA).
服务器在给客户端传输公钥的过程中,会把公钥以及服务器的个人信息通过Hash算法生成信息摘要,同时,为了防止信息摘要被人调换,服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名。如图:
并且,最后把原来没 hash 算法之前的个人信息以及公钥和数字签名合并在一起,形成数字证书。如图
当客户端拿到这份数字证书,之后,就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要,然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比,如果一样,则证明这个人是服务器,否则就不是。如图:
这样就可以保证服务器的公钥安全地交给客户端了。
小白:哦哦,原来如此。可是CA的公钥是怎么拿给客户端的呢?服务器又怎么会有CA的私钥呢?
老师:其实,有些服务器开始就向认证中心申请了这些证书了,而客户端是,也会内置这些证书。
老师:当客户端收到服务器传输过来的数据数字证书时,就会在内置的证书列表里,查看是否有解开该数字证书的公钥,如果有则,如果没有则.…
小白:感觉又学到了不少…
老师:确实,学习的路还很长。
