Huh? I'm talking about certificate issuance and domain ownership here. If a CA can't verify the domain with the registrar then they fail to issue a certificate, it's as simple as that. It's not like they can get a forged response over HTTPS...
What? How? Did you read my comment at all? I was saying the CA needs to have a way to verify ownership with the domain registrar. Over HTTPS, obviously. An attacker can't forget a response, so the worst case is the cert doesn't get issued, which it very much shouldn't be if ownership cannot be verified.
If you control BGP, you can thwart DV checks and get a certificate issued. You can do that without touching the DNS at all.
How can you not tell? I was extremely explicit that this was the former in the very first sentence of my initial comment:
>>>>>> Taking a step back here... ___shouldn't___ proving ownership of a domain involve the domain registrar some way, rather than involving whoever happens to host your DNS?
This isn't something I was aware of, and I'm not having much luck in finding out the implementation details.
I can imagine a zillion different approaches... most obvious (not necessarily the best) one being to ask an IANA server over a normal TLS connection whether it should expect a TLD's records to be signed. And you can obviously cache that response for a while.
Remember the point here is to validate domain ownership, which everybody already understands to be a big deal. If you can't get any trustable response from anybody, then I would expect it is your duty to refrain from issuing a certificate for that domain.
But the larger issue is that there is no global integrated WHOIS system – e.g. to view a WHOIS record for a .de currently you need to solve a captcha and provide a valid reason (and can’t do it automated).
DENIC has been compliant with the GDPR for months already, and its WHOIS database is still running – you just can’t expose all fields of the WHOIS to any unauthenticated viewer.
Not to mention that, more practically there's no need (and potentially possible harm) to tie the ownership records to a particular cipher. Really, it's the registrar's job to deal with domain ownership; ideally it shouldn't involve you at all. And as a near-corollary, they could probably deal with long-term key security better than the average domain owner.
Really? In your mental model is (or should be) every domain owner overflowing with money?
A single static landing page would be expected to have at least traffic tracking, at least for the sake of load-balancing.
Even if the page is that - just a static page, the chance it's hosted by the content owner themselves is becoming smaller every day.
So frankly - yes. I believe today is the right time to start adding/replacing layers in the stack. After all - we've gone a long way in terms of software deployment tools so it's way more interchangeable.
1. I would get a proper SSL cert signed
2. Only hijack one of the ranges, and do not respond to other domains (causing SERVFAIL), so other domains will resolve unaffected, instead of causing a scene (see: https://www.reddit.com/r/sysadmin/comments/8ejrkk/google_dns...)
Uh, how? Are you assuming that a single BGP leak would be enough to cause e.g. a letsencrypt misissuance for the domain? It sounds like (from other comments) they have a global round-robin resolver setup for their DNS challenges.
> 2. Only hijack one of the ranges, and do not respond to other domains (causing SERVFAIL), so other domains will resolve unaffected
I think exactly that's what they did. I saw people posting SERVFAILs during the outage.
Author is suggesting they should be properly resolving the rest of the domains so they wouldn't cause SERVFAILs.
no they don't
On DNS, you can use DNSSEC to sign your records. The IPs returned by the fake DNS would not have been signed as they do not have the private keys.
Would this have helped though? The attacker's DNS resolver could just return records without DNSSEC.
In this instance, had myetherwallet.com been signed, and had a user been using a DNSSEC validating resolver, they would not have visited the invalid site. The attacker's DNS responses would not have validated.
Had myetherwallet.com been DNSSEC signed anyone using Google's public DNS resolver at 18.104.22.168 would not have visited the invalid site.
In the legitimate world, this usually means you global anycast your DNS servers, which then respond to queries with IP addresses of load balancers that are only announcing from one location, out multiple providers.
I think this maybe could be extrapolated to a BGP attack of this nature and could explain why the attacker, in this case, focused on attacking the DNS server rather than a different piece of the stack.
I'm guessing that your global anycast setup in the legitimate world is going to be way more reliable and flap a lot less than whatever the attacker can cobble together out of upstreams with inadequate prefix filtering.
Note, I'm not trying to claim that the attacker couldn't take over the end machines that serve longer TCP streams; I'm just pointing out that the attacker has good reason to attack DNS first if possible, for the same reasons as the legitimate operators have for using global anycast for DNS and not for HTTP.
(as further trivia, I have seen setups where the http server was global anycast, but that webserver only returned really short responses, 3xx redirects, again redirecting the request to a non-anycast webserver.)
DNS resolves myetherwallet.com to 22.214.171.124. This is valid & signed. Your browser does a request to 126.96.36.199. Attacker need not interfere with DNS.
Thanks to the BGP leak the attacker controls 188.8.131.52. The request is still going to him.
So, I think it was a rational choice.
The problem is that when you can hijack the routing for an IP there's nothing that can realistically be done with how the internet works today to protect again it. Basically every system of validation requires you have access to some outside authority that can verify authenticity, and if you can announce the route to those IPs to your own infrastructure, you can fool the validation.
It fails to solve the issue if the dns resolver doesn't check DNSSEC signatures though.
If they managed to hijack the route to the server itself, there's no need to hijack DNS at all, so it's a different issue that can't be solved at DNS level itself as DNS is not involved in the attack
The potential downside there is the specificity - last I checked, the internet routing table won't take anything more specific than a /24 - so if you can't provide a more specific route, as-path-length becomes the next determining factor, so you might be in a situation where you can announce the DNS cidr with more specificity and not whatever IP is in the A record... But that's pretty far outside of your control and could just as easily flip the other way.
All of this is to say: I think the important part of this whole thing was the BGP hijack, and not necessarily the lower level specifics, because the hijack isn't dependent on a lot of those specifics.
(although they would likly not get all the hashing power because not everyone is taking that route.)
BGPsec would solve this issue, but is currently not deployed at all (and won't be before a long time).
And probably nobody will be hold responsible for this other than hacker.
Thats why noone in this chain will have any incentive to fix this ever occuring again.
Curious what stopped cloudfare from naming these providers.
I am not advocating "blockchain for every problem", but name resolution is a good fit - if only there were blockchains in the 80s. there are already implementations: https://email@example.com/ethdns-an-ethereum-backend-f...
And what percentage of domains use "blockchain"?
But yeah, there's still the trailing sequence and companies that don't understand how simple that is.
You mean superkuhbit6g4tf.onion. Although longer Tor based address hashes are coming soon for better security (https://blog.torproject.org/tors-fall-harvest-next-generatio...) so the trailing length of random chars will be even longer. Kind of mitigates my objection.
Still, Tor hidden services come with DoS/DDoS protection built in as well. Something Cloudflare and it's centralized service doesn't like to acknowledge.
Incorrect. We do not block Tor users by default and we massively changed our handling of Tor a very long time ago.