如果你喜欢MITM攻击,就别管DNSSEC
摘要
文章认为,忽略DNSSEC会让用户暴露在中间人攻击之下,并以电子邮件、Matrix和XMPP为例,将其与历史上对HTTPS的抵制进行类比。
<p><a href="https://lobste.rs/s/pcuxjt/ignore_dnssec_if_you_like_mitm_attacks">评论</a></p>
查看缓存全文
缓存时间: 2026/06/24 22:02
# 忽略DNSSEC等于欢迎中间人攻击
来源:https://whynothugo.nl/journal/2026/06/24/ignore-dnssec-if-you-like-mitm-attacks/
2010年左右的一天,我们在工作中尝试了ARP投毒和拦截网络中其他主机的流量。我们立刻看到所有流量在网络中流动。在那些数据中,我们瞥见了几位同事通过MSN Messenger与家人聊天的消息片段。该死,我们并非有意窥探任何人,只是想更好地了解网络安全性。这种经历令人不安。
那时集线器和开放Wi-Fi网络也很常见,监听这些网络上的流量甚至不需要ARP投毒:只需被动监听即可。
大约在那时,我了解到了HTTPS,并且很明显它带来了巨大的改变。如果我们要向客户或亲人暴露服务,就需要使用TLS来确保服务安全。
然而,HTTPS一直面临阻力。“它很复杂,出问题时难以调试”。“如果弄错了,服务就会变得不可达”。“我们必须及时更新证书,否则服务会中断”。“它会增加开销和延迟”。
反对HTTPS的理由总是这些,大多基于恐惧和(可以理解的)缺乏经验。
这正是每次讨论DNSSEC时,我听到的反对它的理由。
## 忽略DNSSEC对邮件的影响[永久链接](https://whynothugo.nl/journal/2026/06/24/ignore-dnssec-if-you-like-mitm-attacks/#impact-of-ignoring-dnssec-on-email)
当我配置邮件客户端时,我提供邮箱和密码。客户端自动通过SRV记录解析IMAP和SMTP服务器,并连接到该服务器。
如果我没有使用DNSSEC,攻击者可以伪造这些DNS响应,将我的邮件客户端指向`smtp.evilattacker.com`。当邮件客户端连接到服务器时,TLS握手完全正常:服务器正确地为`smtp.evilattacker.com`出示了证书。
如果你留意客户端使用的服务器,这很容易发现。但如果他们用的是`smtp.gmaill.tech`,而你在用Gmail,就不那么容易了。对于每个从未听说过DNSSEC的人(即:99%的人类),这些攻击完全不可见。
在邮件的另一端,当一台服务器向另一台发送邮件时,它会查询目标域名的MX记录。同样,当我的邮件服务器通过DNS查找收件人的MX服务器时,攻击者可以毒化响应,然后我的邮件服务器将连接到攻击者的服务器。在这种特定情况下,由于反垃圾邮件规则的工作方式,攻击者的邮件很可能无法转发拦截的流量,因此这种攻击会留下更多证据(由于邮件未送达),但仍然完全可行。
在最后这种情况下,我要指出,即使没有DNSSEC,MTA-STS在一些特定情况下也能提供帮助,但在许多场景中很容易被绕过。
## 对Matrix的影响[永久链接](https://whynothugo.nl/journal/2026/06/24/ignore-dnssec-if-you-like-mitm-attacks/#impact-on-matrix)
Matrix通信协议的委派方法与此相同,并且同样面临中间人攻击的风险。
明确一点:Matrix的做法本身没有问题:它采用了行业标准方法。问题在于服务提供商和本地解析器忽略了DNSSEC。
## 对XMPP的影响[永久链接](https://whynothugo.nl/journal/2026/06/24/ignore-dnssec-if-you-like-mitm-attacks/#impact-on-xmpp)
XMPP在这方面很奇特,它并非以相同方式容易受到攻击。如果我将域名委派给别人的服务器,那台服务器需要出示我自己的域名的TLS证书,而不是我委派到的目标域名。即使存在DNS欺骗,最坏的情况也只是拒绝服务,而非中间人攻击。
这奇怪的一点是,如果我想将XMPP委派给其他人,我还需要授予他们为我的域名提供TLS证书的能力。
## 发行版和操作系统[永久链接](https://whynothugo.nl/journal/2026/06/24/ignore-dnssec-if-you-like-mitm-attacks/#distributions-and-oss)
几乎所有的发行版和操作系统默认不验证DNSSEC,这让我非常困扰。上述攻击几乎对任何人都可行,纯粹是因为糟糕的默认设置。
使用第三方的外部验证解析器没有意义。不仅因为那第三方可以轻易伪造响应,而且流量本身也很容易被拦截。这就像使用明文HTTP连接到一个“可信”的服务器,它会剥离HTTPS。整个链条的强度取决于其最薄弱的一环。
就个人而言,我在每台主机上使用本地验证实例的`unbound(8)`。`unwind(8)` (https://man.openbsd.org/unwind) 也是一个不错的选择。
相似文章
基于网页的密码学永远是骗局
该文章认为,基于网页的端到端加密本质上并不安全,因为分发客户端代码的服务器可以推送恶意更新,导致威胁模型不一致。文章还批评了 WhatsApp 和 Signal 等服务存在类似缺陷。
搭建自己的DoH(基于HTTPS的DNS)服务
一篇关于搭建自己的基于HTTPS的DNS(DoH)服务的指南,通过加密DNS查询来提升隐私和安全性。
电子邮件加密
本文追溯了电子邮件从其去中心化、基于信任的起源到现代安全问题的历史,解释了SMTP和MIME等协议是如何作为技术限制的变通方案而出现的,但这使电子邮件容易受到窃听和篡改。
设备如何自行发现加密DNS
本文解释了指定解析器发现(DDR)协议,该协议让设备能够自动发现加密DNS端点。它描述了查询如何工作、解析器如何响应,以及从普通DNS进行机会性升级的局限性。
内部服务的TLS证书正确实践
介绍了如何使用分视域DNS、带DNS解析器的VPN以及ACME客户端(如acme.sh配合Let's Encrypt)来为内部服务设置TLS证书,为自签名证书提供了实用的替代方案。