Ignore DNSSEC if you like MITM attacks · WhyNotHugo (雨果)One day around 2010, we experimented at work with ARP poisoning and intercepting<br>traffic for other hosts on the network at work. We immediately saw all traffic<br>flowing through the network. Between all that data, we caught a glace of bits of<br>messages of a few colleagues talking to their families over MSN Messenger. Shit,<br>we didn’t mean to spy on anyone, we were trying to understand our network<br>security better. The experience was unsettling.<br>Hubs and open Wi-Fi networks were also still common back then, and listening to<br>traffic on those didn’t even require ARP poisoning: it could be done entirely<br>passively by just listening.<br>I learnt about HTTPS around that time, and it was obvious to me that it made a<br>huge difference. If we were exposing a service to either clients or loved ones,<br>we needed to use TLS to ensure that the services were secure.<br>Yet, HTTPS continuously faced resistance. “It’s complex and hard to debug when<br>it fails”. “If we get it wrong, our services become unreachable”. “We have to<br>renew certificates in time or the service goes done”. “It adds overhead and<br>delays”.<br>The arguments against HTTPS were always the same, mostly based on fear and [an<br>understandable] lack of experience.<br>These are the exact same arguments that I hear against DNSSEC every time the<br>topic comes up.<br>Impact of ignoring DNSSEC on email[permalink]
When I configure an email client, I provide my email and password. The client<br>automatically resolves the IMAP and SMTP servers using SRV records and connects<br>to that server.<br>If I’m not using DNSSEC, an attacker can spoof these DNS responses and point my<br>email client to smtp.evilattacker.com. When the email client connects to the<br>server, the TLS handshake succeeds just fine: the server properly presents a<br>certificate for smtp.evilattacker.com.<br>If you’re paying attention to which server your client uses, this is easy to<br>spot. A bit less easy if perhaps they use smtp.gmaill.tech and you’re using<br>Gmail. For every human being who’s never heard of DNSSEC (i.e.: 99% of the human<br>population), these attacks are entirely invisible.<br>On the other side of email, when a server sends an email to another, it does so<br>by querying the MX records of a domain. Again, when my email server checks for<br>the recipient’s MX server via DNS, an attacker can poison the response, and now<br>my email server will connect to the attacker’s server instead. In this<br>particular case, the attacker’s email likely won’t be able to forward<br>intercepted traffic (due to how anti-spam rules work), so this kind of attack<br>leaves more evidence (by virtue of emails not being delivered), but is still<br>perfectly feasible.<br>In this last case, I’ll note that MTA-STS can help on some specific cases, even<br>in the absence of DNSSEC, but can easily be circumvented in many scenarios.<br>Impact on Matrix[permalink]
The Matrix communication protocol follows the same approach to delegation, and<br>is exposed to MITM attacks in the same way.<br>To be clear: there’s nothing wrong with Matrix’s approach here: it’s using an<br>industry standard approach. The issue is service providers and local resolvers<br>ignoring DNSSEC.<br>Impact on XMPP[permalink]
XMPP is really weird in this sense, and is not vulnerable in the same way. If I<br>delegate my domain to someone else’s server, that server needs to expose a TLS<br>certificate for my own domain, not for the target domain where I’m delegating.<br>Even with DNS spoofing, the worst that can happen is DOS, but not MITM.<br>The odd aspect of this, is that if I want to delegate XMPP for my domain to<br>someone else, I need to also grant the capabilities to provision TLS<br>certificates for my domain.<br>Distributions and OSs[permalink]
It really bothers me that almost all distributions and operating systems don’t<br>validate DNSSEC by default. The above attacks are feasible on almost anyone,<br>purely because of lousy defaults.<br>Using a third party external validating resolver doesn’t make sense. Not just<br>because that third party can easily spoof responses, but because traffic can<br>easily be intercepted too. It’s like using plain-text HTTP to a “trusted” server<br>which strips out HTTPS. The whole chain is as strong as its weakest link.<br>Personally, I use a local validating instance of unbound(8) on each host.<br>unwind(8) is also a neat choice.
Have comments or want to discuss this topic?<br>Send an email to my public inbox: ~whynothugo/public-inbox@lists.sr.ht.<br>Reply privately by email: hugo@whynothugo.nl.
— § —