谈恋爱也要懂 https

写了篇关于 https 的文章，老哥们有空可以帮忙看下文章中有没有什么错误。 可能有点标题党吧(ω`)o

高中往往是青少年最渴望恋爱的时期，即使在高考的重压之下，情窦初开的同学们，用着自己的方式传达着自己对异性（或同性）的好感。由于手机等通讯工具在学校中是被列为第一大禁品，那时的小情侣们往往通过传纸条、交换日记的方式在罅隙间私语。相较于冰冷的屏幕，这些存在于纸上残留着温度的油墨文字，反而更让人感受身心的熨帖。

在这种原始的通信方式中，所有的信息都是明文公开的，这非常的不安全，对于热恋中的情侣来说，窃窃私语，是属于两人独家的记忆，而这是万万不可让第三者监听或偷窥了去的。

在最初，字节高中里情侣传纸条使用的是一种名为 http1.0 的协议，这还是 1996 年的学长们制定的一种规范。

这套规则虽然满足了校园中情侣们日常的纸条传递需求，但是有着非常明显的缺点。因为 http 是无状态的，传递每张纸条都要重新建立起 tcp 连接，这十分消耗时间，也考验着同学们的耐心，一个课间十分钟，往往还没传几张纸条就上课了，非常低效。

半年后，在 1997 年，学长们终于忍受不了这种折磨了，于是对 http1.0 进行完善。

首先 http1.1 设计了一种长连接（ persistent connection ），在一次通信中，可以保持 tcp 连接不断开，这样就为多次传递纸条提供了一个稳定的通道。此外，在这个 tcp 通道里，学长可以向学姐发出多张纸条，而不用像以前那样只能发一张收一张了。更加激动人心的是，以前只能在纸条上写文字，现在可以附上照片、视频等内容，这简直是情侣们的一大福音。

就这样过去了十多年，同学们一直将就着使用这种通信方式。而到了 2015 年，字节高中里一位学长决定要创新与推动协议的发展，为了让同学们能够更愉快和高效地传纸条，他发布了 http2。

在这个新版本中，他实现了“多工”的方式，即双方可以同时实时地向对方发送纸条，不需要像以前那样一一对应了。比如学姐现在收到了两张纸条，一张是“你中午吃了什么？”，第二张是“周末准备去哪玩？”她想详细地规划一下周末去哪玩（耗时任务），但又不想让对方久等，于是她现在可以先简短回复第二张纸条“周末我想去电影院，然后和你一起刷公众号「字节流」”。然后完全回复第一张纸条“中午吃的食堂，难吃死了。”接下来她可以慢慢构思周末想看哪部电影，看完电影再去哪个书店，然后再发送对第二张纸条的完整回复。同时，http2 将所有的信息格式都定义为二进制，为了将来能直接发送更高级的应用而方便解码。

字节中学原本是所正德厚学的高中，但是近年来学校里的不良少年竟渐渐多了起来。他们有时偷窃纸条，将其篡改再发送，引起情侣间的矛盾；有时监听情侣间的对话，然后将其报告给教导主任或匿名张贴在校门口，还有的，利用纸条上有价值的信息大发横财，赚的盆满钵满。一时间，校园内风声鹤唳，草木皆兵。同学们都不再敢使用 http 来传纸条了。

由于 http 是明文传输，这确实很容易让不良少年（中间人）截获，那么，怎么才能有效地对信息进行加密呢？

一般来说，加密有两种方式，对称加密与非对称加密。首先简单介绍下这两种加密方式：

1. 对称加密： 也称为单密钥加密，即加密解密是使用同一把密钥。速度较快，使用的 CPU 资源少。
2. 非对称加密： 使用一对密钥：公钥和私钥。私钥与公钥是一对多的关系，公钥用于签名，私钥用于验证。私钥需要私自保管在本地，不能泄露，公钥可以随意在网上传输发放。

小黄和小棕是校园中一对令人艳羡的情侣，现在他们准备亲身开创并尝试一种新的传纸条方式，以此来造福大家，也为了打击学校里的不良少年。

首先，他们是这么设想的：

看上去是可行的，但其实 too young，不良少年只要截获 KEY，发送伪造的 KEY，那么之后的所有消息都将被监听。

问题的核心在于，直接传输密钥是不安全的，需要对密钥进行加密。我们的目的是：即使中间人截获了密钥，也无法对密钥解密。

那么，如何对密钥进行加密？

如果使用对称加密来加密密钥，那么密钥的密钥在传输过程中仍然是不安全的，需要再对密钥的密钥加密。这将无限叠加，最终仍是不安全的，而且显然不合理。

如果使用非对称加密，首先服务器生成一对公钥和私钥，将公钥发送出去；对方收到公钥后，本地使用对称加密生成一个密钥 KEY，然后使用公钥加密这个密钥 KEY，发送；服务器收到公钥加密的数据后，使用私钥解密，得到 KEY。这时，双方可以使用 KEY 来加密数据，开始安全地交流。 （即使中间人截获了公钥加密的数据，但是由于没有私钥（私钥只有签发公钥的服务器保管，不会用于传输）所以无法解密出 KEY。）

设想图如下：

看上去是可行的，但其实还是 too simple。假如小棕（服务器）在传输公钥给小黄（客户端）时，公钥被截获，小黑（中间人）自己生成一对公钥私钥，并将伪造的公钥传到小黄，这样一来，又被完全监听了。

此时，产生了这种情况：客户端使用的是 KEY1，服务器使用的是中间人伪造的 KEY2，而中间人拥有 KEY1，KEY2。所以中间人可以无限篡改数据。

小黄和小棕又陷入了沉思，虽然新的方案解决了密钥被截获的问题，但是产生了新的难点，现在的问题域缩小为：如何加密并安全传输公钥？

如果只是给公钥再对称加密或非对称加密的话，必定还是会衍生出鸡生蛋，蛋生鸡的问题。

这该怎么办呢？此时，需要一个权威机构来主持大局。于是同学们决定推选德高望重的学生会主席小季(CA)来担此重任。

小季是这样来操作的：首先，每个同学在入学的时候，都会收到由学生会颁发的公钥 A，而这个公钥 A 是绝对可信任的。以后，哪个同学谈恋爱了，需要串小纸条了，就到学生会小季处申请证书，证书将用于对你的公钥 B 进行加密，然后你将你的公钥 B 加密后传输给你的对象，因为他 /她在开学之初已经收到了 CA 的颁发的公钥 A，只要用这个公钥 A 来解密数据，若能解开，便能取出你的公钥 B。

流程如下：

此时还有一个问题，因为不良少年也是学校里的学生，图一中可以看到，小季给不良少年也颁发了 CA 公钥，不良少年也是可以去向小季申请证书的。若不良少年截获服务器发送的证书，改成自己的，那岂不是又出现了不安全的问题？如下图：

可以发现有可能出现两个问题：

1. 证书被中间人截获，使用 CA 公钥篡改
2. 中间人将自己的证书伪造成源服务器发送的

但这两个问题其实不会出现，小季早就考虑过这个问题，在证书的设计之初就解决了。其中引入了“数字签名”的概念。

数字签名可以解决可能出现的问题 1。对于可能出现的问题 2，由于证书 B 也是 CA 机构签发，所以数字签名可以通过验证，但是证书中包含了 host 信息，假如客户端正在访问的 host 和证书中的 host 不一样，浏览器会发出警告。就像这样：

到此为止，我们已经完全解决了中间人的问题，不良少年再也无法利用信息传输中的空子了。

而 https （ http over Secure Socket Layer ）即在 SSL 之上的 http，正是使用了这种方式来保证传输的安全。

小黑不甘心，想要找到新的解决方法，小季告诉他，编程世界中或许有你想要的答案，可以关注一下「 xxx 」(避嫌，已打码)这个公众号，里面的同学个个都是人才，说话又好听。

于是小黑和他的中间人朋友们开始潜心学习，字节高中又恢复了往日正德厚学的氛围。