在之前的文章中，我概述了密码学，并讨论了保密性（保持数据秘密）、完整性（保护数据免遭篡改）和身份验证（了解数据来源的身份）的核心概念。由于身份验证与现实世界中身份的所有混乱情况密切相关，因此围绕确定某人是否是他们声称的那个人，已经发展出一个复杂的技术生态系统。在本文中，我将大致描述这些系统是如何工作的。
公钥密码学和数字签名的快速回顾
在线世界的身份验证依赖于公钥密码学，其中密钥有两个部分：所有者保密的私钥和与世界共享的公钥。公钥加密数据后，只有私钥才能解密它。如果举报人想与记者建立联系，例如，此功能很有用。对于本文更重要的是，私钥可以与消息组合以创建数字签名，从而提供完整性和身份验证。
在实践中，签名的不是实际消息，而是通过加密哈希函数发送消息获得的消息摘要。发送者不是签署整个源代码 zip 文件，而是签署该 zip 文件的 256 位 SHA-256 摘要，并将 zip 文件以明文形式发送。接收者独立计算他们收到的文件的 SHA-256 摘要。他们将摘要、收到的签名和发送者的公钥输入到签名验证算法中。验证过程因加密算法而异，并且存在足够的细微之处，以至于签名验证漏洞仍然弹出。如果验证成功，则文件在传输过程中未被修改，并且必须源自发送者，因为只有发送者拥有创建签名的私钥。
拼图中缺失的部分
此场景中缺少一个主要细节。我们从哪里获得发送者的公钥？发送者可以将公钥与消息一起发送，但这样我们就无法证明他们的身份，只能证明他们自己的断言。想象一下，你是一名银行柜员，一位顾客走过来，说：“你好，我是简·多伊，我想取款。” 当你要求出示身份证明时，她指着衬衫上写着“简·多伊”的名字标签贴纸。就我个人而言，我会礼貌地拒绝“简”。
如果您已经认识发送者，您可以亲自见面并交换公钥。如果您不认识，您可以亲自见面，检查他们的护照，一旦您确信它是真实的，就接受他们的公钥。为了提高效率，您可以举办一个聚会，邀请一群人，检查他们所有的护照，并接受他们所有的公钥。在此基础上，如果您认识简·多伊并信任她（尽管她有不寻常的银行业务习惯），简可以去参加聚会，获得公钥，并将其交给您。事实上，简可以使用她自己的私钥签署其他公钥，然后您可以使用在线公钥存储库，信任简签署的公钥。如果一个人的公钥由您信任的多个人签名，那么您也可能会决定信任那个人（即使您不认识他们）。以这种方式，您可以构建一个信任网络。
但是现在事情变得复杂了：我们需要决定一种标准方法，将密钥和与该密钥关联的身份编码到一个我们可以签名的数字捆绑包中。更恰当地说，这些数字捆绑包称为证书。我们还需要可以创建、使用和管理这些证书的工具。我们解决这些和其他要求的方式构成了公钥基础设施 (PKI)。
超越信任网络
您可以将信任网络视为一个由人组成的网络。人与人之间有许多互连的网络使找到一条简短的信任路径变得容易：例如，社交圈。GPG 加密的电子邮件依赖于信任网络，并且它可以运行（理论上），因为我们大多数人主要与相对较小的朋友、家人和同事群体进行交流。
在实践中，信任网络存在一些重大问题，其中许多问题与扩展有关。当网络开始变得更大，人与人之间的联系很少时，信任网络开始崩溃。如果信任路径在很长的人链中被削弱，您将面临更高的机会遇到粗心或恶意签名密钥的人。如果根本没有路径，您必须通过联系对方并验证他们的密钥以使您满意来创建路径。想象一下，您要去一家您和您的朋友从未使用过的在线商店。在您建立安全的通信渠道来下订单之前，您需要验证该网站的公钥属于该公司，而不是冒名顶替者。这种审查将需要去实体店、打电话或其他一些费力的过程。在线购物将变得非常不方便（或者非常不安全，因为很多人会偷工减料，在没有验证的情况下接受密钥）。
如果世界上有一些非常值得信赖的人不断验证和签署网站的密钥会怎样？您只需信任他们，浏览互联网就会顺畅得多。在更高的层面上，这就是今天的工作方式。这些“非常值得信赖的人”是称为证书颁发机构 (CA) 的公司。当网站想要签署其公钥时，它会向 CA 提交证书签名请求 (CSR)。
CSR 就像存根证书，其中包含公钥和身份（在本例中为服务器的主机名），但未由 CA 签名。在签名之前，CA 会执行一些验证步骤。在某些情况下，CA 仅验证请求者是否控制 CSR 中列出的主机名的域（例如，通过与 WHOIS 条目中的地址进行质询-响应电子邮件交换）。在其他情况下，CA 会检查法律文件，例如营业执照。一旦 CA 满意（通常在请求者支付费用后），它会从 CSR 中获取数据并使用自己的私钥对其进行签名以创建证书。然后，CA 将证书发送给请求者。请求者将证书安装在其网站的 Web 服务器上，并且当用户通过 HTTPS（或任何其他使用 TLS 保护的协议）连接时，证书会传递给用户。
当用户连接到站点时，他们的浏览器会查看证书，检查证书中的主机名是否与它连接到的主机名相同（稍后会详细介绍），并验证 CA 的签名。如果这些步骤中的任何一个失败，浏览器将显示警告并断开连接。否则，浏览器将使用证书中的公钥来验证从服务器发送的一些签名信息，以确保服务器拥有证书的私钥。这些消息也用作建立将加密后续消息的共享密钥的几种算法之一的步骤。密钥交换算法超出了本文的范围，但在 此视频 中对其中一种算法进行了很好的讨论。
创建信任
您可能想知道，“如果 CA 的私钥签署证书，这意味着要验证证书，我们需要 CA 的公钥。它来自哪里，谁来签署它？” 答案是 CA 为自己签名！可以使用与同一证书的公钥关联的私钥对证书进行签名。这些证书被称为自签名；它们是 PKI 等同于说“信任我”。（人们经常说，作为一种简写形式，证书已经签署了某物，即使是私钥——根本不在证书中——在进行实际签名。）
通过遵守 Web 浏览器 和 操作系统 供应商建立的策略，CA 证明他们足够值得信赖，可以放入浏览器或操作系统中内置的一组自签名证书中。这些证书称为信任锚或根 CA 证书，它们放置在根证书存储区中，并在其中被隐式信任。
CA 还可以颁发具有充当 CA 本身能力的证书。通过这种方式，他们可以创建证书链。为了验证链，程序从信任锚开始，并（除其他事项外）使用当前证书的公钥验证下一个证书上的签名。它继续沿着链向下，验证每个链接，直到到达末尾。如果沿途没有问题，则建立信任链。当网站付费给 CA 以签署其证书时，他们是在为被放置在该链末端的特权付费。CA 将出售给网站的证书标记为不允许签署后续证书；这是为了他们可以在适当的位置终止信任链。
为什么链会超过两个链接长？毕竟，站点只需要其证书由 CA 的根证书签名。在实践中，CA 出于方便（以及其他原因）创建中间 CA 证书。CA 根证书的私钥非常宝贵，以至于它们驻留在专用设备中，即 硬件安全模块 (HSM)，该模块需要多人解锁，完全离线，并保存在装有警报器和摄像头的金库内。
管理 CA 的 CAB 论坛 要求 任何与 CA 根证书的交互都必须由人直接执行。如果每个证书请求都需要员工将请求放在安全介质上、进入金库、与同事一起解锁 HSM、签署证书、退出金库，然后将已签名的证书复制到介质上，那么每天为数十个网站颁发证书将是乏味的。相反，CA 创建内部中间 CA，用于自动签署证书。
您可以通过单击 URL 栏中的锁形图标、打开页面信息并单击“安全”选项卡上的“查看证书”按钮，在 Firefox 中查看此链。截至撰写本文时，opensource.com 具有以下链
DigiCert High Assurance EV Root CA
DigiCert SHA2 High Assurance Server CA
opensource.com中间人
我之前提到过，浏览器需要检查证书中的主机名是否与它连接到的主机名相同。为什么？答案与所谓的中间人 (MITM) 攻击有关。这些是网络攻击，允许攻击者将自己插入客户端和服务器之间，伪装成服务器对客户端，反之亦然。如果流量通过 HTTPS，则它是加密的，窃听是徒劳的。相反，攻击者可以创建一个代理，该代理将接受来自受害者的 HTTPS 连接，解密信息，然后与原始目标建立 HTTPS 连接。为了创建虚假的 HTTPS 连接，代理必须返回攻击者拥有私钥的证书。我们的攻击者可以生成自签名证书，但受害者的浏览器不会信任任何未由浏览器根证书存储区中的 CA 根证书签名的证书。如果攻击者改为使用受信任的 CA 为其拥有的域签名的证书，该怎么办？
想象一下，我们又回到银行工作。一个人走进银行，要求从简·多伊的账户中取款。当被要求出示身份证明时，这个人递给我们一张乔·史密斯的有效驾驶执照。如果我们允许交易继续进行，我们将被解雇是理所当然的。如果浏览器检测到证书主机名和连接主机名之间不匹配，它将显示一个警告，内容类似于“您的连接不安全”，并提供显示其他详细信息的选项。在 Firefox 中，此错误称为 SSL_ERROR_BAD_CERT_DOMAIN。
如果我希望您从本文中记住一个教训，那就是：如果您看到这些警告，请勿忽视它们！它们表明该站点的配置要么存在严重错误，以至于您不应该使用它，要么您可能是 MITM 攻击的潜在受害者。
最后想法
在本文中，我仅触及了 PKI 世界的表面，但我希望我为您提供了一张地图，您可以用来指导您的进一步探索。密码学和 PKI 在其美丽和复杂性方面都像分形。您越深入，就越有待发现。
2 条评论