浅谈握手：通信协议变迁

浅谈握手：通信协议变迁

初始通信协议

刚开始通信协议是没有加密概念的，即全程发送明文，后面有人好奇别人发了什么东东就通过抓包等手段抓取数据，这种事情干多了，总会露馅，不愿意暴露自己隐私的人就想到了将自己的数据进行加密，但是加密的目的是让第三方不知道自己发的是什么，总得让接收方知道自己发的是什么吧，于是发送方和接收方就约定，在通信的前几个字节保存密钥，这样的话无论是对方还是自己，收到消息都能很方便的解密，而第三方不知道这个协议的话就很难知道发送的是什么。

非对称加密通信协议

初始通信协议没用多久，很快就有很多人知道了协议内容，那些抓包的人也与时共进，抓包之后用前面几个字节的密钥来解密，通信内容继续暴露，开始寻找新的加密方法，非对称加密登上舞台，这种利用数学难题形成的公钥私钥，不惧怕破解。但是为了对方能够解密，需要先把自己通信加密的公钥给对方，所以通信流程就变成了这样：

client: hello server//测试通信通道是通的
server: hello client//回复是通的
server: 公钥给你//发送server的公钥
client: 公钥给你//发送client的公钥

这个流程叫做握手，握手成功后就开始愉快的通信了。

非对称加密+对称加密通信

非对称加密的确保密性很好，但是，但是加解密花费的时间有点多，而且大部分通信是对保密性没有那么高的，咋办，采用非对称加密和对称加密相结合的方式，即用非对称加密来传递密钥，然后采用对称加密的密钥来加密通话，其握手过程就变成这样。

client: hello server//测试通信通道是通的
server: hello client//回复是通的
server: 公钥给你//发送server的公钥
client:biubiubiu...........//利用公钥将发送的私钥进行加密

握手结束，就开始快乐的通信。

非对称加密+对称加密+密钥计算

前面的加密效果的确还行，但是有些人它不走寻常路，他不管你的非对称加密，直接测试对称密钥，因为密钥是一串随机数，所以还是有点危险的。咋办，密钥计算上台，即客户端生成一个随机数，服务器生成一个随机数，客户端再生成一个随机数，双方交换随机数后，将这三个随机数计算出最后的密钥。握手流程就变成这样：

client: hello server + 随机数1//测试通信通道是通的
server: hello client + 随机数2//回复是通的
server: 公钥给你//发送server的公钥
client:biubiubiu...........//利用公钥将发送的随机数3进行加密
client计算密钥
server计算密钥

然后就快活的通信。。。。。

数字证书

道高一尺，魔高一丈，以为高枕无忧的时候，来了中间人攻击，就是我们的握手过程中第三方站了进去，坐在中间，面向client的时候假装自己是server面向server的时候假装自己是client，前面的握手过程变成了这样。

client: hello server + 随机数1//测试通信通道是通的，其实在半路被bad拦截了下来。
bad: hello server + 随机数1//保存随机数后，又将随机数发给了server
server: hello client + 随机数2//回复是通的，这个更无语，直接回复给bad了。
bad: hello client + 随机数2//保存随机数后，又将随机数发给了client
server: 公钥给你//发送server的公钥，给了bad
bad: 公钥给你//保存公钥后，又自己创建一个密钥，将自己的公钥发给了client
client:biubiubiu...........//利用bad的公钥将发送的随机数3进行加密,还是bad接收
client:biubiubiu...........//bad利用自己的私钥解开密文，然后用server的公钥将明文加密，继续转发给server。
client计算密钥
server计算密钥
bad计算密钥

好家伙，通信又被暴露了，怎么防止中间人攻击，数字证书登上舞台。数字证书是怎么来的？第一步，server将自己的一些信息和公钥发给一个大家都信赖的人CA,CA也有自己公私钥，他从server发过来的所有信息提取出hash值，然后用私钥将其加密(你也可以说是签名，因为私钥加密，所有公钥都能解密，那么他就不能保证信息的保密性，只能保证信息的完整性)，CA将那些信息+公钥+加密后的hash值整合成一个文件就变成了数字证书。这个数字证书怎么用呢？很简单，因为CA的证书大家伙都有，那么当一个人发证书过来的时候如何证明这个人是服务器，将数字证书里面的信息+公钥再提取一次hash值，然后用公钥解密数字证书上面那个加密后的hash值，将两个hash值相对比，如果一样，那这个证书就是有效的，而且能够明确这个证书的公钥是谁的(毕竟上面的那些信息，包括名字，地址，邮箱等等等信息)，如果不一样，那这个证书是有问题的。于是握手流程又开始进化了，现在的握手是这样的:

client: hello server + 随机数1//测试通信通道是通的
server: hello client + 随机数2//回复是通的
server: 证书给你//发送server的数字证书
client对证书验证，验证是本人后发送随机数3
client:biubiubiu...........//利用公钥将发送的随机数3进行加密
client计算密钥
server计算密钥

快乐通信。。。。。。。。。。

数字证书进化:证书链

数字证书解决了服务端向客户证明我是我的难题，大家纷纷使用，然后CA忙不过来了，于是更多的CA被选出来了，而且各个CA也开始发展下线，即CA给下线验证授权，然后下线也可以给别人做证明啦，下线又发展下线，于是二代目，三代目，四代目等等都出来了，这么多公钥，怎么记得过来。于是大家又约定，CA一代目自己给自己签名一个证书，称其为根证书，然后大家将这些根证书保存，当一个陌生的网站发来证书时，我们先验证它的签发者，再验证签发它签发者的人，等等等，验证到最后如果这个最后的签发者在我们的根证书列表中，那这个陌生的网站就是受信任的，否则就是危险危险危险。。。。。。。。

参考资料

为了一个 HTTPS，浏览器操碎了心