SSL 和中间人的误解

Posted 2023-02-21

【中文标题】SSL 和中间人的误解

【英文标题】：SSL and man-in-the-middle misunderstanding

【发布时间】：2013-02-01 04:31:11

【问题描述】：

我已经阅读了大量与此问题相关的文档，但我仍然无法将所有部分放在一起，所以我想问几个问题。

1234563受信任机构的元数据和数字签名。然后客户端决定她是否信任服务器，用公钥加密一些随机会话密钥并将其发回。此会话密钥只能使用存储在服务器上的私钥解密。服务器执行此操作，然后 HTTPS 会话开始。

所以，如果我在上面是正确的，那么问题是在这种情况下如何发生中间人攻击？我的意思是，即使有人用公钥拦截了服务器（例如 www.server.com）的响应，并且有办法让我认为他是 www.server.com，他仍然无法解密我的会话密钥没有私钥。

谈到相互身份验证，是否完全取决于服务器对客户端身份的信任？我的意思是，客户端已经可以确定她正在与正确的服务器进行通信，但是现在服务器想要找出客户端是谁，对吧？

最后一个问题是关于相互身份验证的替代方案。如果我在所描述的情况下充当客户端，如果我在 SSL 会话建立后在 HTTP 标头中发送登录名/密码怎么办？正如我所看到的，无法拦截此信息，因为连接已经安全，服务器可以依赖它来识别我。我错了吗？与相互身份验证相比，这种方法有哪些缺点（只有安全问题很重要，而不是实现复杂性）？

【参考方案1】：

只有当 SSL 的前提条件之一被打破时，对 SSL 的中间人攻击才是真正可能的，这里有一些例子；

服务器密钥已被盗 - 意味着攻击者可以伪装成服务器，而无法客户端知道。

客户端信任一个不可信的 CA（或者它的根密钥被盗的 CA）——任何持有可信 CA 密钥的人都可以生成一个伪装成服务器的证书，并且客户端会信任它。随着当今浏览器中预先存在的 CA 数量，这可能是一个真正的问题。这意味着服务器证书似乎会更改为另一个有效的证书，这是大多数客户端会对您隐藏的内容。

客户端无需根据其受信任的 CA 列表正确验证证书 - 任何人都可以创建 CA。如果没有验证，“Ben 的汽车和证书”将与 Verisign 一样有效。

客户端受到攻击，并在其受信任的根权限中注入了假 CA - 允许攻击者生成他喜欢的任何证书，并且客户端将信任它。恶意软件往往会这样做，例如将您重定向到虚假银行网站。

特别是＃2 相当讨厌，即使您为高度信任的证书付费，您的网站也不会以任何方式锁定该证书，您必须信任客户端浏览器中的所有 CA因为它们中的任何一个都可以为您的站点生成一个同样有效的假证书。它也不需要访问服务器或客户端。

【讨论】：

还有sslstrip之类的工具，会尝试透明地将https链接改写成http链接。

关于证书验证的另一点是客户端需要验证主机名。检查证书是否真实还不够好，它必须发给您要与之交谈的实体（请参阅here 和here）。至于 sslstrip，不幸的是最终是 up to the user to check they want to use SSL/TLS（尽管 HSTS 可以提供帮助）。

我可以编写一个 chrome（或任何其他浏览器）插件，在浏览器加密之前拦截数据吗？

另一个原因是“滥用信任”，如 TürkTrust 问题。

@Remover 不是真的... #1 是服务器上的私钥，与真正的公钥配对。在这种情况下，您将与真实服务器交谈，但其他人可以通过处于中间来解密流量。他们不能修改证书。 #2 涉及发送一个完全不同的证书，由“受信任的”CA 颁发，对客户端来说似乎是合法的。然后，攻击者可以代表您代理请求并以这种方式查看消息。两者都会导致妥协，但＃1在您的控制之下。不幸的是，#2 不是。

【参考方案2】：

客户端和服务器之间的任何人都可以对 https 进行中间人攻击。如果您认为这不太可能或很少见，请考虑 there are commercial products 系统地解密、扫描和重新加密 所有互联网网关上的 ssl 流量。他们通过向客户端发送一个即时创建的 ssl 证书来工作，其中详细信息从“真实”ssl 证书复制，但使用不同的证书链签名。如果此链以任何浏览器的受信任 CA 终止，则此 MITM 将对用户不可见。这些产品主要出售给公司以“保护”（警察）公司网络，并且应在用户知情和同意的情况下使用。但从技术上讲，没有什么能阻止 ISP 或任何其他网络运营商使用它们。 （假设 NSA has at least one trusted root CA signing key 是安全的）。

如果您正在提供一个页面，you can include an HTTP header 指示该页面应该使用什么公钥进行签名。这可能有助于向 MITM 提醒用户他们的“安全”连接，但这是一种首次使用时信任的技术。如果 Bob 还没有“真正的”公钥 pin 的记录，Mallory 只需重写文档中的 pkp 标头。使用这种技术 (HPKP) 的网站列表非常短。值得称赞的是，它包括 google 和 Dropbox。通常，一个 https 拦截网关会遍历来自几个使用 HPKP 的大型可信站点的页面。如果您意外看到 HPKP 错误，请小心。

关于密码，https 连接上的所有内容都受 https 保护，但域名除外，域名需要明文，以便可以路由请求。一般来说，建议不要将密码放在查询字符串中，因为它们可以在日志、书签等中徘徊。但是除非 https 被破坏，否则查询字符串是不可见的。

【讨论】：

