[LinuxBender]

If you control the root DNS servers for .io, you can simply not answer the DNSSEC queries. Many resolvers will fail open.

HSTS requires the site is HTTPS with a valid cert. If you own all .io, you can use LetsEncrypt to get that for free. They now even support Wildcard Certs! :-) That said, you would have to choose your targets carefully and/or load balance your requests to LetsEncrypt. There is a rate limit. There are browser plugins that can tell you if a cert just changed, assuming you have been to that site prior.

Then there is Public Key Pinning. This would be great, but I suspect the number of big companies implementing this are low. I don't have numbers, but you can test your favorite sites in Qualys[1] or using testssl.sh[2] that only depends on openssl and bash.

You could proxy all requests to the real root servers for .io and only become authoritative for the ones you wish to target.

Given the small number of zones, I think a modest server could keep up, or you could balance the load on a bunch of VM's. It may take a while for anyone to notice. I am curious actually, how many fellow geeks have nagios/sensu alerts that would tell them if the root server IP's changed.

All of this said, there are BGP attacks you can do that accomplish the same thing for any TLD and the IP's wouldn't even have to change. Only more advanced monitoring tools that keep an eye on route path might notice, but probably would not alert anyone.

[1] https://www.ssllabs.com/ssltest/index.html [2] https://github.com/drwetter/testssl.sh

[ConfucianNardin]

LetsEncrypt don't support wildcards yet. They will, starting January next year.

[LinuxBender]

Ah, I was not aware it would be January. Then for now the targets would have to be specific DNS records.

[jancsika]

So how does certificate transparency fit into all this?

https://www.certificate-transparency.org/what-is-ct

Let's assume an attacker who selectively hijacks .io traffic in such a magical* way that the owners of the relevant domain names do not notice the attack is happening. Assuming that, what exactly would the CT monitors notice? I assume there would be new LetsEncrypt certificates entered into the append-only log, but then what?

Edit: added word magical for clarity

[LinuxBender]

That could certainly be useful in the follow-up investigation and forensics. Hopefully our attacker did not spin up those VM's using a burner card or stolen CC and proxies.

There isn't anything magical about selectively targeting domains. One simply creates multiple recursors and sets the upstream forwarder to the proper IP's of the original root servers. Then one adds zones for the domains or individual records they wish to modify. Unbound DNS is great for taking over individual records. I use it for this very purpose to block advertisements and trackers. In this case however, we are just acting as a root server, so there isn't much to take over. We just point the victims to ourselves for the domains we wish to hijack. We could then have a second level of recursors to perform the above selective attacks.

[michaelmior]

I think the problem with PKP is that there's such a big risk of temporarily unfixable breakage if things aren't done right.

[pingiun]

Could you get a wildcard certificate for *.io this way?

[LinuxBender]

I don't know if LetsEncrypt would issue that, even if you control it. That would be a good exercise to validate if there is an "easy mode" for state sponsored fun.

I've read that browsers are said to block such wildcards, but I don't know to what they are referring. I create wildcard TLD self signed certs all the time. I've never had one signed by a proper CA, so I can't tell you if the browsers have any logic to ignore them.