我们知道小程序的wx.request网络接口只支持HTTPS协议(文档-小程序网络说明),为什么HTTPS协议就比HTTP安全呢?一次安全可靠的通信应该包含什么东西呢,这篇文章我会尝试讲清楚这些细节。
Alice与Bob的通信
我们以Alice与Bob一次通信来贯穿全文,一开始他们都是用明文的形式在网络传输通信内容。
嗅探以及篡改
如果在他们的通信链路出现了一个Hacker,由于通信内容都是明文可见,所以Hacker可以嗅探看到这些内容,也可以篡改这些内容。
公众号的文章之前就遇到很多被挟持篡改了内容,插入广告。
加密解密
既然明文有问题,那就需要对明文进行加密处理,让中间人看不懂内容,于是乎要对原来的内容变成一段看不懂的内容,称为加密,反之则是解密。而本质其实就是一种数学运算的逆运算,类似加法减法,例如发送方可以将 abcd…xyz 每个字母+1映射成 bcd…yza,使得原文的字母变成看不懂的序列,而接收方只需要将每个字母-1就可以恢复成原来的序列,当然这种做法规律太容易被破解了,后边会有个案例示意图。
对称加密
如果对2个二进制数A和B进行异或运算得到结果C, 那C和B再异或一次就会回到A,所以异或也可以作为加密解密的运算。
把操作数A作为明文,操作数B作为密钥,结果C作为密文。可以看到加密解密运用同一个密钥B,把这种加解密都用同一个密钥的方式叫做对称加密。
可以看到简单的异或加密/解密操作,需要密钥跟明文位数相同。为了克服这个缺点,需要改进一下,把明文进行分组,每组长度跟密钥一致,分别做异或操作就可以得到密文分片,再合并到一起就得到密文了。
但是这种简单分组的模式也是很容易发现规律,可以从下图看到,中间采用对原图进行DES的ECB模式加密(就是上边提到简单分组的模式)
很明显,原图一些特征在加密后还是暴露无遗,因此需要再改进一把。一般的思路就是将上次分组运算的结果/中间结果参与到下次分组的运算中去,使得更随机混乱,更难破解。以下图片来自维基百科:
经过改良后,Alice与Bob如果能提前拿到一个对称加密的密钥,他们就可以通过加密明文来保证他们说话内容不会被Hacker看到了。
非对称加密
刚刚还引发另一个问题,这个对称加密用到的密钥怎么互相告知呢?如果在传输真正的数据之前,先把密钥传过去,那Hacker还是能嗅探到,那之后就了无秘密了。于是乎出现另外一种手段:
这就是非对称加密,任何人都可以通过拿到Bob公开的公钥对内容进行加密,然后只有Bob自己私有的钥匙才能解密还原出原来内容。
RSA就是这样一个算法,具体数学证明利用了大质数乘法难以分解、费马小定理等数学理论支撑它难以破解。相对于前边的对称加密来说,其需要做乘法模除等操作,性能效率比对称加密差很多。
由于非对称加密的性能低,因此我们用它来先协商对称加密的密钥即可,后续真正通信的内容还是用对称加密的手段,提高整体的性能。
认证
上边虽然解决了密钥配送的问题,但是中间人还是可以欺骗双方,只要在Alice像Bob要公钥的时候,Hacker把自己公钥给了Alice,而Alice是不知道这个事情的,以为一直都是Bob跟她在通信。
要怎么证明现在传过来的公钥就是Bob给的呢?在危险的网络环境下,还是没有解决这个问题。
一般我们现实生活是怎么证明Bob就是Bob呢?一般都是政府给我们每个人发一个身份证(假设身份证没法伪造),我只要看到Bob身份证,就证明Bob就是Bob。
网络也可以这么做,如果有个大家都信任的组织CA给每个人出证明,那Alice只要拿到这个证明,检查一下是不是CA制作的Bob证书就可以证明Bob是Bob。所以这个证书里边需要有两个重要的东西:Bob的公钥+CA做的数字签名。
前边说到用公钥进行加密,只有拥有私钥的人才能解密。数字证书有点反过来:用私钥进行加密,用公钥进行解密。CA用自己的私钥对Bob的信息(包含Bob公钥)进行加密,由于Alice无条件信任CA,所以已经提前知道CA的公钥,当她收到Bob证书的时候,只要用CA的公钥对Bob证书内容进行解密,发现能否成功解开(还需要校验完整性),此时说明Bob就是Bob,那之后用证书里边的Bob公钥来走之前的流程,就解决了中间人欺骗这个问题了。
这种方式也是一种防抵赖的方式,让对方把消息做一个数字签名,只要我收到消息,用对方的公钥成功解开校验这个签名,说明这个消息必然是对方发给我的,对方不可以抵赖这个行为,因为只有他才拥有做数字签名的私钥。
CA其实是有多级关系,顶层有个根CA,只要他信任B,B信任C,C信任D,那我们基本就可以认为D是可信的。
完整性
上边基本上已经解决了保密性和认证,还有一个完整性没有保障。虽然Hacker还是看不懂内容,但是Hacker可以随便篡改通信内容的几个bit位,此时Bob解密看到的可能是很乱的内容,但是他也不知道这个究竟是Alice真实发的内容,还是被别人偷偷改了的内容。
单向Hash函数可以把输入变成一个定长的输出串,其特点就是无法从这个输出还原回输入内容,并且不同的输入几乎不可能产生相同的输出,即便你要特意去找也非常难找到这样的输入(抗碰撞性),因此Alice只要将明文内容做一个Hash运算得到一个Hash值,并一起加密传递过去给Bob。Hacker即便篡改了内容,Bob解密之后发现拿到的内容以及对应计算出来的Hash值与传递过来的不一致,说明这个包的完整性被破坏了。
一次安全可靠的通信
总结一下,安全可靠的保障:
- 对称加密以及非对称加密来解决:保密性
- 数字签名:认证、不可抵赖
- 单向Hash算法:完整性
来一张完整的图:
有个问题让我百撕不得骑姐,那就是既然https比http这么多的优势,为什么不把http的协议内核直接升级到http,而是让我们自己下证书,自己做这些事情,甚至有些地方用http的还需要搜索出来重新改成https。
嗯,小白,新手,不喜勿喷0.0
与纯文本通信相比 加密通信会消耗更多的CPU及内存资源 直接升级就没得选了 每次通信都加密 流量大的网站所承担的负载不可小觑
可是流量越大,不是越应该加密么,现在大部分的网站为了安全都会去做https吧
Can i reprint it?
注明出处即可。
这个页面有问题吧,1366*768分辨率下必须缩放到80%才可以全部显示
分辨率的bug 我们已知,正在处理。
图太糊了
样式默认了图片最大宽度是400px,这里之后优化修复一下。
图片不能双击放大查看哇
我们下期优化加上。
请问你这个叫什么图?用什么软件做的?
balsamiq mockups
简单易懂,思路清晰。点个赞!
有一个问题不是很明白,用于对称加解密的密钥,通信双方是怎么通过非对称加密方式获取的?
我的理解是 Alice拿到Bob的公钥是CA的数字签名以后,验证了Bob的身份合法以后,通过Bob的公钥将 "对称加密要用到的密钥" 加密会传给Bob,然后Bob在通过自己的密钥解密得到 "对称加密要用到的密钥",然后双方在通过 "对称加密要用到的密钥" 加解密传输的内容。
这样的话"对称加密要用到的密钥"就是Alice方来提供的,但是不知道是不是这样的呢???
有点疑惑:
最后总结的图里面说先用非对称加密同步客户端和服务端的私钥,再通过这个私钥加密和解密接下来传输的内容
既然是已经可以通过非对称加密的方式“安全”传输数据了,为什么还要 再 用对称性加密的方式传输数据,是有特别用意吗?
写的很好,请教下,只有浏览器才能验证CA的有效性吗?Hacker如果知道CA的公钥,是否也可以用CA的公钥解密出Bob的的密文,从而得到Bob的公钥
有个问题不太了解,Bob的公钥传给Alice有什么作用?或者说Alice拿到Bob的公钥有什么作用,和采用非对称加密生成的用来对称加密的秘钥有啥区别?
写的不错~赞赞👍