但这意味着这个 MITM 设备（解密/扫描和重新加密流量的设备）需要访问受信任的 CA 之一，对吧？ （“伪造”服务器证书）。可以说这发生了。然后有人破坏了这个，信息公开了，新闻界就会出现丑闻，CA证书将从所有浏览器中删除，对吧？我的意思是，理想情况下......

没有没有。网关上的“SSL 检查”需要即时创建和签署证书，但它不需要根证书来执行此操作。它有一些中间证书，有一个链。浏览器是否信任链的根决定了您是否会看到证书错误。在工作中，我们被要求安装 fortinet 根证书，这样我们的浏览器就不会出现证书错误。但如果链以一个已经受信任的证书终止，它是透明的。

一位同事对为什么这些公司网络 MITM 技术对 Google 强制 SSL 来说是个坏主意的理解有限 - 他真的有一点正确性吗？

对不起，我不明白这个问题！

@bbsimonbb, No no. The "SSL Inspection" on the gateway needs create and sign certificates on the fly, but it doesn't need a root cert to do this. It has some intermediate cert, that has a chain. 但是，网关是否需要有效的 CA 才能签署这些即时证书，不是吗？对于恶意的中间人攻击者，是否不太可能获得由有效根 CA 颁发的这些中间 CA 之一？

【参考方案3】：

首先，我将简要描述一下我所理解的身份验证过程，也许我在这一步上弄错了。因此，客户端启动连接，服务器使用公钥、一些元数据和受信任机构的数字签名的组合来响应它。

服务器以 X.509 证书链和使用自己的私钥签名的数字签名进行响应。

然后客户端决定是否信任服务器

正确。

用公钥加密一些随机会话密钥并将其发回。

没有。客户端和服务器参与一个相互的会话密钥生成过程，其中会话密钥本身根本不会传输。

此会话密钥只能使用存储在服务器上的私钥解密。

没有。

服务器会这样做

没有。

然后 HTTPS 会话开始。

TLS/SSL 会话开始，但首先还有更多步骤。

所以，如果我在上面是正确的，那么问题是在这种情况下中间人攻击是如何发生的？

通过伪装成服务器并充当 SSL 端点。客户端将不得不省略任何授权步骤。遗憾的是，大多数 HTTPS 会话中唯一的授权步骤是主机名检查。

我的意思是即使有人用公钥拦截了服务器（例如www.server.com）的响应，然后通过某种方式让我认为他是www.server.com，他仍然无法解密我的会话密钥没有私钥。

见上文。没有要解密的会话密钥。 SSL 连接本身是安全的，您正在与之交谈的人可能不安全。

谈到相互身份验证，是否完全与服务器对客户端身份的信任有关？我的意思是，客户端已经可以确定她正在与正确的服务器进行通信，但现在服务器想要找出谁是客户端，对吧？

正确。

最后一个问题是关于相互身份验证的替代方案。如果我在所描述的情况下充当客户端，如果我在 SSL 会话建立后在 HTTP 标头中发送登录名/密码怎么办？如我所见，此信息无法被截获，因为连接已经安全，服务器可以依靠它来识别我。我错了吗？

没有。

与相互身份验证相比，这种方法有哪些缺点（只有安全问题很重要，而不是实现复杂性）？

它与用户名/密码一样安全，比私钥更容易泄露。

【讨论】：

感谢您的解释。我唯一不明白的是为什么你说客户端不向服务器发送会话密钥？嗯，可能是我用错了术语，here这段数据叫“pre-master secret”，但不管怎样，不是客户端发过来的，是用服务端私钥解密的吗？

@VadimChekry 预主密钥不是会话密钥。它是用于生成会话密钥的几条数据之一，在两端独立。该过程在 RFC 2246 中进行了描述。

@Chris 你的漏洞要小得多，但是 IP 地址欺骗是可能的。没有什么可以替代您自己检查证书中的对等身份。

+1 在大多数情况下，这是一个很好的答案。然而，有些观点缺乏用一个词的回答来解释。如果您要在正文中扩展和/或详细说明所述点（即，而不是“不”，您可以简要提及实际发生的事情。），您可以将其作为明确的答案。那真的会澄清一些事情。谢谢。

@tjt263 第一个“否”解释了实际发生的情况。接下来的两个“不”指的是产生第一个“不”的相同误解，并且具有相同的解释。下一个也是最后一个“不”指的是“我错了吗”，它指的是刚刚从 OP 中引用的信息。因此，很难理解您认为这里实际上缺少什么。

【参考方案4】：

正确 不太正确。在这种攻击中，中间服务器获取您的请求并代表您将其发送到目的地。然后用结果回复你。实际上，它是与您建立安全连接的中间人服务器，而不是您打算通信的实际服务器。这就是为什么您必须始终检查证书是否有效且受信任的原因。 可能是正确的 如果您确定安全连接是可信的，那么发送用户名/密码是安全的。

【讨论】：

关于 2 - 我假设客户端在连接建立过程中彻底检查服务器发送的元数据，并且客户端不信任所有证书。那么，如果-a）客户没有按照我上面所说的去做，或者b）中间人在某个地方获得了由受信任的CA签署的证书，那么这种情况是否可能发生？

中间服务器发送有效证书的情况非常罕见，如果我记得清楚的话，去年发生在 Comodo CA 上。但通常，如果它是受信任的连接，那么它是完全安全的。

【参考方案5】：

您所说的一切都是正确的，除了关于会话密钥的部分。 CA 的重点是击败中间人攻击——其他一切都由 SSL 本身完成。客户端身份验证是用户名和密码方案的替代方案。