我和小宇早恋了,上课的时候老说话。

老师把我们的座位分得很远,我在第一排,她在最后一排,我们中间隔了很多人。

但我们还是想通过传纸条的方式交流。

我们中间的那些同学,虽然坏心思比较多,但好在可以保证将纸条传递到位,于是我们用传纸条的方式,一直秘密交流着感情。

但好景不长,我们渐渐发现,中间这些同学特别不靠谱,出现了以下两种恶劣的行为:

偷看纸条,把我们的小甜蜜作为他们饭后的谈资。

篡改内容,让我们之间产生了好多误会。

这还了得,我必须得想个办法才行!

单钥匙锁

于是我发明了一个盒子,并且给这个盒子配了一把锁和一把钥匙。

这把锁与普通的锁不太一样,解锁需要钥匙,同时上锁也需要钥匙。

我把这个钥匙复制了一份,给到小宇,这样我每次给她写完小纸条之后,都把纸条放在盒子里,用钥匙把它锁起来。

小宇收到这个盒子后,用钥匙解锁,才能拿出里面的纸条。

同时如果小宇想给我回纸条时,也需要把纸条放在盒子里,并且用钥匙加锁,再传给我。

这样,由于中间的同学没有钥匙,就无法偷窥里面的内容了,也无法篡改里面的内容,问题完美解决。

但好景又不长,由于之前我把钥匙给小宇时,也是通过同学传递过去的,有个同学当时就偷偷又复制了一份,因此拿到了一个钥匙。

于是他每次收到我传给小宇的盒子的时候,就先用钥匙解锁,偷看内容,有的时候甚至还修改内容,放回盒子,然后再用钥匙锁起来。

这还了得,我必须得再想个办法才行!

双钥匙锁 - 防篡改

我绞尽脑汁,通宵达旦了好几天,终于发明出了一把特别神奇的锁。

与这个锁相对应的有两把不同的钥匙 A 和 B,神奇的地方就在于,用钥匙 A 加锁,必须用钥匙 B 才能解锁。反过来用钥匙 B 加锁,必须用钥匙 A 才能解锁。

我对我的这个发明非常满意!感觉可以申请专利了!

我给这个锁起了个名字叫双钥匙锁,那自然之前那个简单的锁,就叫单钥匙锁。

而双钥匙锁这种加解锁的方式,我给起了个名字,叫非对称加解锁,自然,那个单钥匙锁对应的方式,就叫对称加解锁咯。

有了这个发明,我只需要把钥匙 B 给小宇,我每次写纸条时先用钥匙 A 进行加密,然后盒子到了小宇那里,她只需要用钥匙 B 解密,即可看到我的内容了。

这个钥匙 B 被人复制了一份也没关系,坏人只能用钥匙 B 打开盒子偷看我的内容,但是他如果想篡改内容,必须用钥匙 A 才能把盒子锁住,而钥匙 A 一直在我手里,从来没有传递过,没人知道。

当然,坏人也可以用钥匙 B 把盒子锁住,但用 B 锁住的盒子,只能用 A 去解锁,所以如果小宇用自己手里的 B 解锁时,发现解不开,就知道内容被人篡改了。

现在,内容篡改的问题就完美解决了。

还有内容被偷看的问题还没解决,也就是内容泄漏。

双钥匙锁 - 防泄漏

我灵机一动,想到了办法。

我发现,小宇那边已经有了钥匙 B,如果小宇用 B 去加锁,只有钥匙 A 能解锁,而钥匙 A 只有我这里有,这样小宇用钥匙 B 加锁的纸条,就没有任何人能看到并且篡改了!

就着这个思路,因为我们完全是对称的关系,所以只要小宇那边再造一个类似的神奇的锁,然后分配两把钥匙 C 和 D。

然后小宇把钥匙 D 给我,自己保留钥匙 C,这样我只要用钥匙 D 加锁我的内容,就只有小宇能解开了!

这样,就保证了双向的通信安全!中间的坏同学们既无法阅读我们的内容,也无法篡改我们的内容,因为会被我们发现。

但好景又不长,我们发现,这个双钥匙锁由于设计的太过复杂,导致加锁解锁的效率实在是太低了,每次传一个纸条都要费好大劲加锁再解锁,极大降低了我们每天交流的次数,很不爽。

这还了得,我必须得想个办法才行!

单双钥匙锁相互配合

我记得当初用那个单钥匙锁的时候,效率就挺高的,只是因为传送钥匙的过程中容易被坏人偷看到,复制一份出来,就可以监听和篡改我们后续的通讯了。

那我们能不能用双钥匙锁的安全性,把单钥匙锁的钥匙安全地传送给对方,然后之后再用单钥匙锁,高效率地通信。这样,安全性和效率就都有了保证!

我赶紧想出了一个绝妙的方案!

1. 由小宇设计一个双钥匙锁,配两把钥匙 C 和 D,然后把钥匙 D 给我。

