HTTPS底层原理及其安全原理

HTTPS底层原理及其安全原理

平时我们在访问网页的时候一般都是直接输入域名，如www.baidu.com。而这种情况下，是先走HTTP的（后面有了改进，后面会提到）。

HTTP协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，因此通信过程非常容易遭遇劫持、监听、篡改。

既然HTTP是明文传输才引发的这一问题，那我们自然而然地就想到了对数据进行加密传输：

可是哪怕是加密了，这并不代表着就是安全了的，就像上图所示的那样，哪怕客户端用加密算法将数据进行了加密，代理服务器仍然可以截获加密算法和相关数据（因为HTTP是明文传输，所以无论发什么都可以被截获并破解）。中间代理服务器截获了加密算法和加密后的数据，有了加密算法，就可以用加密算法解密数据了；因此，客户端的加密也就形同虚设了。就好像是一扇门虽然是上了锁，可是钥匙就摆在那。

那如何解决这个问题呢？

很简单嘛，既然是因为钥匙在，才可以解锁的，那把钥匙藏起来就可以了。当然，回到HTTP中就不是把加密算法藏起来了。因为客户端是用加密算法对数据进行加密了的，它必须把加密算法告诉服务端，这样子服务端才可以正确获取数据。所以，我们需要做得就是在发送加密算法的时候，确保加密算法不可被中间代理服务器截获即可。只要加密算法不泄露，那数据就是安全的。

可能会有小伙伴在这里有疑惑：假如中间代理服务器对加密数据进行暴力破解呢？

其实这个是不必要担心的，没有加密算法的破解都是比较消耗时间的，在它破解出来的时候，客户端/服务端已经完成了数据请求了。

说到这里就不得不提出一个新的算法了——非对称加密算法。

前面提到的加密其实都是对称加密算法（一个算法可以完成加密、解密两套工作）；而非对称加密算法则不一样了，它拥有两种秘钥（公钥、私钥）。

公钥加密，只有私钥可以解开，公钥不可解开；私钥加密，公钥可以解开。

服务端用私钥生成公钥，将公钥通过网络传输给客户端。在传输的过程中，公钥被代理服务器截获，可是由于客户端发送的数据是经公钥加密的，只有私钥可以解开；而中间代理服务器所拥有的只有公钥，无法解开。

那到了这一步，有没有实现了真正的安全了呢？

其实，并没有!

没错，这时候，中间代理服务器确实没有办法解开客户端所发过来的数据，可是它解不开不代表着它不会伪造假数据啊。由于它截获了公钥，所以它完全有能力利用公钥伪造客户端的加密数据，以达到欺骗服务端的目的。

到时候服务端返回的数据可以被截获，因为服务端返回的数据是用私钥加密的，所以中间代理服务器可以用曾经截获的公钥解密，得到客户的隐私数据。

当然，因为中间代理服务器只有公钥，所以这种情况下，它是无法将数据返回给客户端的。（假如它用公钥加密后发给客户端，可是客户端也只是只有公钥，无法解开）。

可是，假如中间代理服务器用它自己的私钥伪造了假公钥呢？情况如下图：

在这种情况下，由于客户端里得到的是中间代理服务器本身的公钥（并非服务端的公钥），所以代理服务器可以用它自己的私钥伪装数据发给客户端，客户端可以正常接收解开；整个过程客户端毫无感知。

上面这种情况的最大问题就是客户端无法判断公钥的真假，也正因为这个可以引进数字签名（Hash算法）。服务端利用Hash算法给公钥进行签名（只要公钥相同，结果都相同），这时候，服务端会将公钥和签名一起发给客户端。

那这样安全了吗？

很显然并没有，无论是发公钥还是发签名，都会被截获到；中间代理服务器连公钥都能伪造了，伪造一份签名这还不是轻而易举的事？

既然这样不行，那样也不行，那能不能不传了呢？可不可以客户端本身就有呢？

你别说，还真可以！

这就说到了由CA机构下发的证书了。

服务端将自己的公钥交给CA私钥加密，从而生成对用的证书，客户端操作系统内置有CA的证书。证书也是通过网络传输，中间代理服务器可以截获，因为CA的证书是公开的，所以中间代理服务器可以解开证书得到服务端的公钥；但是由于它并没有CA私钥，故它不可以伪造证书（其他方式伪造的证书，客户端操作系统不会承认的）。就这样子，证书，要不不达到客户端，此时客户端可以重发请求；但凡到达客户端的证书都是CA的真证书。通过证书，客户端可以解密得到服务端公钥，从而解决了上述问题。