谈恋爱也要懂https

会员服务 ·

谈恋爱也要懂https

2018 年 11 月 16 日 程序人生

点击上方“程序人生”，选择“置顶公众号”

第一时间关注程序猿（媛）身边的故事

题图 | @麦伢

作者

寒食君i

如需转载，请联系原作者。

高中往往是青少年最渴望恋爱的时期，即使在高考的重压之下，情窦初开的同学们，用着自己的方式传达着自己对异性（或同性）的好感。

由于手机等通讯工具在学校中是被列为第一大禁品，那时的小情侣们往往通过传纸条、交换日记的方式在罅隙间私语。相较于冰冷的屏幕，这些存在于纸上残留着温度的油墨文字，反而更让人感受身心的熨帖。

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

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

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

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

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

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

在这个新版本中，他实现了“多工”的方式，即双方可以同时实时地向对方发送纸条，不需要像以前那样一一对应了。

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

可是好景不长。

字节中学原本是所正德厚学的高中，但是近年来学校里的不良少年竟渐渐多了起来。

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

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

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

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

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

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

点击显示大图

看上去是可行的，但其实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公钥，不良少年也是可以去向小季申请证书的。若不良少年截获服务器发送的证书，改成自己的，那岂不是又出现了不安全的问题？如下图：

点击显示大图

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

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

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

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

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

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

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

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

- The End -

「若你有原创文章想与大家分享，欢迎投稿。」

加编辑微信ID，备注#投稿#：

程序丨 druidlost

小七丨 duoshangshuang

点文末阅读全文，看『程序人生』其他精彩文章推荐。

推荐阅读：

print_r('点个赞吧')；
var_dump('点个赞吧')；
NSLog(@"点个赞吧！")
System.out.println("点个赞吧!");
console.log("点个赞吧!");
print("点个赞吧!");
printf("点个赞吧!\n");
cout << "点个赞吧!" << endl;
Console.WriteLine("点个赞吧!");
fmt.Println("点个赞吧!")
Response.Write("点个赞吧")；
alert（’点个赞吧’）