Ignore DNSSEC if you like MITM attacks
摘要
文章从作者早期进行 ARP poisoning 的经历讲起，说明在未加密网络中可以轻易截获他人通信，并由此引出 HTTPS 的必要性。随后作者将当年对 HTTPS 的常见质疑（复杂、难排错、证书维护等）与今天反对 DNSSEC 的论点进行类比，认为两者本质类似。 文中重点分析未使用 DNSSEC 时的风险：在邮件场景中，攻击者可通过伪造 SRV 或 MX 记录，将客户端或服务器重定向到恶意主机，即使 TLS 握手成功也可能发生流量劫持；MTA - STS 在部分情况下可缓解但并不总是有效。在 Matrix 协议中，因其依赖 DNS 进行服务发现，同样面临类似 MITM 风险。 相比之下，XMPP 的机制不同，其 TLS 证书绑定在自身域名上，使得即使 DNS 被篡改也更难实现 MITM，但仍可能造成拒绝服务。最后文章批评多数操作系统与发行版默认不验证 DNSSEC，并指出依赖第三方解析器同样不安全，作者建议使用本地 DNSSEC 验证解析器（如 unbound）以降低风险。
荐读理由
默认关闭 DNSSEC 就让 MITM 攻击几乎对所有人完全可见：邮件、Matrix、XMPP 服务器可被随意重定向到恶意服务器，而 XMPP 反而因证书绑定原理对这种攻击免疫。作者用 2010 年网络安全经历和多年经验给出这套硬道理，证明忽略 DNSSEC 不是技术权衡，而是自己把安全门打开；建议用 unbound 本地验证解析器，闭环彻底堵死链路。
原文
One day around 2010, we experimented at work with ARP poisoning and intercepting traffic for other hosts on the network at work. We immediately saw all traffic flowing through the network. Between all that data, we caught a glace of bits of messages of a few colleagues talking to their families over MSN Messenger. Shit, we didn’t mean to spy on anyone, we were trying to understand our network security better. The experience was unsettling.
Hubs and open Wi-Fi networks were also still common back then, and listening to traffic on those didn’t even require ARP poisoning: it could be done entirely passively by just listening.
I learnt about HTTPS around that time, and it was obvious to me that it made a huge difference. If we were exposing a service to either clients or loved ones, we needed to use TLS to ensure that the services were secure.
Yet, HTTPS continuously faced resistance. “It’s complex and hard to debug when it fails”. “If we get it wrong, our services become unreachable”. “We have to renew certificates in time or the service goes done”. “It adds overhead and delays”.
The arguments against HTTPS were always the same, mostly based on fear and [an understandable] lack of experience.
These are the exact same arguments that I hear against DNSSEC every time the topic comes up.
Impact of ignoring DNSSEC on email
[permalink]
When I configure an email client, I provide my email and password. The client automatically resolves the IMAP and SMTP servers using SRV records and connects to that server.
If I’m not using DNSSEC, an attacker can spoof these DNS responses and point my email client to smtp.evilattacker.com. When the email client connects to the server, the TLS handshake succeeds just fine: the server properly presents a certificate for smtp.evilattacker.com.
If you’re paying attention to which server your client uses, this is easy to spot. A bit less easy if perhaps they use smtp.gmaill.tech and you’re using Gmail. For every human being who’s never heard of DNSSEC (i.e.: 99% of the human population), these attacks are entirely invisible.
On the other side of email, when a server sends an email to another, it does so by querying the MX records of a domain. Again, when my email server checks for the recipient’s MX server via DNS, an attacker can poison the response, and now my email server will connect to the attacker’s server instead. In this particular case, the attacker’s email likely won’t be able to forward intercepted traffic (due to how anti-spam rules work), so this kind of attack leaves more evidence (by virtue of emails not being delivered), but is still perfectly feasible.
In this last case, I’ll note that MTA-STS can help on some specific cases, even in the absence of DNSSEC, but can easily be circumvented in many scenarios.
Impact on Matrix
[permalink]
The Matrix communication protocol follows the same approach to delegation, and is exposed to MITM attacks in the same way.
To be clear: there’s nothing wrong with Matrix’s approach here: it’s using an industry standard approach. The issue is service providers and local resolvers ignoring DNSSEC.
Impact on XMPP
[permalink]
XMPP is really weird in this sense, and is not vulnerable in the same way. If I delegate my domain to someone else’s server, that server needs to expose a TLS certificate for my own domain, not for the target domain where I’m delegating. Even with DNS spoofing, the worst that can happen is DOS, but not MITM.
The odd aspect of this, is that if I want to delegate XMPP for my domain to someone else, I need to also grant the capabilities to provision TLS certificates for my domain.
Distributions and OSs
[permalink]
It really bothers me that almost all distributions and operating systems don’t validate DNSSEC by default. The above attacks are feasible on almost anyone, purely because of lousy defaults.
Using a third party external validating resolver doesn’t make sense. Not just because that third party can easily spoof responses, but because traffic can easily be intercepted too. It’s like using plain-text HTTP to a “trusted” server which strips out HTTPS. The whole chain is as strong as its weakest link.
Personally, I use a local validating instance of unbound(8) on each host. unwind(8) is also a neat choice.
这条对你有帮助吗？