写了篇关于 https 的文章,老哥们有空可以帮忙看下文章中有没有什么错误。 可能有点标题党吧ヾ(•ω•`)o
高中往往是青少年最渴望恋爱的时期,即使在高考的重压之下,情窦初开的同学们,用着自己的方式传达着自己对异性(或同性)的好感。由于手机等通讯工具在学校中是被列为第一大禁品,那时的小情侣们往往通过传纸条、交换日记的方式在罅隙间私语。相较于冰冷的屏幕,这些存在于纸上残留着温度的油墨文字,反而更让人感受身心的熨帖。
在这种原始的通信方式中,所有的信息都是明文公开的,这非常的不安全,对于热恋中的情侣来说,窃窃私语,是属于两人独家的记忆,而这是万万不可让第三者监听或偷窥了去的。
在最初,字节高中里情侣传纸条使用的是一种名为 http1.0 的协议,这还是 1996 年的学长们制定的一种规范。
这套规则虽然满足了校园中情侣们日常的纸条传递需求,但是有着非常明显的缺点。因为 http 是无状态的,传递每张纸条都要重新建立起 tcp 连接,这十分消耗时间,也考验着同学们的耐心,一个课间十分钟,往往还没传几张纸条就上课了,非常低效。
半年后,在 1997 年,学长们终于忍受不了这种折磨了,于是对 http1.0 进行完善。
首先 http1.1 设计了一种长连接( persistent connection ),在一次通信中,可以保持 tcp 连接不断开,这样就为多次传递纸条提供了一个稳定的通道。此外,在这个 tcp 通道里,学长可以向学姐发出多张纸条,而不用像以前那样只能发一张收一张了。更加激动人心的是,以前只能在纸条上写文字,现在可以附上照片、视频等内容,这简直是情侣们的一大福音。
就这样过去了十多年,同学们一直将就着使用这种通信方式。而到了 2015 年,字节高中里一位学长决定要创新与推动协议的发展,为了让同学们能够更愉快和高效地传纸条,他发布了 http2。
在这个新版本中,他实现了“多工”的方式,即双方可以同时实时地向对方发送纸条,不需要像以前那样一一对应了。比如学姐现在收到了两张纸条,一张是“你中午吃了什么?”,第二张是“周末准备去哪玩?”她想详细地规划一下周末去哪玩(耗时任务),但又不想让对方久等,于是她现在可以先简短回复第二张纸条——“周末我想去电影院,然后和你一起刷公众号「字节流」”。然后完全回复第一张纸条——“中午吃的食堂,难吃死了。”接下来她可以慢慢构思周末想看哪部电影,看完电影再去哪个书店,然后再发送对第二张纸条的完整回复。同时,http2 将所有的信息格式都定义为二进制,为了将来能直接发送更高级的应用而方便解码。
字节中学原本是所正德厚学的高中,但是近年来学校里的不良少年竟渐渐多了起来。他们有时偷窃纸条,将其篡改再发送,引起情侣间的矛盾;有时监听情侣间的对话,然后将其报告给教导主任或匿名张贴在校门口,还有的,利用纸条上有价值的信息大发横财,赚的盆满钵满。一时间,校园内风声鹤唳,草木皆兵。同学们都不再敢使用 http 来传纸条了。
由于 http 是明文传输,这确实很容易让不良少年(中间人)截获,那么,怎么才能有效地对信息进行加密呢?
一般来说,加密有两种方式,对称加密与非对称加密。首先简单介绍下这两种加密方式:
小黄和小棕是校园中一对令人艳羡的情侣,现在他们准备亲身开创并尝试一种新的传纸条方式,以此来造福大家,也为了打击学校里的不良少年。
首先,他们是这么设想的:
看上去是可行的,但其实 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。对于可能出现的问题 2,由于证书 B 也是 CA 机构签发,所以数字签名可以通过验证,但是证书中包含了 host 信息,假如客户端正在访问的 host 和证书中的 host 不一样,浏览器会发出警告。就像这样:
到此为止,我们已经完全解决了中间人的问题,不良少年再也无法利用信息传输中的空子了。
而 https ( http over Secure Socket Layer )即在 SSL 之上的 http,正是使用了这种方式来保证传输的安全。
小黑不甘心,想要找到新的解决方法,小季告诉他,编程世界中或许有你想要的答案,可以关注一下「 xxx 」(避嫌,已打码)这个公众号,里面的同学个个都是人才,说话又好听。
于是小黑和他的中间人朋友们开始潜心学习,字节高中又恢复了往日正德厚学的氛围。
1
flyzero 2018-11-11 11:34:47 +08:00 via Android
点赞
|
2
wdlth 2018-11-11 11:40:27 +08:00 2
如果岳父母做了交叉签名呢……
|
3
RqPS6rhmP3Nyn3Tm 2018-11-11 11:50:44 +08:00 via iPhone
所以中间人攻击……
|
4
STRRL 2018-11-11 12:10:02 +08:00 via Android 1
把 Alice 和 Bob 换成了小黄和小棕。。。
|
5
laike9m 2018-11-11 12:14:07 +08:00 via Android
“ HTTP2 将所有的信息各式都定义为二进制”是啥意思,你是指消息类型吗?反正这句话很让人费解。
|
6
snal123 2018-11-11 12:50:16 +08:00 via iPhone
点赞
|
7
youngster 2018-11-11 12:59:03 +08:00
涨知识了
|