In 2012, ICANN opened applications for hundreds of new top-level domains, and the first appeared in 2013. Names ending in .shop, .blog, .app and thousands of others became possible, though .com kept its pull.
In April 2014, Heartbleed, a flaw in a widely used encryption library, let attackers read memory from affected servers. Operators around the world patched and reissued certificates in a scramble. The incident drew attention to how much of the internet depended on a few under-funded open source projects.
The two stories have little in common on the surface, one about branding and one about a missing length check. Both landed on hosting support desks within the same two years, and both produced a lot of customers asking whether they needed to do something.
Opening the namespace
Until 2012 the list of top-level domains was short and slow to change: .com, .net, .org, a few others, and the two-letter country codes. ICANN's new generic TLD programme invited organisations to apply to run their own extension, for a large fee. Applications closed after a long window with close to two thousand submitted, and some were for company names, not generic words.
The first new names began appearing in the root in late 2013, and registrations for ordinary words such as .guru and .bike opened to the public in early 2014. Each new registry ran its own launch: a sunrise period for trademark holders, then an early-access stage at higher prices, then general availability.
For a hosting company this meant a steady stream of small chores. Registrar systems had to support hundreds of new extensions, each with its own rules about who could register and what contact data was needed. Some were restricted, some had unusual renewal prices, and a few shut down or changed hands later.
Did the new endings win?
Mostly, no, if you measure by what ordinary people type. .com stayed the default in memory, in advertising and in the address bars of people who would not think to try anything else. Many new names were bought defensively, so that nobody else could register them, and left without a website.
Where they did work, they tended to work for a specific audience: a technology company on a short, descriptive name, a local business on a city extension, a developer on a name that read as a sentence. The pattern we saw was that a new extension suited a project with a clear identity and a marketing budget to explain it.
What Heartbleed was
Heartbleed was a bug in OpenSSL, the library behind a very large share of HTTPS servers. It sat in the heartbeat extension of TLS, a small feature designed to check that the other end of a connection is still there. A client sends a short payload and says how long it is; the server echoes it back.
The flaw was that OpenSSL did not check the claimed length against the real length of the payload. A client could send one byte, claim it was sixty-four thousand, and the server would reply with the byte plus whatever happened to sit next to it in memory, up to around 64 KB at a time. Do that repeatedly and you collect fragments of the server's working memory.
The scramble
The bug was made public on 7 April 2014, alongside a fixed OpenSSL release. Versions from 1.0.1 up to 1.0.1f were affected; 1.0.1g closed the hole. Patching the library was the easy part. The hard question was what might already have leaked, because the memory could contain session cookies, passwords in transit and, worst of all, the server's private key.
A sound response therefore had several steps in order. Anyone who skipped the first two would leak the new secrets as well.
- Update OpenSSL and restart every service that links to it.
- Generate a new private key. Do not reuse the old one.
- Have the certificate reissued against the new key, and revoke the old certificate.
- Force logouts and prompt users to change passwords.
Revocation turned out to be patchy in practice, since many browsers did not check it reliably, and that fed a long argument about how revocation ought to work.
The lesson about dependencies
The uncomfortable fact behind Heartbleed was how little support OpenSSL had. It was maintained by a very small team, a few of whom were paid, and it underpinned commerce, banking and government sites. Soon afterwards the Linux Foundation launched the Core Infrastructure Initiative, with industry funding, to support projects of this kind.
For site owners the practical takeaway was dull but real: know what your server runs, keep it patched, and prefer a host that tells you when a library vulnerability affects you. If you want to confirm what a server is presenting today, openssl s_client -connect example.com:443 shows the chain and the expiry, and the SSL expiry tool will watch the date for you.