4 ms·

As other comments said, DNS is vulnerable to man-in-the-middle attacks without DNSSEC, and DNSSEC is not widely adopted. However, even with DNSSEC, bob could o

As other comments said, DNS is vulnerable to man-in-the-middle attacks without DNSSEC, and DNSSEC is not widely adopted. However, even with DNSSEC, bob could obtain domain.tld's keys and then use them to MITM alice's DNS requests, getting her browser to show a malicious site for domain.tld complete with a trusted certificate. Furthermore, bob can do this for alice and only alice, decreasing the odds of detection by a large margin. With LE you gain: - Targeted attacks harder to pull off, since you would need to successfully attack the LE servers/networks first and then your actual target. - LE participates in the certificate transparency initiative, meaning every time a certificated is emitted for a domain it gets recorded. These things are particularly relevant when you consider that in most cases the DNS is either directly or indirectly controlled by state actors at their root. With DNS-only, they could pull off such targeted attacks without anybody noticing. With LE, they can still pull off these attacks, but there would be a papertrail when that happened.

tssva 6y ago
DNSSEC is not about protecting MITM attacks against DNS traffic. DNSSEC is about validating that DNS records have not been tampered with. Are you thinking about DNS over HTTPS and DNS over TLS?
- kilburn 6y ago
  I've always undrestood that MITM attacks can both be: - active (injecting/tampering with content), which is what DNSSEC protects against. - passive (eavesdropping), which is what DNS over TLS protects against. Am I missing something?
  - tssva 6y ago
    MITM involves monitoring and/or altering the traffic between two endpoints which believe they are talking directly. If DNS traffic between Alice's client and configured DNS server can be intercepted DNSSEC provides no real protection because unlike TLS all information to verify signed records are provided in band via DNS. Once the traffic can be intercepted and return traffic spoofed the attacker can return the appropriate records to make it appear that the response is properly signed without any need of having the DNSSEC keys being used at the authoritative DNS server for that domain. DNS over HTTPS, DNS over TLS and DNSCurve are intended to protect against this type of interception/tampering and should be used along side DNSSEC.
    - kilburn 6y ago
      I think you are incorrect here. DNSSEC protects from the root servers' (.) keys downward. If you have a compliant DNSSEC resolver it should authenticate the entire chain using the pre-shared keys for the root domain. For a MITM attack to work in this scenario, the attacker would have to first get fake keys for the root domain (that normally come with the OS) into your computer, at which point not even DNS over anything would work because they should be able to install TLS certs too. As far as I know, all these DNS-over-TLS flavors' advantage is that they prevent eavesdropping, not spoofed traffic (because DNSSEC can do that too as per my explanation above).
      - tptacek 6y ago
        The parent comment is more right than not: end-systems in fact don't perform DNSSEC validation, but rather rely on their DNS servers to do it for them. On the network path between an end-system and its DNS server, no cryptography is deployed to protect DNS records; rather, a single bit in the header signals to DNS resolvers that some DNSSEC validation has been performed, somewhere. Along that network path, any middlebox can tamper with the DNS. It's not an academic concern, because the two most common modes of deployment for DNS are "with ISP DNS servers", in which case one of your most important and active DNS adversaries is on-path, and "with services like 8.8.8.8", in which case the whole Internet is between you and the thing that validated DNSSEC for you. It's not a good system, and it's true that DoH does a better job at addressing this problem.
        kilburn 6y ago
        That totally makes sense. Thanks for the explanation!
        tialaramex 6y ago
        It's certainly true that if you want your resolver to live on a separate node that you trust, yet there's a network you don't trust between you and that node, DPRIVE attempts to solve that and DNSSEC does not. But without DNSSEC a middlebox still gets to tamper anyway, since there's no authenticity of the answers you receive, you're just moving your trustworthy source of these potentially bogus answers for whatever that's worth. Thomas believes your ISP is "one of your most important and active DNS adversaries" and yet astonishingly he trusts them to provide you with authentic DNS answers. If you do local validation, which you're free to, DNSSEC solves the problem. If you do remote validation but you trust the remote DNS server to do that on your behalf correctly, DNSSEC solves the problem and then any DPRIVE protocol brings those correct answers home intact. If you believe there are certainly authentic answers where Google is (I have a lot of used iron available, central Paris area, it's in the form of a big tower so you can't miss it, buyer collects) then just DPRIVE lets you get their authentic answers. Notice that Google does not warrant that this is true, and "where Google is" might mean a data centre controlled by your country's censors.

