禁用 HTTPS 的通用名称检查的安全影响

发布于 2024-07-06 09:02:36 字数 432 浏览 7 评论 0原文

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

因此,所有未来的请求都 我不确定禁用此检查的影响,我的第一反应是执行某种中间人攻击会更容易,因为其他人可以复制我们的证书并冒充我们的证书。但如果我们进行通用名称检查,您无论如何都可以使用自定义 DNS 设置执行相同的操作,因此它似乎实际上并没有给我们带来任何好处。 是否还有其他我们不会受到的攻击?

谢谢

I'm going over some client code I've inherited for doing secure communication over HTTPS, and it seems that it's not checking the common name in the server certificate (eg. 'CN = "example.com"' against the actual URL that's being requested. This is probably deliberate, since our client app is required to talk to various environments, so after contacting an initial portal (eg. example.com/main) and the user choosing an environment the app gets redirected to a specific IP, so all future requests look something like "http://127.0.0.1/page".

However being an SSL newbie, I'm unsure of the implications of disabling this check. My first reaction would be that it'd be easier to perform some kind of man-in-the-middle attack, since someone else could just copy our certificate and pretend to be one of our servers. But if we were doing common name checking you'd be able to do the same thing with custom DNS settings anyway, so it doesn't seem to actually gain us anything. Are there other attacks that this leaves us open to which we wouldn't be otherwise?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

芯好空 2024-07-13 09:02:36

其他人无法复制您的证书并使用它,因为他们没有您的私钥。

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

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

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

另请参阅此答案了解如果您对客户有足够的控制权,那么不同的方法将会有效。

Someone else can't just copy your certificate and use it because they don't have your private key.

If you don't check that the certificate's CN doesn't match the domain name then they can simply create their own certificate (and have it signed by a trusted CA so it looks valid), use it in place of yours, and perform a man in the middle attack.

Also, you need to be checking that the certificate comes from a trusted CA. It's the CA's job to make sure that you can only get a certificate with the CN= if you actually control that domain.

If you skip either of these checks then you are at risk of a MITM attack.

See also this answer for a different approach that will work if you have sufficient control over the client.

终弃我 2024-07-13 09:02:36

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

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

If you control the client code, then you can restrict the trusted CAs to just your own. Then the domain check is less important - any of your servers can pretend to be another one.

If you don't control the client code, then a cert signed by a trusted CA can be substituted for yours.

小镇女孩 2024-07-13 09:02:36

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

$0.02: using CN for host names is deprecated, X.509 Subject Alternate Names should be used instead.

请帮我爱他 2024-07-13 09:02:36
  • 通过验证证书本身以及它是否可以链接到您已经信任的 CA 证书,您可以检查该证书是否真实且有效。
  • 如果您已验证证书确实有效,则通过检查证书中的主机名,您可以检查您正在与要与之通信的服务器进行通信。
  • (检查远程方确实是持有该证书私钥的一方是在 SSL/TLS 握手中完成的。)

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

  • 验证证书就像检查护照或某种形式的身份证件是真实的。 您可以决定接受某人的哪种形式的身份证件(例如护照、驾驶执照、员工卡……)以及您信任哪些发行人国家/地区能够验证其真实性。
  • 检查远程方是否持有私钥类似于检查护照/身份证上的照片是否与您面前的人的脸部相符。
  • 检查主机名就像检查护照是否属于您要查找的人。

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

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

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

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

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

  • Verifying the certificate itself and that it can be chained to a CA certificate you already trust allows you to check that the certificate is genuine and valid.
  • Checking the host name in the certificate allows you to check you're talking with the server you intended to talk to, provided you've verified the certificate to be valid indeed.
  • (Checking that the remote party is indeed the one holding the private key for that certificate is done within the SSL/TLS handshake.)

If you want an analogy with passport/ID checking for people:

  • Verifying the certificate is like checking that a passport or a form of ID is genuine. You can decide which forms of ID you want to accept from a person (e.g. passport, driving licence, staff card, ...) and which issuer countries you trust to be able to verify their authenticity.
  • Checking that the remote party is the one holding the private key is similar to checking that the picture on the passport/ID matches the face of the person in front of you.
  • Checking the host name is like checking the passport belongs to the person whose name is the one you're looking for.

If you don't check the host name, anyone with a valid passport that you consider genuine could come to you and claim they're the one you're looking for (by name).

In very limited set of circumstances, where you only trust a specific CA or self-signed cert where you allow any potential certificate to impersonate any other in the entire set of certificates you trust, it can be acceptable to ignore this verification, but this is very rare, and not good practice.

Checking that the name in the passport matches the name of the person you're looking for would be considered common sense; do it for certificates too. Not doing so allows anyone who has a certificate that you trust as genuine to impersonate any other certificate you would trust, thereby potentially perform MITM attacks.

The HTTPS host name verification rules are defined in RFC 2818 Section 3.1 (also more recently in a "best practices" spec, RFC 6125, not much implemented yet).

In short, the host name should be in a Subject Alternative Name DNS entry (although you can fall back on the CN of the Subject DN where there's no SAN in the certificate). When you're using an IP address, the IP address must be in a SAN IP-address entry (although some browsers will let you get away with the IP address in the CN of the Subject DN).

咿呀咿呀哟 2024-07-13 09:02:36

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

To do the same thing with "custom DNS settings" the attacker should exploit a DNS server (yours or a client's) to point example.com to an IP he controls, as opposed to just copying the certificate. If possible I'd create all the specific apps as subdomains of example.com and use a wildcard certificate (*.example.com) to be able to validate the CN.

剑心龙吟 2024-07-13 09:02:36

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

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

Hostname verification (verifying the CN part) guarantees that the other end of the connection (server) is having a SSL Certificate issues with the domain name you typed in the address bar. Typically an attacker will not be able to get such a certificate.

If you don't verify the hostname part, somebody (somebody sit at any of the routers or proxies the request passes though) could do a man in the middle attack. Or somebody could do exploit some DNS attacks.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文