The .zip domains are a good idea

Google should be praised for doing this.

Today, the cybersec community erupted in outrage over Google offering domain names ending in .zip, like financialstatement.zip. It’s a security problem because it looks like a filename (the classic ZIP archive), but it’s actually a domain-name. It’ll undoubtedly enable some attacks, like more ways to phish victims. For defenders, you should absolutely block any .zip domain name where you can, like filtering email messages or black-holing DNS requests.

The downsides are obvious. The upsides less so.

The problem with things like phishing is that we are willing to limp along with only partial security. It’s a constant source of problems, but things just aren’t painful enough to actually fix them.

Sometimes the answer is to ratchet up the pain.

An example of this was sidejacking in 2007. Back in those days, we used SSL to protect login forms, so hackers couldn’t steal passwords. But the rest of the session proceeded with HTTP, unencrypted, and eavesdroppable. A cookie set under SSL was used to track the session without SSL.

I wrote an easy tool to capture those cookies, insert into my own browser, and “sidejack” the connection. The demo at BlackHat in 2007 worked really well, sidejacking a GMail session of a random audience member logged in via WiFi.

My tool was easy for techies, but somebody made it even easier to use by non-techies with a tool called Firesheep. Suddenly everyone’s email accounts were getting sidejacked, such as movie stars. People would sit in Starbucks and grab everything, causing havoc. Kids in high school in 2008 sidejacked the heck out of people.

Because this had become so intolerable and painful, all the major websites switched to SSL all the time. Even the most trivial of webpages by major websites would be SSL encrypted.

It’s not the only reason. This was also around the time where hardware became efficient enough. Also, LetsEncrypt deserves credit for being a part of the solution (rather than me being part of the problem), solving the high cost of SSL certificates. But still, making the problem intolerable forced the solution.

Today, we have lots of solutions to the phishing problem, such as DMARC for validating emails. But they aren’t used as much as they could be because it’s more important for good emails to get through than blocking bad emails. The solution causes problems for good emails only because they aren’t more widely used. So we have a chicken-and-egg problem: to make them more reliable, they have to be used more, but they aren’t used more, because they aren’t reliable.

The same is true of other issues due to the “type-confusion” between filenames and domain-names. We don’t use protections enough because they interfere with good things, but wouldn’t interfere with good things if we used them constantly.

By offering .zip domains, Google changes the status quo. In the near term, this will probably mean talks at DEFCON/BlackHat as we find creative ways of exploiting this. But in the long run, people won’t tolerate a worse situation, and do more to fix it. While in the next year we’ll be worse off, in five years we’ll almost certainly be better off.

It’s pretty much the same throughout cybersecurity. The status quo limps along with being simply tolerable. Changes to the status quo leads to improvements. It could be anything. Take Mirai from 2017. There hasn’t been a repeat because the status quo became intolerable, and the major issues have been fixed that led to Mirai.

Or we could all be wrong and it won’t actually change the status quo, in which case this entire debate is a bunch of hot air.