【问题标题】:Why not trust all http certificates为什么不信任所有 http 证书
【发布时间】:2012-04-27 14:21:20
【问题描述】:

我编写了一个资源管理器处理程序,用于为我组织中的几个不同站点提供资源 (js/css)。大多数站点是内部站点,但少数站点是外部站点并使用 ssl。 QA/Dev 站点没有与证书相同的域名,因此需要我使用回调进行自定义验证。我了解我可以执行以下操作,例如检查我的环境并仅在不在生产中时返回 true,或者检查域名并在与我的 qa/dev 域匹配时返回 true。我的问题不是怎么做,而是为什么?为什么接受资源处理程序的所有证书对我来说是不安全的?用户实际上可以做哪些恶意的事情?

ServicePointManager.ServerCertificateValidationCallback += ValidateRemoteCertificate;
public static bool ValidateRemoteCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors)
{
     return true;//Why not do this?
}

更新:认为我可能需要对处理程序的作用进行一些说明。通过此处理程序的所有资源请求都经过哈希处理。处理程序解密请求并通过从程序集中拉取资源或通过对项目自己的本地资源发出请求来提供资源。唯一发生域不匹配的情况是当我的处理程序请求该本地资源时。回想起来,我认为也许我应该以不同的方式处理它,但是关于我最初的问题,我仍然看不到 MITM 攻击如何应用,并且感觉在这种情况下接受所有证书是安全的,但我不是 100%为什么这就是我在这里提出它的原因。 :)

【问题讨论】:

  • 证书很容易伪造。信任所有证书会使您容易受到来自不受信任站点的任意数量的攻击。此外,证书存在的原因是因为假设存在一些您不信任的人或证书。
  • 这是服务器端代码还是客户端代码?代码看起来像客户端代码,你的描述听起来像服务器代码。
  • @fbfcn,不过那是客户端代码。
  • @SilverNinja:[...] 一种用于客户端对服务器证书进行自定义验证的方法。

标签: .net security ssl


【解决方案1】:

这违背了 HTTPS 的目的。

如果您接受所有证书,任何人都可以使用自签名证书进行中间人攻击,并且可以正常工作。

【讨论】:

  • 我明白这一点,但在提供 css 或 JS 的情况下,我想我不明白中间人攻击将如何应用。
  • @fbfcn:MITM 可以添加流氓 JS 以任意更改页面(例如,添加键盘记录器)
  • 既然是服务器端,难道服务器就不会受到 MITM 攻击吗?
  • 我同意@SliverNinja 的观点,我认为他更能理解我的要求。 Rogue JS 真的不适用,因为服务器没有受到损害,只有个人已经损害了他们自己。
  • @fbfcn 很难理解您要做什么,因为您显然在谈论客户端代码。它是否在您的服务器上运行,以连接到另一台服务器(在这种情况下,您的服务器在这方面是客户端)?
【解决方案2】:

您需要验证与您交换秘密的人的身份,否则他们可能是冒名顶替者。

从客户端到服务器,活跃的 MITM 攻击者可以使用他们自己的证书并将流量中继到真实站点,而您不会注意到。在Security.SE: Downside of allowing uncertified Certificates 上查看此问题。

在接受客户端证书时(从服务器的角度来看)。您将与客户still exchange data secretly,但您不会告诉您客户是谁。客户端证书用于身份验证,您可以通过在没有额外验证的情况下允许任何内容来绕过它(并使此步骤无用)。

编辑(您刚刚补充说它是从服务器端的角度来看的):

大概,您正在做的是接受任何证书,然后将它们包含的名称作为用户的身份。这样做的缺点是您实际上并没有进行任何身份验证:您只是接受用户声称的表面价值的名称。这有点像接受一张写着“我的名字是 X”的纸,而不是检查正式的身份证件(例如护照)。

【讨论】:

    【解决方案3】:

    您将容易受到中间人攻击,因为您信任提供给您的任何证书。

    只有当攻击者可以冒充每个端点让对方满意时,中间人攻击才能成功——这是对(或缺乏)相互身份验证的攻击。

    http://en.wikipedia.org/wiki/Man-in-the-middle_attack

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2014-02-14
      • 2012-06-29
      • 1970-01-01
      • 1970-01-01
      • 2014-10-19
      • 2015-09-30
      • 1970-01-01
      • 2016-10-22
      相关资源
      最近更新 更多