6

我正在查看我为通过 HTTPS 进行安全通信而继承的一些客户端代码,它似乎没有检查服务器证书中的公用名(例如,'CN = "example.com"' 与实际 URL被请求。这可能是故意的,因为我们的客户端应用程序需要与各种环境对话,因此在联系初始门户(例如 example.com/main)并且用户选择环境后,应用程序将被重定向到特定 IP,所以所有未来的请求看起来都像“ http://127.0.0.1/page ”。

但是,作为 SSL 新手,我不确定禁用此检查的含义。我的第一反应是执行某种中间人攻击会更容易,因为其他人可以复制我们的证书并假装是我们的服务器之一。但是,如果我们进行通用名称检查,那么无论如何您都可以使用自定义 DNS 设置来做同样的事情,所以它似乎并没有真正为我们带来任何好处。是否还有其他攻击让我们敞开心扉,否则我们不会受到攻击?

谢谢

4

6 回答 6

10

其他人不能只是复制您的证书并使用它,因为他们没有您的私钥。

如果您不检查证书的 CN 是否与域名不匹配,那么他们可以简单地创建自己的证书(并由受信任的 CA 签名,因此看起来有效),使用它代替您的,然后执行中间攻击的人。

此外,您需要检查证书是否来自受信任的 CA。CA 的工作是确保您只有在您实际控制该域的情况下才能获得带有 CN= 的证书。

如果您跳过这些检查中的任何一个,那么您将面临 MITM 攻击的风险。

如果您对客户端有足够的控制权,另请参阅此答案以了解另一种可行的方法。

于 2008-09-26T11:09:09.180 回答
5

如果您控制客户端代码,那么您可以将受信任的 CA 限制为您自己的。那么域检查就不那么重要了——你的任何服务器都可以伪装成另一台服务器。

如果您不控制客户端代码,则可以用受信任的 CA 签名的证书代替您的。

于 2008-09-26T11:28:35.280 回答
4

0.02 美元:不推荐使用 CN 作为主机名,而应使用 X.509 主题备用名称。

于 2008-09-28T10:37:30.353 回答
2
  • 验证证书本身以及它是否可以链接到您已经信任的 CA 证书允许您检查证书是否真实有效。
  • 检查证书中的主机名允许您检查您正在与您打算与之交谈的服务器交谈,前提是您已验证证书确实有效。
  • (检查远程方确实是持有该证书私钥的一方在 SSL/TLS 握手中完成。)

如果您想与护照/身份证检查进行类比:

  • 验证证书就像检查护照或身份证件是否真实。您可以决定您希望从一个人那里接受哪些形式的身份证明(例如护照、驾驶执照、员工证……)以及您信任哪些发行国能够验证他们的真实性。
  • 检查远程方是否是持有私钥的一方类似于检查护照/身份证上的图片是否与您面前的人的脸相匹配。
  • 检查主机名就像检查护照是否属于您要查找的那个人。

如果您不检查主机名,那么任何持有您认为真实的有效护照的人都可能来找您并声称他们就是您要找的人(按姓名)。

在非常有限的情况下,您只信任特定 CA 或自签名证书,您允许任何潜在证书模拟您信任的整个证书集中的任何其他证书,忽略此验证是可以接受的,但这是非常罕见,也不是很好的做法。

检查护照上的姓名是否与您要找的人的姓名相符将被视为常识;也为证书做。如果不这样做,任何拥有您信任的真实证书的人都可以冒充您信任的任何其他证书,从而可能执行 MITM 攻击。

HTTPS 主机名验证规则在RFC 2818 第 3.1 节中定义(最近也在“最佳实践”规范RFC 6125中,尚未实现太多)。

简而言之,主机名应该在主题备用名称 DNS 条目中(尽管您可以使用证书中没有 SAN 的主题 DN 的 CN)。当您使用 IP 地址时,该 IP 地址必须位于 SAN IP 地址条目中(尽管有些浏览器会让您使用主题 DN 的 CN 中的 IP 地址)。

于 2012-10-23T18:25:24.693 回答
0

主机名验证(验证 CN 部分)可确保连接的另一端(服务器)与您在地址栏中键入的域名存在 SSL 证书问题。通常,攻击者将无法获得这样的证书。

如果您不验证主机名部分,那么某人(有人坐在任何路由器或请求通过的代理)可能会进行中间人攻击。或者有人可以利用一些 DNS 攻击。

于 2008-09-28T10:32:52.097 回答
0

要对“自定义 DNS 设置”做同样的事情,攻击者应该利用 DNS 服务器(您的或客户的)将 example.com 指向他控制的 IP,而不是仅仅复制证书。如果可能,我会将所有特定应用程序创建为 example.com 的子域,并使用通配符证书 (*.example.com) 来验证 CN。

于 2008-09-26T10:58:07.693 回答