8 ms·
It is important. This is unfortunate rhetoric that is harming the safety of the internet. "For instance, in April 2018, a Russian provider announced a number o
by iscoelho 1y ago
It is important. This is unfortunate rhetoric that is harming the safety of the internet.
"For instance, in April 2018, a Russian provider announced a number of IP prefixes (groups of IP addresses) that actually belong to Route53 Amazon DNS servers."
By BGP hijacking Route53, attackers were not only able to redirect a website to different IPs, globally, but also generate SSL certificates for that website. They used this to steal $152,000 in cryptocurrency. (I know I know, "crypto", but this can happen to any site: banking, medical, infrastructure)
Also, before you say, RPKI doesn't solve this either, although a step in the right direction. DNSSEC is a step in the right direction as well.
[1] https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/ https://www.cloudflare.com/learning/security/glossary/bgp-hi...
- tptacek 1y agoBGP attacks change the semantic meaning of IP addresses themselves. DNSSEC operates at a level above that. The one place this matters in a post-HTTPS-everywhere world is at the CAs, which are now all moving to multi-perspective validation.
- iscoelho 1y agoAs you should be aware, multi-perspective validation does not solve anything if your BGP hijack is accepted to be global. You will receive 100% of the traffic. DNSSEC does greatly assist with this issue: It would have prevented the cited incident.
- tptacek 1y agoA BGP attacker doesn't need to alter the DNS to intercept traffic; they're already intercepting targeted traffic at IP selectivity.
- iscoelho 1y agoThere are 2 ways to pull off this attack: 1. Hijack the HTTP/HTTPS server. For some IP ranges, this is completely infeasible. For example, hijacking a CloudFlare HTTP/HTTPS range would be almost impossible theoretically based on technical details that I won't go through listing. 2. Hijack the DNS server. Because there's a complete apathy towards DNS server security (as you are showing) this attack is very frequently overlooked. Which is exactly why in the cited incident attackers were capable of hijacking Amazon Route53 with ease. *DNSSEC solves this.* If either 1 or 2 work, you have yourself a successful hijack of the site. Both need to be secure for you to prevent this.
- tptacek 1y agoIn summation, you propose a forklift upgrade of the DNS requiring hundreds of millions of dollars of effort from operators around the world, introducing a system that routinely takes some of the most sophisticated platforms off the Internet entirely when its brittle configuration breaks, to address the problem of someone pulling off a global hijack of all the Route53 addresses. At this point, you might as well just have the CABForum come up with a new blessed verification method based on RDAP. That might actually happen, unlike DNSSEC, which will not. DNSSEC has lost signed zones in North America over some recent intervals. I do like that the threat model you propose is coherent only for sites behind Cloudflare, though.
- iscoelho 1y ago"I do like that the threat model you propose is coherent only for sites behind Cloudflare, though." The threat model I proposed is coherent for Cloudflare because they have done a lot of engineering to make it almost impossible to globally BGP hijack their IPs. This makes the multi-perspective validation actually help. Yes, other ISPs are much more vulnerable than Cloudflare, is there a point? You are not saying DNSSEC doesn't serve a real purpose. You are saying it is annoying to implement and not widely deployed as such. That alone makes me believe your argument is a bit dishonest and I will abstain from additional discussion.
- tptacek 1y agoNo, I'm saying it doesn't serve a real purpose. I've spent 30 years doing security work professionally and one of the basic things I've come to understand is that security is at bottom an economic problem. The job of the defender is to asymmetrically raise costs for attackers. Look at how DNS zones and certificates are hijacked today. You are proposing to drastically raise defender costs in a way that doesn't significantly alter attacker costs, because they aren't in the main using the exotic attack you're fixated on. If we really wanted to address this particular attack vector in a decisive way, we'd move away, at the CA level, from relying on the DNS protocol browsers use to look up hostnames altogether, and replace it with direct attestation from registrars, which could be made _arbitrarily_ secure without the weird gesticulations DNSSEC makes to simultaneously serve mass lookups from browsers and this CA use case. But this isn't about real threat models. It's about a tiny minority of technologists having a parasocial relationship with an obsolete protocol.
- xorcist 1y agoIt does certainly make it easier. Sure, we can survive without it, but cryptographic signing of dns records is useful for a number of things.
- tptacek 1y agoCounterpoint: no it isn't, which is why virtually nobody uses it. Even the attack this thread centers on --- BGP hijacking of targeted DNSSEC servers to spoof CA signatures --- is a rounding error sidenote compared to the way DNS zones actually get hijacked in practice (ATO attacks against DNS providers). If people were serious about this, they'd start by demanding that every DNS provider accept U2F and/or Passkeys, rather than the halfhearted TOTP many of them do right now. But it's not serious; it's just motivated reasoning in defense of DNSSEC, which some people have a weird stake in keeping alive.
- iscoelho 1y agoYou are again ignoring the fact that DNSSEC would have prevented a $152,000 hack. Yes, we are aware organizations are not always serious about security. For those that are though, DNSSEC is a helpful tool.
- tptacek 1y agoNo, it isn't. It attempts and mostly fails to address one ultra-exotic attack, at absolutely enormous expense, principally because the Internet standards community is so path-dependent they can't take a bad cryptosystem designed in the mid-1990s back to the drawing board. You can't just name call your way to getting this protocol adopted; people have been trying to do that for years, and the net result is that North American adoption fell. The companies you're deriding as unserious about security in general spend drastically more on security than the companies that have adopted it. No part of your argument holds up.
- iscoelho 1y ago"at absolutely enormous expense" Citation? A BGP hijack can be done for less than $100. "You can't just name call your way to getting this protocol adopted" I do not care if you adopt this protocol. I care that you accurately inform others of the documented risks of not adopting DNSSEC. There are organizations that can tolerate the risk. There are also organizations that are unaware because they are not accurately informed (due to individuals like yourself), and it is not covered by their security audits. That is unfortunate.
- baobun 1y agoDNS can be used for non-IP lookups. TXT records and whatnot.
- phillipseamore 1y agoAnd at least Let's encrypt actually verifies DNSSEC before issuing certificates. IIRC it will become mandatory for all CA's soon. DNSSEC for a domain plus restrictive CAA rules should ensure that no reputable CA would issue a rogue cert.
- marcusb 1y agoThey do validate signed zones -- that is true. How do they run their own zones? $ dig +short letsencrypt.org DS $
- tptacek 1y agoIt absolutely will not. Most domains aren't hijacked by spoofing the DNS to begin with.
- iscoelho 1y ago"Most domains". Yes, it is possible that nobody bothers to DNS hijack your domains. Sadly I've worked for organizations where it did happen, and now they have DNSSEC.
- tptacek 1y agoI invite anybody who thinks this is a mic drop to pull down the Tranco research list of most popular/important domains on the Internet --- it's just a text file of zones, one per line --- and write the trivial bash `for` loop to `dig +short ds` each of those zones and count how many have DNSSEC. For starters you could try `dig +short ds google.com`. It'll give you a flavor of what to expect.
- daneel_w 1y agoAnd you still can't seem to make your mind up on whether this is because DNSSEC is still in its infancy or if it's because they all somehow already studied DNSSEC and ended up with the exact same opinion as you. I'm gonna go out on a limb and say that it's not the latter.
- zahllos 1y agoThe argument counter dnssec is that if you are trying to find some random A record for a server, to know if it is the right one, TLS does that fine provided you reasonably trust domain control validation works i.e. CAs see authentic DNS. An argument for DNSSEC is any service configured by SRV records. It might be totally legitimate for the srv record of some thing or other to point to an A record in a totally different zone. From a TLS perspective you can't tell, because the delegation happened by SRV records and you only know if that is authentic if you either have a signed record, or a direct encrypted connection to the authoritative server (the TLS connection to evil.service.example would be valid). So it depends what you expect out of DNS.
- iscoelho 1y agoTLS doesn't provide any security in this case because TLS certificates are generated based on DNS. See Lets Encrypt.
- acdha 1y agoIsn’t this why validation is done from multiple locations on different networks? That blocked the 2018 attack and RPKI has made it even harder since.
- iscoelho 1y agoYes but it is still possible to execute BGP hijacks that capture 100% of traffic, rendering multi-perspective validation useless. RPKI sadly only solves naive "accidental" BGP hijacks, not malicious BGP hijacks. That's a different discussion though.
- zahllos 1y agoI agree and apparently so does the CA/B forum: SC085: Require DNSSEC for CAA and DCV Lookups is currently in intellectual property review. DCV is CA/B speak for domain-control validation; CAA = these are my approved CAs. This seems to be optional in the sense that: if a DNS zone has DNSSEC, then validation must succeed. But if DNSSEC is not configured it is not required.
- muppetman 1y agoDNSSec has caused so many outages at this point it's a joke. You have to be so insanely careful and plan everything to the nth degree otherwise you break everything: https://internetnz.nz/news-and-articles/dnssec-chain-validation-issue-technical-incident-report/ https://internetnz.nz/news-and-articles/dnssec-chain-validat... The idea is important. What it aims to protect is important. The current implementation is horrible, far too complex and fraught with so many landminds that no one wants to touch it. If Geoff Huston is suggesting it might be time to stick a fork in DNSSec because it's done, then IMHO it's well cooked. https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/ https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/
- iscoelho 1y agoYeah I'm by no means saying the implementation is good. RPKI is a joke as well in my opinion. But it's all we have right now. I am saying it is dishonest to discount the real security threat of not having DNSSEC.
- muppetman 1y agoRight OK, I fully agree with you then.
- tptacek 1y agoWhat parts do you agree about? Someone making an argument that we should return to the drawing board and come up with a new protocol, one that doesn't make the "offline signers and authenticated denial" tradeoffs DNSSEC makes, would probably be saying something everybody here agrees with --- though I still don't think it would be one of the 5 most important security things to work on. But the person you're replying to believes we should hasten deployment of DNSSEC, the protocol we have now.
- iscoelho 1y agoI would love to go to back to the drawing board and solve the security pitfalls in BGP & DNS. I wish the organizations and committees involved did a better job back then. Sadly, we live in this reality for now, so we do what we can with what we have. We have DNSSEC.
- deleted 1y ago[deleted]
- burnt-resistor 1y agoRelated: - ECC vs. non-ECC memory and bitsquatting when people said "oh, it doesn't matter and it's too expensive for no benefit." - http:// http:// was, for years, normalized pre-PRISM. - Unsecured DNS over 53/tcp+udp (vs. DoH today) is a huge spoofing and metadata collection threat surface.
- rsync 1y ago"Unsecured DNS over 53/tcp+udp (vs. DoH today) is a huge spoofing and metadata collection threat surface" Genuinely curious: What actor, in 2025, would exist in your threat model for DoH ... but wouldn't simultaneously be sniffing SNI ? I can't think of any. I cannot think of any good reason to be serious about DoH and DNS leakage in the presence of unencrypted SNI. What am I missing ?
- iscoelho 1y agoNot saying they are malicious actors, but easy answer would be any Public WiFi anywhere. They all intercept DNS, less than 1% intercept SNI. It is also public knowledge that certain ISPs (including Xfinity) sniff and log all DNS queries, even to other DNS servers. TLS SNI is less common, although it may be more widespread now, I haven't kept up with the times.
- growse 1y agoIsn't the vast majority of TLS connections using SNI today?
- iscoelho 1y agoYes TLS SNI is ubiquitous. I am referring specifically to TLS SNI metadata collection.
- 1vuio0pswjnm7 1y agoPopular web browsers send SNI by default regardless of whether it is actually needed. For example, HTTPS-enabled websites not hosted at a CDNs may have no need for SNI. But popular web browsers will send it anyway.
- nine_k 1y agoThere are two things mixed up. "We need secure DNS" != "we need DNSSEC". There is a huge demand for securing DNS-related things, but DNSSEC seems to be a poor answer. DoH is a somehow better answer, with any shortcomings it may have, and it's widely deployed. I suspect that a contraption that would wrap the existing DNS protocol into TLS in a way that would be trivial to put in front of an existing DNS server and an existing DNS client (like TLS was trivial to put in front of an HTTP server), might be a runaway success. A solution that wins is a solution which is damn easy to deploy, and not easy to screw up. DNSSEC is not it, alas.
- TZubiri 1y agoDoH is like VPNs, used by paranoids and criminals
- iscoelho 1y agoDoH does not solve anything that DNSSEC solves. They have almost no overlap.
- ClumsyPilot 1y agoBut TLS relies on having a domain If domain intern depends on tls you have chicken and egg problem
- nine_k 1y agoTLS internally does not depend on a domain in the DNS sense, it basically certifies a chain of signatures bound to a name. That chain can be verified, starting from the root servers. The problem is more in the fact that TLS assumes creation of a long-living connection with an ephemeral key pair, while DNS is usually a one-shot interaction. Encrypting DNS would require caching of such key pairs for some time, and refreshing them regularly but not too often. Same for querying and verifying certificates.
- mike_d 1y ago> It is important. This is unfortunate rhetoric that is harming the safety of the internet. DNSSEC was built for exactly one use case: we have to put root/TLD authoritative servers in non-Western countries. It is simply a method for attesting that a mirror of a DNS server is serving what the zone author intended. What people actually want and need is transport security. DNSCrypt solved this problem, but people were bamboozled by DNSSEC. Later people realized what they wanted was transport security and DoH and friends came into fashion.
- iscoelho 1y agoDNSSEC is about authentication & integrity. DNSCRYPT/DOH is about privacy. They solve completely different problems and have nothing to do with one another. There is also no reason we can't have both.
- tptacek 1y agoIf you have secure channels from recursers all the way back to authority servers (you don't, but you could) then in fact DoH-like protocols do address most of the problems --- which I contend are pretty marginal, but whatever --- that DNSSEC solves.
- iscoelho 1y agoYessir, that isn't possible yet but it would absolutely be a solution! I'd love to see it.
- tptacek 1y agoWhat's more, it's a software-only infrastructure upgrade: it wouldn't, in the simplest base case, require zone owners to reconfigure their zones, the way DNSSEC does. It doesn't require policy decisionmaking. DNS infrastructure operators could just enable it, and it would work --- unlike DNSSEC. (Actually getting it to work reliably without downgrade attacks would be more work, but notably, that's work DNSSEC would have had to do too --- precisely the work that caused DANE-stapling to founder in tls-wg.)
- acdha 1y agoThat quote is interesting because all of the period reporting I’ve seen says that the attackers did NOT successfully get an HTTPS certificate and the only people affected were those who ignored their browsers’ warnings. https://doublepulsar.com/hijack-of-amazons-internet-domain-service-used-to-reroute-web-traffic-for-two-hours-unnoticed-3a6f0dda6a6f https://doublepulsar.com/hijack-of-amazons-internet-domain-s... https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
- iscoelho 1y agoHow about another incident in 2022? Attackers BGP hijacked a dependency hosting a JS file, generated a rogue TLS certificate, and stole $2 million. Keep in mind: these are incidents we know about, not including incidents that went undetected. https://blog.citp.princeton.edu/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/ https://blog.citp.princeton.edu/2022/03/09/attackers-exploit... Noteworthy: "Additionally, some BGP attacks can still fool all of a CA’s vantage points. To reduce the impact of BGP attacks, we need security improvements in the routing infrastructure as well. In the short term, deployed routing technologies like the Resource Public Key Infrastructure (RPKI) could significantly limit the spread of BGP attacks and make them much less likely to be successful. ... In the long run, we need a much more secure underlying routing layer for the Internet."
- tptacek 1y agoYou know why I'm not coming back at you with links about registrar ATOs? Because they're so common that nobody writes research reports about them. I remember after Laurent Joncheray wrote his paper about off-path TCP hijacking back in 1995; for awhile, you'd have thought the whole Internet was going to fall to off-path TCP hijacking. (It did not.)
- jcranmer 1y agoI'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously. You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. You then use that specific control to get a CA to forge a certificate for you (and if the CA is capable of using any information to detect that this might be a forgery, the attack breaks). And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking--impersonating somebody to the nameserver and getting the account switched over to them.
- iscoelho 1y ago> I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously. You claim it is fine-tuned, but it has happened in the real world. It is actually even better for attackers that it is "obscure", because that means it is harder to detect. > but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. Yes, all layers of the stack need to be secure. I am not making assumptions about the other layers - this thread is about DNS. > if the CA is capable of using any information to detect that this might be a forgery They are not. The only mitigation is "multi-perspective validation", which only addresses a subset of this attack. > And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking Yes, because other kinds of DNS hijacking are solved by HTTPS TLS. If TLS and CAs are broken, nothing is secure.
- dwattttt 1y ago> You claim it is fine-tuned, but it has happened in the real world. Sure, but it seems like his comment is still responsive; if DNSSEC is deployed, they perform a BGP hijack & can impersonate everyone, and they just impersonate the server after the DNS step? If that's the threat model you want to mitigate, it seems like DNSSEC won't address it.
- iscoelho 1y ago
- deleted 1y ago[deleted]
- kbolino 1y agoIf the threat model is BGP hijacking, is DNSSEC actually the answer? If you can hijack a leaf server, can't you hijack a root server? As far as I can tell, the root of DNSSEC trust starts with DNSKEY records for the "." zone that are rotated quarterly. This means every DNSSEC-validating resolver has to fetch updates to those records periodically, and if I can hijack even one route to one of the fixed anycast IPs of [a-m].root-servers.net then I can start poisoning the entire DNSSEC trust hierarchy for some clients, no? Now, this kind of attack would likely be more visible and thus detected sooner than one targeted at a specific site, and just because there is a threat like this doesn't mean other threats should be ignored or downplayed. But it seems to me that BGP security needs to be tackled in its own right, and DNSSEC would just be a leaky band-aid for that much bigger issue.
- tptacek 1y agoThe much-more-important problem is that the most important zones on the Internet are, in the DNSSEC PKI, irrevocably coupled to zones owned by governments that actively manipulate the DNS to achieve policy ends. This is a problem with TLS too, of course, because of domain validation. But the WebPKI responded to that problem with Certificate Transparency, so you can detect and revoke misissued certificates. Not only does nothing like that exist for the DNS, nothing like it will exist for the DNS. How I know that is, Google and Mozilla had to stretch the bounds of antitrust law to force CAs to publish on CT logs. No such market force exists to force DNS TLD operators to do anything. My (ahem) "advocacy" against DNSSEC is understandably annoying, but it really is the case that every corner of this system you look around, there's some new goblin. It's just bad.
- iscoelho 1y agoI agree that the problem lies with BGP and we definitely need a solution. You can also say the problem is with TLS CA verification not being built on a solid foundation. Even with that said, solving those problems will take time, and DNSSEC is a valid precaution for today.
- throwaway313313 1y agoRPKI plus ASPA does solve the hijack problem by securing both the origin of a prefix and the AS path of a route. Yes ASPA is new. Reference implementations in open source routing daemons and RPKI tools are being developed and rolled out. If you want to be a pioneer you can run a bird routing daemon and secure the routes with ASPA. Only experimenters have created ASPA records at this point, however once upon a time we were in the same position with RPKI.