☰

DNSSEC - 它如何防范 MITM 攻击？

tag-icon • tag-icon dnssec
DNSSEC - 它如何防范 MITM 攻击？

我已经阅读了几个小时，DNSSEC但我仍然不明白它是如何防止MITM攻击的。我还阅读了与 serverfault 相关的每个问题DNSSEC。

请看一下这个DNSSEC数据包捕获：https://www.cloudshark.org/captures/79e23786259b

什么可以阻止MITM拦截每个查询，并使用自己的密钥对回复每个DNSKEYS、RRSIG和DS记录？

例如，将为MITMwww.ietf.org 生成 RRSIG，然后DNSKEYS为 生成ietf.org，然后DS为 生成记录ietf.org。然后为“org”生成另一组DNSKEYS和DS记录，然后再次为 生成<Root>。

在 TLS 中，我们可以信任 CA 的信任链，因为每个系统上都预装了根 CA，所以我们可以根据它检查回复。在 中DNSSEC，我不相信根 CADNSKEY安装在像根 CA 那样的系统上。那么是什么让我们可以信任我们收到的这个根密钥呢？

答案1

这个问题解决了信任链：此链中的每个环节都在前一个区域中签名了DS记录，正如您在问题中提到的那样。这强调了锚在根名称服务器上。如果这是欺骗性的，整个信任链受到损害。因此，解析器必须预先配置信任锚。RFC 6781解释：

4.2.3. 解析器中锚定密钥的泄露

密钥也可以在解析器中预先配置为信任锚。如果信任锚密钥被泄露，则应通知使用这些密钥的解析器的管理员。区域管理员可以考虑设置邮件列表，以传达即将轮换 SEP 密钥的事实。当然，这种沟通需要通过某种方式进行身份验证，例如使用数字签名。

面临更新锚定密钥任务的最终用户应始终验证新密钥。新密钥应在带外进行身份验证，例如，通过使用使用传输层安全性 (TLS) 保护的公告网站[RFC5246]。

您可以下载当前根信任锚 ( bind.keys)直接从互联网系统联盟获取。该网站使用 TLS 进行保护，并且文件也使用其签名密钥进行签名。

如果您没有任何内容named.conf并且没有bind.keys 文件，则 named 将使用已编译的键。

注意：这些是托管密钥，因此这仅适用于您第一次执行named。假设密钥尚未过期（在这种情况下named将记录密钥已过期，验证将不起作用），named将使用RFC 5011检测新密钥并自动滚动和维护密钥。一旦named管理密钥，如果您使用视图，当前密钥将位于managed-keys.bind或中。*.mkeys

另一个问题是与解析器的通信，即“最后一英里”。解析器可能正在验证签名并使用 DNS 进行应答经过验证的数据(AD) 位，但由于 DNS 以纯文本形式工作，结果可能会被中间人 (MITM) 攻击者修改。对此有多种可能的解决方案：

  • 您可以拥有一个包含锚密钥文件的本地解析器，但这对大众来说并不是一个实用的解决方案。如果没有配置转发器，它还会给根名称服务器带来更多流量。这是一个不信任任何人的解决方案，您需要自己验证签名。

  • DNS-over-TLS&HTTPS 上的 DNS. 例如 Cloudflare 及其1.1.1.1 支持两者：

    我们需要的是转向一种新的、现代化的协议。有几个

不同的方法。一种是 DNS-over-TLS。它采用现有的 DNS 协议并添加传输层加密。另一种是 DNS-over-HTTPS。它不仅包括安全性，还包括所有现代增强功能，例如支持其他传输层（例如 QUIC）和新技术，例如服务器 HTTP/2 服务器推送。DNS-over-TLS 和 DNS-over-HTTPS 都是开放标准。

我们认为 DNS-over-HTTPS 特别有前景 - 速度快、更易于解析和加密。——我们希望随着现在独立的 DNS-over-HTTPS 服务的推出，我们将看到更多来自浏览器、操作系统、路由器和应用程序的实验来支持该协议。

  • DNS加密使用加密签名对 DNS 客户端和 DNS 解析器之间的通信进行身份验证。该技术从未向 IETF 提出过（没有 RFC）。

答案2

除了 Esa Jokinen 的详细答复之外，让我们回顾一下：

我不相信根 DNSKEY 安装在像根 CA 那样的系统上。这是您的错误假设，它导致了您正确描述的所有后果。

但根 DNSKEY 确实随解析器一起提供。这本身就带来了其他问题，特别是在计划更改此密钥之后（原计划于去年 10 月进行，但被推迟了）。

您确实有一个 DNSSEC 引导程序。该软件必须具有带外密钥，但也可能需要更新它。如果您今天购买了一款产品，因此附带当前密钥，将其保持这种状态 2 年，然后打开电源，当前的 DNSKEY 根密钥将被另一个密钥替换，会发生什么情况？

您可以想象很多事情，例如...让我们通过 HTTPS 从 IANA 网站获取密钥！但要做到这一点，您需要解析 IANA 网站名称，因此您需要依赖 DNS 和您正尝试配置的相关 DNSSEC。当然，您也不会对 IANA 网站 IP 地址进行硬编码。或者您可以想象只依赖 TLS，因为您甚至可以在 TLS 握手期间交换 DNS/DNSSEC 信任链...但这意味着您需要随附 CA 证书，而该证书本身可以更改（即使我们现在可以说 CA 证书比 DNSSEC 根密钥持续更长时间...但使用 Let's Encrypt，我们还可以想象未来 CA 更短...），所以回到原点。

鸡和蛋的问题。

您可以在本文档中了解有关此问题及其解决方案的更多信息，例如：https://datatracker.ietf.org/doc/draft-jabley-dnsop-bootstrap-validator/ 本文档讨论了在 DNSSEC 验证器中自动配置信任锚的方法。

如果您已经拥有有效（当前）的 DNSSEC 根密钥，则可以遵循特定的程序，以便在发生以下情况时自动安全地切换到较新的密钥：DNS 安全 (DNSSEC) 信任锚的自动更新

相关内容