网络传输协议 Tcp 的三次握手过程及天网防护策略

在上网冲浪的过程中，你是否也遇到过类似的状况，这时候你是选择无视继续访问还是选择当即关掉浏览器呢？

不管是选择关掉还是选择继续访问，你是否考虑过为什么会出现类似的提示？选择继续访问后，提示中的警告是否会真的发生吗？

也许你在经过简单的百度过后，了解到这可能与Https 有关，甚至会有一些大聪明教你来去除这些提示，可是掩耳并不能盗铃，去除风险提示并不代表去除了风险

带着这个疑问，我们接下来往下看

想要了解风险提示的生成，就必须要了解Https协议在网络传输中是如何发挥的作用，数字证书又是如何参与其中的，更进一步，你会发现这与当下的区块链技术也颇有瓜葛

总而言之，在当下波谲云诡的互联网信息安全时代，这大约是一个值得鉴赏的问题

访问一个网站很简单，在搜索框中输入网址即可直达，但数据在用户和服务器之间的流转可能经历万水千山

比如一个南京的用户访问位于北京的一个网址站点，中间可能经过这样若干个路由节点

在如此大的地利跨度下，很难保证其传输过程中不会出窃听者，篡改数据的黑客攻击者

这就好比你远方的朋友给你寄快递，很难保证其中不会出现偷看，偷换者

这其中的根本原因问题在于，Http协议数据直接以铭文的形式传输，以至于让攻击者不用费太大力气就能实施监听和篡改。更有甚者，早些年间，一些不讲武德的互联网运营商自己就会进行数据劫持，并在返给用户的数据中植入广告代码，于是那些年打开浏览器我们看到的鸡贼广告，就是如此

于是在上个世纪90年代中期，当人们意识到互联网的应用越来越广泛，其中所传递数据的价值也越来越大的时候，便不得不考虑为Http协议提供安全保障

第一个吃螃蟹的是当时浏览器乃至互联网行业的领导者，网景公司NetScape，他们于1994年在自己的浏览器中实现了对Https协议的支持，其实现方法是加密，通过对数据加密传输，解密使用，虽然数据经过万水千山，但早期面对密文，攻击者也无可奈何

加密者使用密钥加密明文得到密文，解密者必须使用同样的密钥才能解析出铭文，这被称之为对称加密，加解密使用同样的密钥，互为逆向过程

那么浏览器和服务器如果确定出一个同样的密钥呢，如果由一方生成再先以铭文的形式传递出去，

中间的过程攻击者自然也能轻松拦截下来，攻击者有了密钥，那么后续的加密也就没有意义了

让通信的双方，坐高铁去线下接头不失为一个安全的措施，但每次通信都要去和站长接头，似乎又不太现实

更实际的办法是使用非对称加密，非对称加密是一个和对称加密相呼应的概念，非对称加密中，密钥总是成对出现的，分别称之为公钥和私钥，用公钥加密的数据只能被私钥解密，公钥自己也无法解密，同样私钥加密的数据只能被公钥解密，私钥自己也无法解密

如此，服务器先将自己的公钥发送给浏览器，浏览器生成一个随机的数据，用服务器的公钥进行加密再发送给服务器，服务器用自己的私钥解密，如此双方就都得到了一个同样的随机数据，这个随机数据便可以作为对称加密的密钥，对真正要传递的数据进行加密传输。在这个过程中即便是攻击者拦截到了服务器的公钥也无济于事，因为公钥无法解密由他自身加密的数据，使用非对称加密协商出一个相同的密钥，然后用这个密钥进行对称加密传输正式数据，这就是Https协议中实现的大致原理，这是一套独立于Https协议之外的流程，也被称为安全套接字层SSL，而这个密钥协商的过程也被称之为SSl 握手

从1994年到1996年，SSL分别经历了三个版本的迭代，最终互联网工程事务组IETF决定将其标准化，最终于1999年以TLS这个新的称呼被发布，至今TLS已经于2006，2008，2018年经过了一系列的升级，升级内容包括比如随着Md5和Sha1加密算法逐渐丧失安全性，将其淘汰而用SHA-256取而代之，问题似乎得到了完美解决，但仅仅是似乎，这里面仍然有一个十分棘手的问题。如果服务器在传递给浏览器自己公钥的过程中把它拦截，并替换成自己的公钥再发送给浏览器，又当如何？

浏览器收到后，它无法知道这是被篡改过的，仍然用它加密作为后续对称加密公钥的随机数据。攻击者收到后，因为是被自己公钥加密的数据，所以自然可以用自己的私钥解密得到明文，然后再用服务器的公钥对其加密再发送给服务器，服务器用自己的私钥解密，攻击者就像一个黑中介一样，两头骗。这样，虽然通信的双方协商出了对称加密的密钥，但攻击者也知道了，所以接下来的加密变得毫无意义。问题的根本在于公钥并不能表明自己属于谁，所以解密的方式是让其具有表明自己身份的能力，这就需要引入一个第三方的角色。现在服务器除了自己的公钥之外，还把自己的域名，组织名及所申请的第三方机构信息放在一起，影形成一个数据集合，然后拿着数据集去找第三方机构，该机构也有一个公私钥对，用自己的私钥对这些数据进行加密，得到一个密文，称之为签名。然后把签名数据和原始铭文放在一起，发送给服务器的管理员，这就是所谓的TLS证书，而这个机构也被称为CA。

 

  现在服务器传递给浏览器的不再是自己的公钥，而是这个能表明自己身份的证书，浏览器拿到这个证书后，需要先进行验证而不是选择直接相信。方法也很简单，拿CA机构中公开的公钥对证书中的密文进行解密，如果解密的结果和证书中的明文一致，则通过验证。然后从证书中提取出服务器的公钥，加密随机数据发送，双方协商出对称加密的密钥，如果结果不一致则认为证书不合法。风险随之出现了

如此，原则上来说，中间的攻击者将再也没有可能进行欺骗，攻击者拦截并篡改的目的是为了让浏览器在密钥协商的过程中使用自己的公钥。所以如果现在攻击者拦截到目标服务器的证书后把其中的公钥改成自己的。那么浏览器收到后解密签名结果中的公钥部分和篡改以后的对不上，其中必然有诈。

 

 

，