网络安全协议（完善篇）

在上一期文章当中，提及到了网络安全协议的诞生和发展方向，上期留下了一个问题，在不断进化的安全方案中，依然存有小许缺陷。接下来我们会了解到，小缺陷是如何解决的。

从上期提到的方案4中，客户端获取到公钥S之后，对客户端形成的对称密钥X用服务端给客户端的公钥S进行加密，中间人即使窃取到了数据，确实是无法接触客户端形成的密钥X，因为只有服务器有私钥S’。但是，如果中间人的攻击在最开始握手协商的时候就开始进行劫持，那么方案4就不一定安全了。

那么，我们可以通过模拟场景更具象化地看一下这种方案被劫持信息的可能：

但是这一切都在中间人的掌握中，劫持数据，进行窃听甚至修改都是可以的。因为 客户端无法确定收到含有公钥的数据就是目标服务器发送过来的。被攻击的核心原因是客户端无法验证公钥的合法性，在这种情况下就需要一个公平公正的第三方机构来进行认证，确保客户端连接的服务器是合法的。

为实现这个概念，从而出现了各种网站都需要“引入CA数字证书”，一个可以确保自己的网站、服务器是合法合规并且安全的手段。我们都知道，互联网是虚拟的，通过互联网我们无法正确获取对方真实身份，数字证书提供了一种在互联网上验证实体身份的方式。

CA是证书的签发机构，是公钥基础设施（Public Key Infrastructure,PKI)的核心，用于证明自身身份，比较像身份证和驾驶证。拥有强大的“摘要算法”（也就是常说的散列函数、哈希函数），可以理解为一种特殊的压缩算法，能够把任意长度的数据“压缩”成固定长度、且独一无二的“摘要”字符串，就好像给这段数据生成了一个数字“指纹”。

在我国实名制政策下，应用CA证书的申请者主要围绕电子政务、商务、金融、企业内网和软件分发这些领域，为更好地保护机密数据和用户资料。CA在申请者提交完整身份资料后，会为申请者分配一个公钥，并且CA将该公钥与申请者的身份信息绑在一起形成证书发给申请者。但这不是挂起来的证书，而是安装在服务器的证书。

大多数浏览器开发商在发布浏览器版本时，会预先在浏览器内部植入常用认证机关的CA证书，客户端（比如浏览器）内置了很多收信人的CA证书，这些CA证书中的公钥是用来验证服务器证书签名的。而这种内置的CA证书是浏览器厂商和操作系统开发商管理和更新的，他们确保客户端可以信任这些CA证书，在我们使用HTTPS的网站时，浏览器可以自动验证证书的有效性，确保用户安全。

那么还有一个问题，如果“中间人攻击”对数字证书进行了篡改，我们又要怎样辨别确认所收到的数字签名的真实性？

这种证书正正是为了杜绝这种情况的发生。首先第一：中间人无法伪造签名，即使中间人截获了服务器发送的证书，并试图篡改证书内容或替换服务器公钥，他也无法生成一个有效的数字签名，因为他并没有CA的私钥。只有拥有CA私钥的机构（真正的CA机构）才能生成匹配的签名。中间人即使知道生成签名的算法，也无法在没有CA私钥的情况下生成合法签名。

其二：如果中间人篡改证书内容（比如替换公钥），客户端在解密数字签名后会发现，解密得到的哈希值与客户端计算出的哈希值不匹配。这意味着证书已经被篡改，客户端会拒绝信任这个证书，并会终止与服务器的连接。防止信息泄露给攻击者。

经过这一系列的迭代，我们得到的最优解决方案，非对称式加密+对称式解密+CA证书，是HTTPS锁采取的方案。在建立连接时，HTTPS比HTTP多了TLS的握手过程。这个过程包括客户端向服务器索要并验证服务器的公钥，确保是服务器形成的，然后双方会产生一个密钥，用来加密双方之间的内容。

由此我们可以了解到HTTPS通过SSL/TLS协议提供了一种加密的通信方式，可以防止数据在传输过程中被截获和窃取，而HTTP只是明文传输，没有加密手段。所以，HTTPS比HTTP更加安全。

这下总会明白为什么不建议下载一些渠道外的软件了吧？一些没有正规机构出具证书的网站或软件都能以之前说的“中间人攻击”方式劫持用户的数据并发送他们想让用户看到的信息。一步一步让用户掉入陷阱之中。