☰

SRV DNS 记录目标的 TLS 证书名称

tag-icon • tag-icon domain-name-system security ssl
SRV DNS 记录目标的 TLS 证书名称

当设置 DNS SRV 记录时_service._proto.example.com. IN SRV 0 0 443 service.example.com.，为什么 TLS 证书名称service.example.com:443是example.com而不是service.example.com？

我读过使用 SRV 记录时 TLS 证书的名称是什么这是为了防止中间人攻击，但我不确定为什么：使用 DNSSEC 可以防止对 DNS 的 MITM 攻击。

这种设计的问题如下。假设有以下 DNS SRV 记录：

_service1._proto.example.com. IN  SRV 0 0 443 service1.example.com.
_service2._proto.example.com. IN  SRV 0 0 443 service2.example.com.
_service3._proto.example.com. IN  SRV 0 0 443 service.provider.com.

必须example.com向管理服务 1 和服务 2 的团队以及外部服务提供商的团队提供名为 的 TLS 证书。这样，任何服务的泄露都可能导致所有服务的泄露。

这似乎是 DNS SRV 记录设计中的一个缺陷。是吗？

答案1

这可能是依赖于实现的答案。但一般来说，它会根据 DNS 中用于“重定向”的选项起作用：

  • 别名记录：客户端的请求被重定向 -将显示最初请求的 FQDN在目标证书中，因为重定向是在原始请求期间完成的。

  • 服务车辆记录（您询问的用例）-将会有后续查询到 SRV 记录中提供的目的地，因此证书中只会请求最终目的地（来自 SRV 记录的 FQDN），因为它不是相同的请求，后续请求直接以新的 FQDN 为目标。

例如，在 Exchange 服务器上的自动发现功能中可以看到此行为。如果您在一个 Exchange 上托管了多个域，一旦使用 SRV 记录设置了自动发现功能，服务器上的证书中只需要自己的 FQDN（因此不需要列出所有托管域）。

这里的 DNSSEC“要求”是由于这种行为造成的 - 因为一旦攻击者可以在 DNS 答复中传递自己的 SRV 记录，就会出现后续查询，目的地可以是任何 FQDN，因此攻击者可以轻松获得注入的 SRV 记录指向的自己的域的适当的可信证书。

如果实施不完全正确，客户端可以使用来自 SRV 的信息来发现查询的端点（如 CNAME 记录）并在请求中保留原始 FQDN。在这种情况下，可能需要原始 FQDN - 目标系统上的证书中存在原始 FQDN 只是为了解决客户端 SRV 记录实施不当的问题...

相关内容