趣谈网络协议笔记-二（第十五讲）我与刘超有不同看法

趣谈网络协议笔记-二（第十五讲）

HTTPS协议：点外卖的过程原来这么复杂

---

前言

好饿啊= =，最近感觉自己真的是胖的不行了，所以开始了适当的节食操作。

我似乎很不擅长隐藏自己的想法。我似乎很不习惯于带上假面。所以我，时常会露出野兽般狰狞的面孔，用以告诫自己：我已经无法再成为温室中的花朵。

---

自勉

• 如果你明日将化为蛇 ，开始噬人 ，用你噬人之口 ，声声嘶吼着说爱我 ，我是否还能同今日一样 ，对你说出“爱你”这句话呢。——市丸银《死神》

• 我有可能是你所见过的最疯狂的疯子。——Ciruy B.Heimerdinger

• 失去人性，失去很多；失去兽性，失去一切。——维德《三体》

---

正文

从这篇开始，我将仅仅从刘超给出的图片来进行文章所有内容的回顾。以此来检验我自己是否将一切都已经化为自己的血肉。

的确，通过HTTP协议已经足够让双方能够稳妥地进行沟通了，双方不仅仅是互相传输数据（TCP），还能在一定的程度上分析获取的数据了。

但是这样还远远不够，因为在互联网上，如果仅仅通过HTTP协议，双方就相当于在裸聊，聊的是什么的，一路上的街坊都看的清清楚楚，就看他们愿不愿意看了。如果仅仅是新闻啊，天气预报啊，这些信息，当然无所谓，你看到了就看到了，反正对于发送和接收方来说也无关痛痒。但是如果是更加隐秘，或者说涉及隐私，甚至是安全的沟通信息，就绝对是不能任其裸奔的。

这样一来就需要加密了，但是怎么加密呢？就好比，我给数据上锁了，你拿到的时候总需要一把钥匙来解锁吧，不然我上锁不就完全没有任何意义吗？

此时，就存在两种加密方式，对称加密和非对称加密。此两者各有优劣，不然其一早就被淘汰了。

扫描二维码关注公众号，回复： 11597042 查看本文章

所谓对称加密，就是用使用一把钥匙可以同时可以达到加密和解密的作用，简单易懂，效率还高。但是问题是这钥匙，也即是所谓的秘钥钥匙在传递的过程中让别人拿到了，那么就又回到了裸聊的状态。

所谓的非对称加密，就是加密和解密是通过不同的钥匙来进行的，即所谓的公钥和私钥。公钥和私钥可以互相解密对方加密的数据，但是不能解密自己加密的数据。因此将公钥发送给对方，让对方用这个要是进行数据加密然后自己受到数据时使用私钥进行解密。这样一来就算传输过程中有人拿到了公钥，也解码不了数据。

两者皆有优劣，所以HTTPS协议在两者之间进行了一定的权衡，即通过非对称加密传输对称秘钥，然后后续的通话通过对称秘钥进行加密沟通。

但是问题又来了，你怎么知道你拿到的公钥的确是对方的公钥？

可能上述的表达不太足以说明问题，那么我就举一个更加极端的例子。假设，你是在一个局域网中，你和外网的连接只能通过一个网关，那么，请问，如果这个网关被人控制了，他会对你发送的信息和接收的信息进行篡改，你该怎么办？这就是HTTP协议的目的，尽可能地确保传输数据的安全性。

然后重点讲讲HTTPS协议是如何达成这个目的的，场景依然还是前面所说的极端例子，你的一切传输数据都被监听着的情况下，如果确保你的数据传输的安全性。

OK，终于来到我们的主题了，HTTPS为什么搞这么复杂，来来回回的目的是什么。

首先，解决之前提出来的问题，我如何验证公钥是正确的，所以就有了证书CA证书。证书是权威机构担保的公钥形式，其中不仅仅包括了公钥，要包括了担保方的签名，被担保方的信息以及证书的有效期等等。签名是通过签名算法对证书的一种不可逆操作，签名后再用担保方的私钥进行加密后才会放入证书中。用户可以通过担保方的公钥对签名进行解密，然后和被担保方的公钥签名结果进行比较，从而确保证书的正确性。但是如果证书中的权威机构也被伪造了呢？这你放心，你可以通过一层层的获取证书验证的方式一直验证到全球最高的几位证书机构，你不用担心这几位公钥的安全性，因为操作系统往往会自带这几位的公钥。所以…我默默地看了看我以前下的那么多的盗版windows镜像，以后我还敢用吗= =!

OK，这样一来就保证了我拥有绝对的公钥验证手段了。

接下来就是好好分析这错综复杂的来来回回吧。HTTPS协议的构建连接过程其实和HTTP差别不大，仅仅是HTTP的加强版，加强了什么呢？加强了安全性。

首先客户端会发送一个随机数字，以及客户端支持的加密算法，摘要算法，压缩算法列表发送给服务器端。

服务器收到后首先会发送另外一个随机数连同前面的随机数返回给客户端，此时客户端会进行一定的验证，我发出去的和他确认的是否相同，如果相同则等待服务器传输证书过来。（注意，这里服务器会传客户端的随机数是我和刘超第一个认知不同的地方，刘超认为服务器只会传他自己的随机数回来，但是你想想要是我发送的随机数被人改掉了怎么办呢，如果被人改掉，我还继续走后续流程？）发送完证书，服务器会发送传输完毕的回复给客户端。

OK，客户端这边感觉必要的信息都得到了，客户端就开始验证服务器传输过来的证书的可靠性。验证通过了，先发送客户端的证书给服务器端让服务器端验证，然后生成一个新的随机数，和前两个随机数通过公钥加密后发送给服务器，用以表示，今后，我们就通过这三个数字生成的对称秘钥来沟通交流吧。服务器通过私钥解密后收到了这三个数字，先验证下前两个数字是否和之前一样，一样的话就说明传输没有问题，然后也通过这三个数字来生成对称秘钥，生成方法之前协商过了，即选用客户端发送的加密方式时。（这里是我和刘超的第二个分歧点，刘超认为不会再传前两个随机数了）。

至此，连接已经建立，后续客户端通过对称秘钥对数据进行加密，服务器端通过同一个秘钥进行解密，从而建立沟通。就算中间传输过程中有人心怀不轨，他也只有两个随机数，第三个通过公钥加密过的，他没有私钥也解密不了，从而对称秘钥他也拿不到，数据传输也就安全了。

其实还有一个问题，其实黑客缺乏的也仅仅是第三个随机数而已，那要是他逐个试过来，不就有可能试出来吗？这里往往就需要Timestamp和Nonce随机数联合起来进行验证，我只接受一次这两者的组合，后续收到相同的组合就直接废弃。

那要是我的目的就是通过这种方式（不断发送相同的时间戳和Nonce随机数组合）来直接屏蔽一方的请求，这也可以成为一种黑客的目的不是吗？这个时候就需要在传输的时候再加入对时间戳和Nonce随机数的不可逆签名就可以保证此两者的正确性。

---

OK，感觉这章感觉是我最得意的一章，为自己鼓掌！