tssva 6y ago

DNSSEC is not about protecting MITM attacks against DNS traffic. DNSSEC is about validating that DNS records have not been tampered with. Are you thinking about DNS over HTTPS and DNS over TLS?

kilburn 6y ago
I've always undrestood that MITM attacks can both be: - active (injecting/tampering with content), which is what DNSSEC protects against. - passive (eavesdropping), which is what DNS over TLS protects against. Am I missing something?
- tssva 6y ago
  MITM involves monitoring and/or altering the traffic between two endpoints which believe they are talking directly. If DNS traffic between Alice's client and configured DNS server can be intercepted DNSSEC provides no real protection because unlike TLS all information to verify signed records are provided in band via DNS. Once the traffic can be intercepted and return traffic spoofed the attacker can return the appropriate records to make it appear that the response is properly signed without any need of having the DNSSEC keys being used at the authoritative DNS server for that domain. DNS over HTTPS, DNS over TLS and DNSCurve are intended to protect against this type of interception/tampering and should be used along side DNSSEC.
  - kilburn 6y ago
    I think you are incorrect here. DNSSEC protects from the root servers' (.) keys downward. If you have a compliant DNSSEC resolver it should authenticate the entire chain using the pre-shared keys for the root domain. For a MITM attack to work in this scenario, the attacker would have to first get fake keys for the root domain (that normally come with the OS) into your computer, at which point not even DNS over anything would work because they should be able to install TLS certs too. As far as I know, all these DNS-over-TLS flavors' advantage is that they prevent eavesdropping, not spoofed traffic (because DNSSEC can do that too as per my explanation above).
    - tptacek 6y ago
      The parent comment is more right than not: end-systems in fact don't perform DNSSEC validation, but rather rely on their DNS servers to do it for them. On the network path between an end-system and its DNS server, no cryptography is deployed to protect DNS records; rather, a single bit in the header signals to DNS resolvers that some DNSSEC validation has been performed, somewhere. Along that network path, any middlebox can tamper with the DNS. It's not an academic concern, because the two most common modes of deployment for DNS are "with ISP DNS servers", in which case one of your most important and active DNS adversaries is on-path, and "with services like 8.8.8.8", in which case the whole Internet is between you and the thing that validated DNSSEC for you. It's not a good system, and it's true that DoH does a better job at addressing this problem.
      - kilburn 6y ago
        That totally makes sense. Thanks for the explanation!
      - tialaramex 6y ago
        It's certainly true that if you want your resolver to live on a separate node that you trust, yet there's a network you don't trust between you and that node, DPRIVE attempts to solve that and DNSSEC does not. But without DNSSEC a middlebox still gets to tamper anyway, since there's no authenticity of the answers you receive, you're just moving your trustworthy source of these potentially bogus answers for whatever that's worth. Thomas believes your ISP is "one of your most important and active DNS adversaries" and yet astonishingly he trusts them to provide you with authentic DNS answers. If you do local validation, which you're free to, DNSSEC solves the problem. If you do remote validation but you trust the remote DNS server to do that on your behalf correctly, DNSSEC solves the problem and then any DPRIVE protocol brings those correct answers home intact. If you believe there are certainly authentic answers where Google is (I have a lot of used iron available, central Paris area, it's in the form of a big tower so you can't miss it, buyer collects) then just DPRIVE lets you get their authentic answers. Notice that Google does not warrant that this is true, and "where Google is" might mean a data centre controlled by your country's censors.