网络安全协议（完善篇）|公钥|密钥|服务器|私钥|算法|网络安全

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

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

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

服务器持有非对称加密算法的公钥S与私钥S’
中间人持有非对称加密算法的公钥M与私钥M’
客户端向服务器发起请求，服务器明文传输公钥S给客户端
中间人劫持数据，可以提取公钥S并保存好，之后可以将被劫持数据中的公钥替换成自己的公钥M，并将伪造的数据发送给客户端
客户端接收到数据之后，提取了公钥M（当然这是完全不知情），自己形成对称密钥X，用公钥M加密X，形成的加密数据照常发送
中间人劫持后，直接用自己的私钥M’进行解密，得到的通信密钥X，再用曾静保存的服务器公钥S加密后，将数据推送至服务器。
服务器拿到发送的数据，用自己的私钥S’解密得到了密钥X，双方都开始采用X进行对称加密。

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

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

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

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

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

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

攻击者可能会修改证书内容，比如刚刚说的更改公钥为攻击者自身的公钥，或者修改证书中的其他信息。
攻击者可能会用自己的证书（可能是自签或者由不可信的CA签发的证书）替换掉原始的证书。

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

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