DNSSEC doesn't prevent MITM #15158
Comments
|
Detailed log of resolvectl query bryanquigley.com with incorrect IP entry. |
|
"systemd-resolved only supports opportunistic DNS over an encrypted channel. Opportunistic here means that it will reach out and connect over TLS when available, but it won’t verify that it’s connecting to the correct server; make it susceptible to the man-in-the-middle interception as described in "Actually secure DNS over TLS in Unbound." " manpage says: "Note that in "opportunistic" mode the resolver is not capable of authenticating the server, so it is vulnerable to "man-in-the-middle" attacks." |
The DNSSEC downgrade has some problems like systemd/systemd#10579 and there are a few other issues like systemd/systemd#17406 and systemd/systemd#15158. Particularly the failure to resolve in case of a downgrade is causing problems in the test suite.
|
I don't mean to be aggressive (and I'm developing a kind-of competing SW), but overall I'm baffled by the systemd's approach here. Incurring the extra costs of DNSSEC validation and still not getting its protection... to me personally that sounds worse than either extreme. By the nontrivial extra costs I mean performance to get the extra records, but also various bugs and issues, both in this code and other parties (e.g. when a legitimate domain just breaks its DNSSEC). |
|
What is more important, default configuration in both Ubuntu and Fedora prevents correct DNSSEC validation from any tool or library on its system. Tools like If it did just DNSSEC-aware caching and did not pretent to do validation, it would be better IMO. Proper validation is not simple task to implement. Even worse is when serious issues with it are reported and are ignored for 3 years! |
pemensik
added
downstream/rhel
DNSSEC is off by default, for a reason. |
|
I see "allow-downgrade" as the default: https://github.com/systemd/systemd/blob/main/meson_options.txt#L325 While it's right that "allow-downgrade" can't make impression that it's resistant to MITM, my point about getting the worse from both worlds holds there. |
|
Both Ubuntu and Fedora change build default to |
systemd version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
bryanquigley.com: 2606:4700:3030::6812:22a6 -- link: enp34s0
2606:4700:3035::6812:23a6 -- link: enp34s0
1.0.0.0 -- link: enp34s0
-- Information acquired via protocol DNS in 129.2ms.
-- Data is authenticated: no
It just reports that data is not authenticated, when I think it should fail (or just report the IPv6 bit).
The DNS server in question ( a home router in this case is doing the right thing according to delv):
Normal:
delv bryanquigley.com @192.168.254.254
; fully validated
bryanquigley.com. 300 IN A 104.18.34.166
bryanquigley.com. 300 IN A 104.18.35.166
bryanquigley.com. 300 IN RRSIG A 13 2 300 20200319200516 20200317180516 34505 bryanquigley.com. psckwes4JdpZs7rmjh3rriOXGzwNLaImx6TCHGFsaNbJeKS49YYpgwdm HTmGSm9/p/ZnRU6o8hbGg2vOTYVj4A==
MITM:
delv bryanquigley.com @192.168.254.254
;; insecurity proof failed resolving 'bryanquigley.com/A/IN': 192.168.254.254#53
;; resolution failed: insecurity proof failed
The text was updated successfully, but these errors were encountered: