中间人攻击与 SSL 证书颁发机构

Question

什么阻止了中间人攻击证书颁发机构的请求以验证证书？浏览器是否预先加载了受信任证书颁发机构的公钥（从而提供身份验证）？

每当我想到 MITM 攻击时，我认为任何防御都需要建立一个“安全”连接来进行身份验证，而任何“安全”连接的初始建立似乎总是受到 MITM 攻击本身的影响。因此，例如，如果上述受信任的证书颁发机构的公钥确实与浏览器一起分发，则浏览器的分发将受到 MITM 攻击。据我了解，即使您亲自将公钥/证书/纸上的任何内容交给某人，您也最好从其他地方了解他们，否则他们可能是中间人。

我理解正确吗？

谢谢！

Answer 1

什么阻止了中间人攻击证书颁发机构的请求以验证证书？

当浏览器收到由 提供的证书时，它不会连接到颁发证书的机构 (CA) 来验证证书；它必须已经先验地信任 CA。根据证书、CA 和浏览器，它可能会连接到 CA 证书中包含的 URL 以检查站点提供的证书是否已被撤销（撤销列表），但该连接由 CA 证书保护而不是网站提供的证书。据我所知，大多数浏览器实际上并没有这样做，尽管大多数可以配置。如果 CA 证书遭到破坏，则需要手动删除 CA 证书，或者通过补丁或新版本的浏览器代码删除。

浏览器是否预先加载了受信任证书颁发机构的公钥（从而提供身份验证）？

是的。不仅仅是公钥，它实际上是来自 CA 的自签名证书，其中包含公钥，除了吊销列表之外，还应该包含用于验证证书本身的 URL，以及可能更多。基本上，每个浏览器制造商都必须决定预安装哪些 CA，省略哪些 CA，这是一个备受讨论和大生意的话题。大多数 CA 销售证书可以赚很多钱，并且在每个浏览器中预先安装它们对它们有利，因此它们努力推动浏览器制造商安装它们。但是，CA 的可信度是一个会在安全人员中引起很多争论的话题。

每当我想到 MITM 攻击时，我认为任何防御都需要建立一个“安全”连接来进行身份验证，并且任何“安全”连接的初始建立似乎总是受到 MITM 攻击本身的影响。因此，例如，如果上述受信任的证书颁发机构的公钥确实与浏览器一起分发，则浏览器的分发将受到 MITM 攻击。

虽然确实如此，但这是一个比其他方法更难的攻击媒介，您可以通过在安装之前验证浏览器的分发文件来对抗它（即根据网站的已发布哈希验证安装文件的 SHA1 哈希） ）。那时，攻击者将不得不渗透到浏览器制造商或证书颁发机构中，这也是更困难的攻击媒介（尽管肯定不是闻所未闻）。

据我了解，即使您亲自将公钥/证书/纸上的任何内容交给某人，您也最好从其他地方了解他们，否则他们可能是中间人。

好吧，将您的公钥（或包含公钥的证书）提供给其他人是无害的。这意味着他们可以验证您使用所述证书签名的内容是否确实来自您（并且他们可以加密只有您可以解密的内容）。

但从根本上说，你是对的。在某些时候，您必须信任某人。这是关于安全、网络、业务和生活的重要事项。当然，您需要以健康的怀疑态度来缓和这一点，并不断重新评估您的信任关系。当然，你也应该记住 Gipper 的一些明智的建议：“信任，但要验证”（或者，如果你愿意：遵循俄罗斯古老谚语的合理建议：““doveryai，no proryai”[俄语： ???????, ?? ????????]”）。要真正保护您的计算机，您需要关闭它的电源，将其拆开，销毁组件，然后销毁剩余物。

就与他人建立信任关系而言，拥有一个已经信任他们的共同朋友会有所帮助。这就是“信任环”背后的全部要点 在某些时候，您必须有一点信心。你怎么知道给你颁发驾照的人真的是国家雇员。当然，你可以生成你的公钥，记住指纹，然后在目标系统上安装公钥

我理解正确吗？

我不确定，但我怀疑是这样。请把这一切都复述给我，用你自己的话来解释，我会让你知道的。

编辑：实际上，正如 GregD 指出的那样，所有这些都是学术性的，因为当浏览器警告他们不信任证书时，大多数人会单击“仍然继续”按钮，然后游戏就结束了。当然，如果您在企业工作，并控制发布用户的系统，您可能可以对其进行配置，使其不显示该按钮，但您将不得不处理后果。单击该按钮的唯一时间是当您未连接到网络并且在您和提供不受信任证书的系统之间有单线时（即使如此，这也是有争议的）。