您所描述的内容听起来很像我与朋友共享 PGP 密钥的方式。当我们都是书呆子并手动添加密钥并在我们这样做时在电话上聊天时,它工作正常,但这种方法不能很好地扩展。
CA 在您第一次需要以自动化方式信任连接的情况下解决了您的第二个问题——事实证明,这比您想象的更经常是绝对必要的。这通常被称为引导问题- 或“......但我们第一次如何做到这一点?”
场景1:我在朋友家,想查看我的gmail。我的朋友使用 hotmail,因此她的计算机事先没有信任 gmail.com。我怎么知道它是真正的 gmail.com,而不是看起来像 gmail.com 的网络钓鱼网站?我如何“建立信任”足以给它我的用户名和密码?CA 解决了这个问题,因为 CA 的证书被固定在浏览器中,并且站点提供了由 CA 签名的证书,现在浏览器相信这是真正的 gmail.com。
场景 2:考虑企业 VPN 环境中的 CA。该公司聘请了一名新人,他将从不同的国家远程工作。您要确保他们第一次连接到公司网络时,他们可以对服务器进行身份验证,而不仅仅是将您的公司网络的凭据提供给某些黑客。CA 解决了这个问题,因为您可以将 CA 的证书嵌入(或“固定”)到 VPN 客户端可执行文件中,并让 VPN 服务器提供由该 CA 签名的证书。
场景 3:电子邮件。我的服务器出了点问题。我打电话给一些我被提及的承包商,他们说“将您的防火墙的日志文件发送给我们,我们会找出问题所在”。我从未见过这些人,我如何获得他们的公钥?我想他们可以通过电话向我读取 SHA2 哈希以进行确认,但这是一个巨大的麻烦。CA 解决了这个问题,因为(假设我的 IT 部门以一些复杂的方式设置了 Outlook)Outlook 将验证他们的证书返回到受信任的根。
场景4:银行转账。我要求我的银行将钱电汇给我的朋友,他使用一些不知名的小型银行——也许是在海外。您可以打赌,银行不会只是将钱汇到它不信任的服务器上。你也可以打赌,由于地球上银行的数量庞大,银行不会在每次需要建立新服务器时将 U 盘邮寄给其他所有银行(这可能是响应流量高峰)。CA 解决了这个问题。实际上,银行网络SWIFT使用复杂的 CA 层次结构来保护全球银行间交易。
除了上述技术场景之外,还有可用性问题:在当前模型中,TLS 正在保护您的数据和连接,无论您是否知道它在那里,这对我祖母来说是个好消息。能够将所有证书验证回受信任的根 CA 是您的浏览器在幕后轻松完成的事情。因此,即使一个更手动的导入/信任密钥系统有效,即使我也会觉得它非常不方便,而且我是 1% 以此为生的人的一部分。我的祖母会……嗯,有麻烦了。