揭开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. 能够开始用得到的对称加密秘钥进行通讯了