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
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
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
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
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.