HTTPS的加密进化历史

其实HTTPS并不是一新鲜协议，谷歌很早就开始启用，初衷是为了保证数据的安全。近年来，谷歌、百度、Facebook等互联网巨头，开始大力推广HTTPS，现在全世界很多大型互联网公司已经启用了全站HTTPS，显然已经成为了互联发展得一种趋势。今天就给大家介绍一下HTTPS出现前，通信加密都都经历了些什么？为什么现在建议使用HTTPS？

可以想象成客户端与服务是两个从未见过面的陌生人的交流，而HTTPS是如保证他们交流的内容不被窃听的了？

1、 对称加密

假如客户端要与服务器进行一次私密对话。在每次数据传输之前服务器会先传输给客户端一把密钥，用来解密信息。然后客户端发送消息给服务器时也会先发一个密钥。这种方法被叫做对称加密。

但是这种方法有一个弊端，这就相当于将钥匙和锁放在一起，密钥被黑客截获那就和明文没啥区别了。

2、 非对称加密

为了防止这种尴尬的局面出现于是想到了用非对称加密的方法。也就是服务器与客户端都拥有两把钥匙，一把是公钥（是对外公开的），而另一把是私钥（只有自己知道）。并且，公钥加密的数据，只有对应的私钥才能解密；私钥加密的数据只能对应的公钥才能解密。

在数据传输过程中，服务器在向客户端传输数数据的过程中，会先用客户端给她的公钥（可以想象为一把锁）进行加密。

当客户端收到消息后在用会用自己的私钥（刚才给服务器锁的钥匙）解密。反正也是一样的流程。

做个不是太严谨的比喻便大家理解，这相当于只把锁寄出了，钥匙留下。这样中途被拦截了，黑客没有钥匙也打不开。这样达到一个安全保密的得效果。

可是万万没想到是，黑客会截取双方的锁，黑客将自己的锁发给双方，这样服务器与客户端双都一以为用的是对方的锁，其实是黑客的锁。黑客用自己的钥匙看了到了所有的内容。

3、 数字证书

反思一下，是什么原因导致非对称加密这种方式的不安全性的？

与对称加密方法安全隐患不同。非对称加密之所以会不安全，是因为客户端无法确定收到的公钥是否是真正的服务器的。

那么想要解决这个问题就需要想一种办法来证明公钥的来源是服务器，而不是其他人冒充的。

在多种尝试后找到一种靠谱的方法——数字证书，找一个大家都信任和认可的认证中心（CA）。在服务器发给客户端公钥的过程中，会先把服务的个人信息通过Hash算法生成信息摘要。如图：

为了防止有人中途将摘要调包，服务器要需要将CA提供的私钥对消息摘要进行加密来形成数字签名。如图：

并且，最后需要把原来没有Hash算法之前的信息和数字签名合并在一起，形成数字证书。如图：

当客户端拿到这份数字证书后，就会用CA提供的公钥来对数字证书里的数字签名来进行解密得到消息的摘要，然后对数字证书里面的服务器和个人信息进行Hash得到另一份消息摘要，然后进行对比。如果一样，就证明这些东西确实是服务器发来的。如图：

这时有人会想知道，CA的公钥是怎么拿给到客户端的？服务器又是怎么有CA公钥的？

其实，部分服务器在一开始就向认证中心申请了这些证书，而客户端里，也会内置这些证书。如图：

当客户端收到服务器返回来的数据时，就会在内置的证书列表查看是否有解开该数字证书的公钥。

4、HTTPS

经过上面的铺垫现在可以介绍HTTPS的原理了。可以加将客户端换成浏览器，把服务器换为某个网。

一个简化的（例如下图没有包含Pre-Master Secret—预备主密码）https流程图是这样的， 如果你理解了前面的原理，这张图就变得非常简单：

这样一来，整个个数据传输就会安全很多。而HTTPS是在过去超文本传输协议HTTP协议技术上加入了SSL协议，SSL依靠数字证书来来验证服务器的身份。并为浏览器和服务器之间的通信加密。这也是谷歌等科技公司推广HTTPS重要原因之一。