【web安全】HTTPS原理全解析

HTTPS

HTTPS保证了我们传输过程中的传输安全。
今天就解析一下HTTPs到底是非对称加密还是对称加密。
首先先介绍一个场景那就是我们不进行加密我们明文传输会怎么样呢？

如果我们明文传输的化我们的数据就会跑在网络上，如下图所示如果黑客从中间接入的化我们的数据（用户名、密码、交易数据等）就很容易被窃取所以明文传输显然是不可取的。
https://img-blog.csdnimg.cn/20210505192225731.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1MDM0NTQx,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
然后我们看一下对称加密，首先介绍一下什么是对称加密，对称加密会有一个密钥k
，客户端通过密钥k进行加密服务端通过密钥进行解密拿到数据这样的加密是否就是可取的呢？
如下图所示黑客从中间接入拿到了密文x1这样是否就安全了呢，其实并不是因为客户端制定k的时候这个k所有用户的k都是相同的只有一个所以黑客手里也会有一个k，最终黑客还是通过客户端的k拿到了数据。

https://img-blog.csdnimg.cn/20210505191525444.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1MDM0NTQx,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
那么对称加密不够安全的化，我们再来看一下非对称加密是不是安全的呢？

收先非对称加密会有一个公钥和一个私钥，如果通过公钥加密那么就需要私钥来解密如果用私钥来加密那么就需要公钥解密。这样看来服务端的私钥是只有服务端才有的所以是安全的，那么我们服务端传回数据的时候显然是不安全的，因为黑客也是一个普通的用户客户端，所以他完全可以在服务端传回来的过程来截取这个数据通过自己的公钥来进行解密。
https://img-blog.csdnimg.cn/20210505191251906.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1MDM0NTQx,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
这样看来对称加密和非对称加密都是不安全的，首先我们来看对称加密他的唯一缺点是k只有一个如果k每个用户只有一个的话那就可以实现安全传输了，再来看非对称加密他的缺点是传输回来时不安全的两者各有优缺点，那么两者结合是否可行了呢?

现在将对称加密和非对称加密联系在一起，通过非对称加密的方式来向服务端索要公钥，然后通过公钥进行加密，这次加密的就不是我们的数据而是客户端定义的一个字符串（因为客户端传输给服务端是绝对安全的所有服务端拿到的密文字符串只有服务端知道），当服务端拿到了num1密文会返给客户端告诉客户端服务端已经拿到了密文，之后的传输通过这么num1就作为之后对称加密的k了

这样的传输方式在目前来看已经很安全了。
https://img-blog.csdnimg.cn/20210505191254823.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1MDM0NTQx,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
这个时候如果黑客，非常厉害他在索要公钥的过程的时候就开始介入，他作为中间人做为一个媒介作用客户端索要公钥的请求被黑客拦截然后黑客也有一个自己的私钥和公钥他把自己的公钥返给客户端，这个时候客户端就会把加密的num1发给了黑客，黑客就可以通过自己的私钥解密num1然后发给客户端一个ok，接下来的操作黑客就可以拿到所有的数据了。

https://img-blog.csdnimg.cn/20210505195604396.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1MDM0NTQx,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
这样看来对分加密和非对称加密并不是那么无懈可击。

那么如何解决这个问题呢，
这个时候我们需要引入一个认证机构Certificate Authority 证书授权简称CA机构，
我们的服务端是有公钥pk和私钥sk的，CA机构也是有一个公钥和私钥我们叫他CPK和CSK，有了这个机构我们就不让客户端请求我们的公钥了，我们的公钥会在CA机构进行一个加密得到一个认证的lievse，让我们的客户端直接请求liervse然后客户端通过请求CA机构的cpk来进行解密,那么这个时候黑客截获好像也是可以截获的，所以我们的CPK就写死在客户端这样黑客就无能为力了，按照上面的对称加密和非对称加密就确保了数据的安全性。
https://img-blog.csdnimg.cn/20210505200450184.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzE1MDM0NTQx,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
对称加密+非对称加密+CA机构认证保证了我们数据传输的安全性。

ok是一个商议的过程前面以ok代替方便理解，现在来详细讲一下这个过程是怎么样的，以访问百度为例

客户端想服务端发送请求，请求是携带了一些东西有支持SLL的版本、非对称加密的算法，num1
服务端拿到了请求之后就知道了这些数据就定下来支持SLL的版本、使用的算法、num2、再加上一个证书传给客户端
客户端开始认证这个证书，如果成功接着下面的请求，如果失败了那网页就会弹出证书有问题
认证成功后向服务端发送数据，数据又num3、然后就会进行一个散列算法 hash（第一步和第二步的交互数据）就行一个加密的到一个x
服务端收到数据先认证xx是不是等于hash（第一步和第二步的交互数据）如果是那就没问题，如果不是就认证是黑客传上来的东西，那如果认证成功了就将num1、num2、num3经过一个转换策略转换成k
服务端告诉客户端传输回来的是hash（第一步、第二步、第四步交互数据）=zz
客户端然后确定一下zz是否等于hash（第一步、第二步、第四步交互数据）如果相等那么就会将num1、num2、num3通过的一种转换策略转换成k这个k应该和服务端是相同的.

总结：HHTPS使用了对称加密、非对称加密、Hash算法、CA认证。