4 ms·
Even if they can rewrite the MAC and force a new one via ping, which are usually already disabled, they still can’t eavesdrop on the TLS key exchange. I fail to
by this-is-why 7mo ago
Even if they can rewrite the MAC and force a new one via ping, which are usually already disabled, they still can’t eavesdrop on the TLS key exchange. I fail to see how this is a risk to HTTPS traffic? It’s a mitm sure but it is watching encrypted traffic.
- amiljkovic 7mo agoThe Ars article mentions: “Even when HTTPS is in place, an attacker can still intercept domain look-up traffic and use DNS cache poisoning to corrupt tables stored by the target’s operating system.” Not sure, but I think this could then be further used for phishing.
- jcalvinowens 7mo agoDNSSEC prevents that if set up properly.
- tptacek 7mo agoThis is an on-path attacker. In end-user DNS configurations, attackers can simply disable DNSSEC; it's 1 bit in the DNS response header ("yeah, sure, I verified this for you, trust me").
- jcalvinowens 7mo agoNo, modern resolvers like systemd-resolved actually check the dnssec signatures on the client.
- akerl_ 7mo agoCan you link to a distro config that defaults to that?
- jcalvinowens 7mo agoNo, it's experimental. But I run it on all my machines, the only time I've had a problem is when it caught a typo in a DS record.
- tptacek 7mo agoNobody has ever disputed that you could run a fully recursive cache on your workstation, only that any ordinary user ever does. You can see at this point how hollow "DNSSEC" is as an answer to the problem of this thread.
- jcalvinowens 7mo agoIt's not a full recursive lookup: you don't understand how DNSSEC works. I'm not replying to you any more.
- tptacek 7mo agoI'm guessing I do. Anyways: no question that there are a variety of experimental setups in which you can address the problem of on-path attackers trivially disabling DNSSEC, freeing you up to work on the next, harder set of DNSSEC security and operational problems.
- tptacek 7mo agoTo check the DNSSEC signatures on the client, you have to do a full recursive lookup. You've always been able to run your own DNS cache, if you want your host to operate independently of any upstream DNS server. But at that point, you're simply running your own DNS server.
- jcalvinowens 7mo agoIt's not necessarily equivalent to a recursive lookup, you can ask a cache for all the answers because you already know the root keys a priori. But yes, it does follow the entire chain of trust, that's the entire point of dnssec: if you don't do that the whole exercise is utterly pointless.
- tptacek 7mo agoIt's explicitly not the point of DNSSEC, which has for most of its entire existence been designed to be run as a server-to-server protocol, with stub resolvers trusting their upstream DNS servers. I agree with you, though. It's utterly pointless.
- jcalvinowens 7mo agoNot true, RFC4035 says all security aware resolvers SHOULD verify the signatures. It's far from pointless when actually implemented. Don't dismiss a whole protocol just because some historical implementations have been half assed.
- tptacek 7mo agoThe RFC uses "security-aware" to set them apart from ordinary resolvers, which are what every mainstream resolver uses.