当前位置 博文首页 > 小林coding：吴某凢 300 万诈骗案的瓜，程序员应该怎么吃？
大家好，我是小林。
上周吴某凢和都某竹的瓜大家都吃了吧，结果前几天北京朝阳警方通报了这是一个金钱诈骗案。
我读了那份通报，我直接炸开了，没想到这次的瓜里，还有第三个人，它就是中间人刘某，具体怎么诈骗的呢？
整个诈骗过程可以概括成如下图，下图中的 ID_A 表示都某竹的银行卡，ID_E 表示中间人刘某的银行卡。
这个诈骗案牛逼在于，中间人刘某有双重身份，不仅冒充都某竹的身份来向吴某凢索取赔偿，而且又冒充吴某凢的身份骗都某竹把退款的钱转到中间人刘某的银行卡，从而获取利益。
这波操作说实话比电影还精彩，刘某把中间人的角色演技到了极致，它做到了三件事情：
不知道大家有没有察觉中间人刘某做的这三件事情，正是 HTTP 协议的安全风险？
HTTP 协议不仅传输的信息是明文，而且没有身份认证，所以存在窃听风险、篡改风险、冒充风险。
为了解决 HTTP 协议的安全性，后面就出现了 HTTPS 协议，在 HTTP 层与 TCP 层之间加入了 TLS 协议，来保证安全可靠的信息传输。
具体怎么做到安全可靠的信息传输，这就涉及到了数字签名和数字证书。
没想到吧，画风突转的很快吧。
没错，今天这不是吃瓜文，而是技术文，让大家在吃瓜中学习，小林真是煞费苦心。
先说个事。我在 csdn 写了很多图解网络的文章，质量非常高，帮助到了很多同学，每次面试他们被问到网络，一点都不慌，不少同学去了字节、腾讯、阿里等一线大厂。
然后问把我的 15 万字的图解系列文章整理成了 PDF ，主要是为了方便阅读，现在开源给大家：15万字的图解网络开放下载（点击瞧一瞧）
为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，然后同内容一起传输给对方。
对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。
那么，在计算机里会用哈希函数来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。
通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。
举个例子，你想向老师请假，一般来说是要求由家长写一份请假理由并签名，老师才能允许你请假。
但是你有模仿你爸爸字迹的能力，你用你爸爸的字迹写了一份请假理由然后签上你爸爸的名字，老师一看到这个请假条，查看字迹和签名，就误以为是你爸爸写的，就会允许你请假。
那作为老师，要如何避免这种情况发生呢？现实生活中的，可以通过电话或视频来确认是否是由父母发出的请假，但是计算机里可没有这种操作。
那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：
这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。
流程的不同，意味着目的也不相同：
一般我们不会用非对称加密来加密实际的传输内容，因为非对称加密的计算比较耗费性能的。
所以非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。
私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。
引入了数字签名算法后，你就无法模仿你爸爸的字迹来请假了，你爸爸手上持有着私钥，你老师持有着公钥。
这样只有用你爸爸手上的私钥才对请假条进行「签名」，老师通过公钥看能不能解出这个「签名」，如果能解出并且确认内容的完整性，就能证明是由你爸爸发起的请假条，这样老师才允许你请假，否则老师就不认。
前面我们知道：
但是这还远远不够，还缺少身份验证的环节，万一公钥是被伪造的呢？
还是拿请假的例子，虽然你爸爸持有私钥，老师通过是否能用公钥解密来确认这个请假条是不是来源你父亲的。
但是我们还可以自己伪造出一对公私钥啊！
你找了个夜晚，偷偷把老师桌面上和你爸爸配对的公钥，换成了你的公钥，那么下次你在请假的时候，你继续模仿你爸爸的字迹写了个请假条，然后用你的私钥做个了「数字签名」。
但是老师并不知道自己的公钥被你替换过了，所以他还是按照往常一样用公钥解密，由于这个公钥和你的私钥是配对的，老师当然能用这个被替换的公钥解密出来，并且确认了内容的完整性，于是老师就会以为是你父亲写的请假条，又允许你请假了。
好家伙，为了一个请假，真的是斗智斗勇。
后面你的老师和父亲发现了你伪造公私钥的事情后，决定重新商量一个对策来应对你这个臭家伙。
正所谓魔高一丈，道高一尺。
既然伪造公私钥那么随意，所以你爸把他的公钥注册
到警察局，警察局用他们自己的私钥对你父亲的公钥做了个数字签名，然后把你爸爸的「个人信息 + 公钥 + 数字签名」打包成一个数字证书，也就是说这个数字证书包含你爸爸的公钥。
这样，你爸爸如果因为家里确实有事要向老师帮你请假的时候，不仅会用自己的私钥对内容进行签名，还会把数字证书给到老师。
老师拿到了数字证书后，首先会去警察局验证这个数字证书是否合法，因为数字证书里有警察局的数字签名，警察局要验证证书合法性的时候，用自己的公钥解密，如果能解密成功，就说明这个数字证书是在警察局注册过的，就认为该数字证书是合法的，然后就会把数字证书里头的公钥（你爸爸的）给到老师。
由于通过警察局验证了数字证书是合法的，那么就能证明这个公钥就是你父亲的，于是老师就可以安心的用这个公钥解密出清教条，如果能解密出，就证明是你爸爸写的请假条。
正是通过了一个权威的机构来证明你爸爸的身份，所以你的伪造公私钥这个小伎俩就没用了。
在计算机里，这个权威的机构就是 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。
数字证书的工作流程，我也画了一张图，方便大家理解：
接下来，详细说一下实际中数字证书签发和验证流程。
如下图图所示，为数字证书签发和验证流程：
CA 签发证书的过程，如上图左边部分：
客户端校验服务端的数字证书的过程，如上图右边部分：
但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：
对于这种三级层级关系的证书的验证过程如下：
在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书，于是客户端也信任 baidu.com 证书。
总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。
操作系统里一般都会内置一些根证书，比如我的 MAC 电脑里内置的根证书有这么多：
这样的一层层地验证就构成了一条信任链路，整个证书信任链验证流程如下图所示：
最后一个问题，为什么需要证书链这么麻烦的流程？Root CA 为什么不直接颁发证书，而是要搞那么多中间层级呢？
这是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。
本次分享没有谈到 HTTPS 握手过程，因为我之前写过很详细的 HTTPS 协议的 TLS 握手流程，想深入学习的同学，可以看看这两篇：
小林在 CSDN 写了很多图解网络和操作系统的系列文章，很高兴收获到很朋友的认可和支持，正好最近图解网络和操作系统的文章连载的有 20+ 篇了，也算有个体系了。
所以为了方便大家阅读，小林把自己原创的图解网络和图解操作系统整理成了 PDF，一整理后，没想到每个图解都输出了 15 万字 + 500 张图，质量也是杠杠的，有很多朋友特地私信我，看了我的图解拿到了大厂的offer。
图解系统 PDF 开源下载：图解系统 PDF 下载地址（点击）
图解网络 PDF 开源下载：图解网络 PDF 下载地址（点击）
最后，这瓜你觉得甜吗？
我们下次见啦。
cs