2. 我这边准备一个单钥匙锁,配一个钥匙 M,把它放在盒子里,用小宇给我的钥匙 D 加锁,传给小宇。

3. 传送过程中,由于钥匙 D 加锁的盒子只能用钥匙 C 解锁,所以中间人无法查看和篡改内容,最终钥匙 M 被安全传送到小宇那边。

4. 此时,我们双方都有了钥匙 M 和与之对应的单钥匙锁,而且这个钥匙 M 谁都不知道。

5. 在此之后,我们用钥匙 M 去加密我们的信息,对方用钥匙 M 解密我们的信息,达成了安全通信的条件。

简单说就是,小宇给了我把钥匙 D,我用 D 加锁我的 M,传给小宇,之后我们用钥匙 M 进行对称加解锁的方式进行通信。

当然,中间的坏蛋,可以在小宇给我钥匙 D 的时候,偷偷换成别的钥匙 E,但我用 E 加锁我的钥匙 M 之后,小宇是无法用钥匙 C 解锁的,也就知道中间有人动了手脚,那我们就停止我们的通信。

也就是说,中间人可以阻止我们的通信,但是却再也无法偷窥和阅读我们的通信内容了。

太绝了!我们居然在中间人完全不可靠的通信链路上,实现了安全的通信,这简直不可思议!

但好景又不长。

有个又坏又聪明的坏蛋,居然也研究出了这种双钥匙锁的技术!

这些坏蛋给自己也准备了一个双钥匙锁,并且配置了两把钥匙 X 和 Y。

此时他在我们原来的通信方式上,做了这么个事。

1. 由小宇设计一个双钥匙锁,配两把钥匙 C 和 D,然后把钥匙 D 给我。

2. 这个人没把钥匙 D 给我,而是把自己造的钥匙 Y 给了我,但我以为这是小宇给我的呢。

3. 我这边准备一个单钥匙锁,配一个钥匙 M,把它放在盒子里,用小宇给我的钥匙(其实是坏蛋给我的钥匙 Y)加锁,传给小宇。

4. 这个人收到加锁后的盒子,用自己的钥匙 X 轻松解了锁,因为这个锁是被 Y 锁的嘛~解锁后取出里面的钥匙 M,复制了一份,然后再用小宇的钥匙 D 加锁。

5. 小宇用 C 解开了锁,得到里面的钥匙 M,这个的确是我给的,但小宇不知道此时已经被坏人知道了,与此同时我也不知道这个事。

6. 于是我们用钥匙 M 加锁解锁通信,坏蛋也同样用钥匙 M 来偷窥或篡改我们的信息。

简单说,就是,我以为我是用小宇的钥匙加密,但却是坏蛋的。小宇以为是我用她的钥匙加密后传给她的 M,因为她解得开,但却是坏蛋伪装的。我们双方都不知情。

坏蛋也真是卷啊,这么精妙的设计也能想出来,只是为了偷窥我和小宇的小纸条,果然八卦是人类的第一生产力。

这肯定不行,我必须又得想个办法才行。

找班长做公证

我苦思冥想,找到了一个解决思路。

首先我们至少有一次,就是第一次传输的那把钥匙,是无法进行加密的,会被中间的所有人看到,这个是无法避免的,否则就一直套娃了。

但是我们能不能做到,可以让对方看到,但却无法篡改呢?

也就是说,坏蛋传给我假钥匙 Y,我可以知道这个是坏蛋的呢?

只靠我们两个,几乎不可能,于是我求助了班长。

我让班长也准备了一个双钥匙锁,然后配置了两把钥匙 J 和 K,然后把钥匙 K 公开让所所有人都知道。

小宇在第一次准备给我钥匙 D 时,不再直接给我了,而是找班长,把钥匙 D 放在一个盒子里,让班长用自己的钥匙 J 给加锁。

然后小宇把这个用钥匙 J 加好锁的盒子传给我,我用班长公开的钥匙 K 解锁盒子,就可以得到小宇的钥匙 D 了。

这样,中间的坏蛋可以用公开的钥匙 K 把盒子打开,看到小宇准备给我的钥匙 D。

但是,他们却无法把自己伪造的钥匙 M 传给我,因为要想加锁这个盒子,必须有钥匙 J 才行,而钥匙 J 只有班长知道。

也就是说,目前这个内容,中间的坏蛋们只能看,不能修改了!

如果不能修改,我就能成功用小宇给我的真正的钥匙 D 加锁我们之后要通讯用的钥匙 M,于是这个钥匙 M 就被安全地传给了小宇,我们之后就可以用这个谁也不知道的钥匙 M,和配套的单钥匙锁,愉快地聊天了!

可是如果班长同坏蛋勾结,把 J 泄漏或者卖给了坏蛋怎么办呢?那没辙,说明他不配当班长!

这么多钥匙傻傻分不清了

这个环节涉及到很多钥匙

我的单钥匙 M:用来之后我和小宇对称加锁方式通信用的,需要想办法安全传给小宇

