101

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

  1. 首先，我将简要描述我所理解的身份验证过程，因为我可能在这方面犯了错误：客户端启动连接，服务器使用公钥、一些元数据和数字签名的组合来响应受信任的权威。然后客户端决定她是否信任服务器，用公钥加密一些随机会话密钥并将其发回。此会话密钥只能使用存储在服务器上的私钥解密。服务器执行此操作，然后 HTTPS 会话开始。

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

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

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

4

5 回答 5

112

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

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

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

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

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

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

于 2013-02-16T06:38:24.440 回答
22

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

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

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

于 2015-09-14T15:59:23.360 回答
19

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

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

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

正确的。

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

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

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

不。

服务器这样做

不。

然后开始 HTTPS 会话。

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

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

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

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

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

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

正确的。

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

不。

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

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

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

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

于 2013-02-16T06:19:53.440 回答