揭开HTTPS的神秘面纱

在说HTTP前，一定要先介绍一下HTTP，这家伙应该不用过多说明了，大家每天都在用，每一次HTTP请求，都是一次TCP连接。遗憾的是，请求的内容在TCP报文中是明文传输的，任何人截取到请求都可以读取其中的内容，很尴尬。

数据加密

为了防止请求内容被人窃取，在网络传输的路上我们做不了手脚，那就只能对传输的数据报文上做手脚了。对报文内容进行加密就是其中的一种方法。

有一种加密算法叫做对称加密算法，即加密和解密使用同一个秘钥，使用这种算法对请求数据进行加密，中间人因为没有秘钥，无法读取其中的内容。但是，使用这种算法进行加密，肯定要同意秘钥，那秘钥在网络中传输同样存在被窃取的风险啊。

这时，出现了新的加密算法：非对称加密算法，它有两把钥匙，一把叫私钥，是只有自己知道的，另一个叫公钥，可以发到互联网上，随便谁都可以看到，也就是说，传输过程中即使被别人看到也无所谓。这时，A向B发消息时，可以先用B的公钥对数据进行加密，B收到消息后再使用自己的私钥进行解密，中间即使被窃取了，因为没有对应的秘钥，也无法对了数据进行解密。

但是，非对称加密算法要比对称加密算法慢上许多。一个折中的办法，先使用非对称加密算法来传输对称加密的秘钥，以确保秘钥安全送达，之后就可以使用对称加密算法来加密数据报文了。

中间人劫持

你以为现在可以高枕无忧了吗？你以为你可以放心安全的进行通信了吗？天真。

假设，你现在正在和A通信，来自灵魂的拷问：你怎么能确定和你通信的人是A呢？

我们假设，通信正常进行。在通信开始传输公钥的时候，请求被中间人C劫持了。C讲A的公钥换成自己的公钥发给了你，在你发送请求后，再讲你的信息解密，使用A的公钥进行加密，发送给A。这样，在你和A看来好像是在和彼此通信，其实所有的信息都经过了C，所有的信息都被C一览无余。

那么如何保证收到的公钥是A的呢？完犊子了，又回到开始的问题了，如何保证秘钥在网络中安全的传输。但这次，加密似乎救不了我们了，我们必须要确保收到的秘钥确实是A发来的，也就是说报文没有别中途篡改过。

数字证书

其实无法保证报文内容的关键，在于我们对于收到的公钥无法确定有没有被人修改过，那如果有一个我们信任的中间人S来传输这个公钥就可以了。问题来了，D的公钥传输中同样存在被修改的问题，拿到再找其他人来传输S的公钥么？这要下去简直没完没了，完全就是三次握手的翻版。

问题的根源是什么？我们没有一个可以信任的公钥，那么解决办法也很粗暴，我们在本地保存一个绝对信任的公钥，它不是通过互联网来获取的，而是预装在系统中的，也就是系统/浏览器预置的顶层CA证书。

这些预装信任的内容，就是CA证书。通过CA获取A的公钥时，获得的数字证书大概长这样：

当收到证书后，我们对信息通过同样的hash算法计算出信息摘要，在用CA的公钥对数字签名进行解密，若解密后的信息摘要与我们计算的摘要相同，则可以认为信息没有被人修改过。验证流程如下：

难道这样就不怕别人篡改了么？不怕。因为我们已经拿到CA的公钥了，这是没有问题的。中间人因为没有CA的私钥，及时截取到信息，也无法对修改后的内容进行加密并生成对应的数字签名。

这样一来，信息的传输问题算是暂时告一段落了。（不知道什么时候就冒出了新的安全问题，毕竟道高一尺魔高一丈）

HTTPS

到这里，HTTPS介绍完毕，以上大概就是HTTPS的全部内容了。HTTPS的一次请求，大概流程如下：

1. 浏览器发出HTTPS请求
2. 服务器讲自己的数字证书返回
3. 浏览器用预置的CA来验证证书，若没有问题，顺利拿到公钥
4. 浏览器生成对称加密算法的秘钥，通过服务器的公钥进行加密，将报文发送给服务器
5. 服务器用自己的私钥进行解密，得到对称加密的秘钥
6. 可以开始用获得的对称加密秘钥进行通信了