小宇的双钥匙 CD:用来让我安全把 M 传给她,做法是把公开的钥匙 D 传给我,我用钥匙 D 加锁我的 M,这样只有她才能用自己的保密钥匙 C 解开,中间人无法得知。

坏蛋的双钥匙 XY:用来传给我伪造的钥匙 Y 让我误以为这是小宇传给我的钥匙 D。

班长的双钥匙 JK:用来加锁小宇的钥匙 D,防止中间的坏蛋篡改这个值。

这在安全领域,分别对应对称加密,非对称加密。

单钥匙就是对称加密,对称加密的速度很快,可以用于传输过程中的数据加密,防止中间人查看和篡改信息。但是如何将对称加密的秘钥安全传递过去,个问题。

双钥匙就是非对称加密,非对称加密的速度慢,可以用于加密少量数据,同时也可以用于签名防止篡改,为什么呢?看后面。

非对称加密的秘钥中,公开让别人知道的就是公钥,比如小宇的钥匙 D 或班长的钥匙 K 等。

留在自己这里不让别人知道的就是私钥,比如小宇的钥匙 C 或班长的钥匙 J 等。

既可以用私钥加密数据,公钥解密数据。也可以用公钥加密数据,私钥解密数据。

公钥加密,私钥解密,这个叫加密,是为了保证内容安全,因为私钥只有自己知道,是为了保证这个信息不被中间人解开。

私钥加密,公钥解密,这个叫签名,是为了防止内容被篡改,因为公钥所有人都知道,所有人都能看到这个信息做验证。

但是,如果想篡改,就必须得篡改原文信息后,用私钥加密,才能得到原来的效果,可惜私钥是不公开的。

还有一种不可逆的哈希函数,这个叫摘要,是无法解密的,这个之后再说。

在刚刚的环节中,首先小宇让班长用私钥 J 加密自己的公钥 D,传给我,这是私钥加密公钥解密,这个目的就是签名,防止公钥 D 在传输过程中被别人篡改。

我得到了公钥 D 之后,加密我的对称加密的秘钥 M,传给小宇,这是公钥加密私钥解密,这个目的是加密,为了让中间人不知道我的 M 是什么。

当然,我们之后的数据传输过程,也可以用这种非对称加密的方式玩,但可惜,非对称加密的复杂度非常高,性能非常低,因此仅仅适合这个传递秘钥 M 的过程,数据量很小,而且仅仅一次。

再之后的传输,就通过我们协商好的对称秘钥 M 进行传输,这个也是加密,与公钥加密私钥解密的目标是一致的,只不过适合的场景不同,对称加密的效率比非对称加密高出好几个数量级。

HTTPS

我和小宇传纸条这个过程,就是 HTTPS 的工作原理。

哦不对,这句话重说一遍,这个破玩意,就是 HTTPS。

我就是客户端,小宇就是服务端,班长就是 CA 机构,中间那些坏蛋同学就是传输链路,用以标明传输链路很不靠谱,有很多中间人想要搞破坏,或者偷窥我们的信息。

只不过,HTTPS 的细节更多些,但大体的思路和我们今天传纸条是一致的。

之后给大家出,通过抓包方式学习 HTTPS 的细节过程,包我已经抓好了。

今天大家只关注这个 HTTPS 的思想过程,后面带大家学习 TLS 协议细节,以及 CA 证书的组成即验证方式。

最新文章

  1. sass兼容IE8透明度方法
  2. Hibernate控制insert\update语句
  3. 不输入密码ssh直接登录阿里云Linux主机
  4. COJN 0558 800600带通配符的字符串匹配
  5. HDU 2112 HDU Today (Dijkstra算法)
  6. supervisor启动流程
  7. 关于js参数传递矛盾新理解
  8. 服务端渲染和nuxt简单介绍
  9. DC综合简单总结(1)
  10. Qt 滚动窗口类
  11. JAVA面对对象(三)——Super、static、final关键字
  12. node初学者笔记
  13. 句柄线程做参数和PostMessage的用法
  14. 2018.12.15 codeforces 920F. SUM and REPLACE(线段树)
  15. Union和Union All的区别[转]
  16. 使用位图文本工具BMFont从图片生成自定义字体
  17. WIN7 64位配置X86 MySQL 数据源
  18. LT1961 升压型稳压器造就了兼具升压和降压能力的扁平状SEPIC
  19. python3的下载与安装
  20. 【python】 requirements使用方法

热门文章

  1. 96、linux之rpm包定制
  2. CentOS-Docker安装MongoDB(单点)
  3. Java:代码高效优化
  4. shell中的特殊变量IFS
  5. 《PHP扩展学习系列》系列分享专栏
  6. 干掉 Postman?测试接口直接生成API文档,这个工具贼好用
  7. python 15篇 面向对象
  8. Java基础00-多态19
  9. Java基础00-方法10
  10. Day3 变量 运算符 及运算符的优先级