Possible security disasters loom with rollout of new top-level domains

Potential for malicious abuse of new TLDs is "extraordinary," PayPal exec warns.

Plans to populate the Internet with dozens of new top-level domains in the next year could give criminals an easy way to bypass encryption protections safeguarding corporate e-mail servers and company intranets, officials from PayPal and a group of certificate authorities are warning.

The introduction of Internet addresses with suffixes such as ".corp", ".bank", and ".ads" are particularly alarming to these officials because many large and medium-sized businesses use those strings to name machines inside their networks. If the names become available as top-level domains to route traffic over the Internet, private digital certificates that previously worked only over internal networks could potentially be used as a sort of skeleton key that would unlock communications for huge numbers of public addresses.

A secure sockets layer certificate used by employees to access a company intranet designated as ".corp", for instance, might be able to spoof a public credential for the website McDonands.corp or Ford.corp. Employee laptops that are used at an Internet cafe or other location outside of a corporate network might also be tricked into divulging private information.

"If the appropriate service endpoints are available, these clients will next begin to dump confidential data and potentially pull incorrect information and apply damaging state changes," PayPal Information Risk Management officials Brad Hill and Bill Smith wrote in recently published letter to Fadi Chehade and Stephen D. Crocker, the chief executive and chairman respectively of the Internet Corporation for Assigned Names and Numbers (ICANN). "The potential for malicious abuse is extraordinary, the incidental damage will be large even in the absence of malicious intent, and such services will become immediate targets of attack as they inadvertently collect high-value credentials and private data from potentially millions of systems."

The security concerns come in response to ICANN's plans to create a variety of new top-level domains by the end of this year to bolster currently available suffixes such as ".com", ".net", and ".biz". Last week, VeriSign also sharply criticized the plan, saying the speed at which ICANN was moving threatened the stability of the Internet address system.

A report recently published by ICANN's Security and Stability Advisory Committee provides support for the security concerns, which in addition to PayPal are being voiced by members of a group of certificate authorities. Citing data assembled three years ago by the Electronic Frontier Foundation's SSL observatory, the report said there were 1,053 certificates signed by recognized authorities that end in 63 strings which are candidates to become top-level domains. Such a scenario might make it possible for "man-in-the-middle" attackers, who control a connection between a website and end users, to spoof traffic in a way that would completely bypass encryption protections provided by SSL.

"If an attacker obtains a certificate before the new TLD is delegated, he/she could surreptitiously redirect a user from the original site to the attacker site, present his certificate, and the victim would get the Transport Layer Security/SSL (TLS/SSL) lock icon," the ICANN report stated. "This poses a significant risk to the privacy and integrity of HTTPS communications as well as other protocols that use X.509 certificates (e.g. TLS/SSL-based e-mail communication)."

The report went on to say that the number of "short name" certificates that could collide with the new domains is almost certainly much higher. That's because the SSL Observatory only scanned for certificates publicly advertised on the Internet. That leaves most private certificates unaccounted for. Another reason the SSL Observatory is likely understating the problem is that it probably doesn't scan many ports used by e-mail servers.

ICANN officials didn't respond to an e-mail seeking comment for this article.

Averting disaster

Security experts have been pondering such possibilities for a couple years now. As a result, they have devised several ways to avert the worst of the disasters. Specifically, the CA Browser forum, made up of many of the Internet's certificate authorities and browser developers, is telling members to stop issuing "internal name" certificates by October 2015 and to revoke any such valid certificates by October 2016.

Ryan Hurst, CTO of GlobalSign and a participant in the CAB Forum, told Ars the group has also mandated the revocation of any certificates that contain short names that are later designated by ICANN as a top-level domain. CAB Forum members are required to perform the revocations within 120 days. Since it probably takes three or more months for a generic TLD to become operational, that should buy authorities time to revoke any potentially dangerous certificates, but some security experts remain uncomfortable. They warn there is little margin for error, and that the system depends on the willingness of members to comply.

"The primary concern is the speed at which these new gTLDs are going to be adopted by ICANN without giving enough consideration to the potential impact on security and established networks," Jeremy Rowley, the associate general counsel for certificate authority DigiCert, told Ars. "I don't think they have an accurate understanding of the number of internal server names [and] internal networks that are out there and the number of certificates that have been issued to those networks."

Hurst and Rowley, who are both members of the recently formed CA Security Council, also warned that the CAB forum mandates aren't binding on CAs who aren't members, so there's no guaranty the requirements will be followed universally.

Collisions between internally used SSL certificates are only one of many potential risks that stem from the planned expansion. The introduction of domains such as "domain", "localhost", "home", or "belkin" could also cause significant disruption since an untold number of networks use these names to route traffic to computers, servers, and embedded devices internally. Network engineers and Internet policy makers have been aware of these dangers for years. With the rollout of new domains rapidly approaching, security experts said they need more time.

"We're trying to find a find balance between: 'I'm sorry, guys, your network no longer works the way it's worked for the last 20 years,' and this requirement, and we're trying to do it as quickly as possible," Hurst said. "A lot of times this requires ordering new hardware for these guys, hiring consultants to help them plan their directories, and this is not something they do easily."

59 Reader Comments

What are the new top level domains being rolled out? The ICANN webpage points to this list:https://gtldresult.icann.org/applicatio ... tionstatusAnd implies the IE Result: Pass column indicates the TLD is ready to go. But almost all of the domains with IE Result:Pass are in Chinese or Japanese characters.

Most of the corporate domains I encounter use the ".local" pseudo-TLD. When I first ran into it years ago, I thought it was strange, but of course now it will (probably) reduce problems. Unless they issue a real ".local.", that is.

I don't know who is more "at fault" here, the companies that set up certificates on fake domains or ICANN for knowing that companies do this and pushing ahead with this at this speed anyway.

I'm leaning towards the companies, just because they should have known that a new domain extension could potentially be added. Although, maybe not so much as ICANN has only started with the new TLDs recently and 20 years ago all there was for business was .com and nothing else.

It will be interesting to see who has more might here, the corporations or ICANN.

The problem with TLDs is that no one thinks of them as a domain of anything. To most people who use the internet, even comparatively tech-savvy people, TLDs don't mean anything. Sure they mean something to the architecture of the internet, but that is not reflected in how they are used most of the time, and the URL architecture doesn't make that clear unless you are familiar with the format.

Another concern here, in my opinion, might be the expense of new or replacement SSL certificates causing small businesses to do the self-signed cert thing. The risk there is in "training" users to click through the browser warnings; any modern browser will turn red in the face when presented with a cert that isn't signed by a large, trusted - and expensive - CA. Once that training takes hold, the risks expand significantly, as users start clicking through the warnings when they shouldn't. And not just for their employers' domains - maybe they start to think it's okay everywhere.

It's a matter of scale, perhaps; many organizations have their own CAs, and will have their CAs installed on all client machines (which they probably own and reimage on day one anyway), but only the larger ones with deeper pockets than the little guys.If all the network operator wants is end-to-end encryption for a very few trusted and savvy clients, maybe it works and becomes tempting. Beyond that, it's just bad idea, and the new TLDs may encourage it.

I really don't know how real or large an issue that could prove to be, but it comes to mind.

I don't know why Certificate Authorities are issuing signed certificates for private top level domains anyway.

Yes, I see why companies would want them to, because they don't want to go through the hassle of making each machine in the company have their own third party CA installed and trusted. But it's way too much power to issue a company a cert for their private network that any machine on anyone's network will trust.

Their proposed attack is something that's always been possible during a redirection attack (DNS spoofing for example). You take them to one website, have a quick JavaScript redirect to a Fakebank.com, or Fakebank.bank now, and use a cert issued to Fakebank. It's not incredibly hard to get a cert to your own domain.

And all I can imagine the "leaking information" by a machine in an Internet cafe can mean is that the laptop would be trying to establish a connection to a public site using the public key corresponding to the private certificate. Yes, it's not good to go around telling people more than they need to know, but it in no way compromises the security of the key.

The things that could be real potential problems are once the TLD gets pushed out malicious users grabbing the domains that are used internally in these large networks, and then getting certificates over them. Then you would have these computers on the network trusting certificates external to their private network. It would be trivial to host a spoofed server with complete certificate trust and an identical fully qualified domain name.

I never understood companies that did this in the first place. What is the big deal with paying the $9/year for a real FQDN to use for your domain? These fake domains have always been against best practices and now we are seeing one real-life reason why.

Things will really get interesting if they allow something like .local....

I've been thinking more about the potential for scams based on consumer confusion with the new TLD's, and hadn't considered the certificate problem. I guess the bright side is that fixing private certificates for businesses will be a lucrative new niche for IT service providers.

Most of the corporate domains I encounter use the ".local" pseudo-TLD. When I first ran into it years ago, I thought it was strange, but of course now it will (probably) reduce problems. Unless they issue a real ".local.", that is.

Surely they wouldn't be so stupid as to make .local available as a TLD... not to mention .localdomain and .localhost, and their variants...

The problem with TLDs is that no one thinks of them as a domain of anything. To most people who use the internet, even comparatively tech-savvy people, TLDs don't mean anything. Sure they mean something to the architecture of the internet, but that is not reflected in how they are used most of the time...

When they started giving away ".net" addresses to anyone who asked, regardless of their activity, and when local governments started using ".com" addresses, it was clear that TLDs were becoming meaningless.

The corruption (and thus elimination of relevance) of TLDs long ago passed the point of no return.

why not designate and reserve private TLDs (like .local) just like we do with IP addresses.

The number of available names is infinite, compared to the number of available IP addresses, particularly IPv4. If you didn't reserve a range of IPv4 addresses for private use, they'd all be gobbled up for public use. I guess everybody got comfortable with the old TLDs and assumed anything not already being used was fair game for private use.

Also, the type of attack mooted has surely been available anyway? If I have a private cert from Verisign for internalnetwork.corp, as an attacker all I need to do is go to another provider and get my own cert for internalnetwork.corp for "my" internal network, then I can use this to attack the first company? If you actually wanted to perform this type of attack you would be AGAINST the proposed change, because now to get your collision you'd have to publicly buy the address, rather than be able to do it privately, which would be a lot harder to trace. Thus you can argue that ICANN should do this to force these organisations to close a security loophole.

The same applies to running your own internal CA then you have to trust that no other CA in your trusted root list will issue a cert for the same domain, which if these large companies are providing private certs, you can't do, so you've still got the security hole.

This argument can apply to any new TLD. If there are common ones (.corp) then practical sense says don't issue those as real TLDs for the time being, but otherwise awareness that what people are doing is subverting the Certificate system is the only real cure.

In other news, corporations put their own wants in front of everyone else. While it is human nature to dodge change and to try to find the easy way out, guess what, you guys survived Y2K, you survived 2012, and you can handle this.

Who does this change benefit? Seriously, who?

It benefits only entities with very deep pockets (which can afford to buy the gTLD), while putting everyone else down a few notches. It provides no benefit for the Internet as a whole, and just creates quite a lot of confusion and opportunities for exploitation.

Every time I read a new article about these additional TLDs, the more I think to myself; "What the fuck is ICANN thinking?"

You should be asking "WTF are these companies thinking?" Using an unallocated TLD on an internal network makes no more sense than using unallocated public IP space. It's risky, just because it's not used right now doesn't mean it won't ever be. Although it would be nice if ICANN would just issue a permanent guarantee that the TLD's of "internal" and "local" never be issued.

"Intranets should never use TLD's" -no, you're wrong. Using network structure for networks is not a bad idea.

"ICANN should never expand TLD's" -also wrong. We need more human-readable namespace. That said, redundant TLD's probably don't do the job well. They just require people to register more domains to prevent domain-squatting and phishing.

Local-only TLD namespace should have existed from the start; then this outrage about companies wanting to use basic network structure for their networks would be warranted.

If anything, ICANN should have (and probably will yet) give a much longer warning period so intranets can adapt to the TLD changes, but holy crap reserved local-only TLD namespace needs to exist.

.local, .localhost and .domain have long been accepted generic TLDs for internal use so ICANN is unlikely to let them become delegated TLDs.

It's worth noting that .local. actually isn't safe for internal use, either-- it's reserved in RFC 6762 (Multicast DNS, aka Bonjour, Zeroconf, or Avahi) as the TLD for link-local domain names, and (in that spec) names in that space are supposed to be resolved through mDNS, not through traditional DNS.

This isn't a huge problem as long as you stay in the Windows world, but in a more heterogenous environment (containing Windows, Mac, and Linux machines) using the .local TLD for something it's not intended for can cause problems pretty quickly.

If you want an address space that's safe to use internally, register a public name and use it. Subdomains of a domain you control are guaranteed to remain unique and be safe to use.

I've been thinking more about the potential for scams based on consumer confusion with the new TLD's, and hadn't considered the certificate problem. I guess the bright side is that fixing private certificates for businesses will be a lucrative new niche for IT service providers.

Totally agree, my mind has been more on the social engineering aspect. This is especially true if they do go for the non-latin character gTLDs. Think about what yourbank.com would look like using graphically similar russian letters, or even mixed languages (i.e. only change the y to a ... well... y[russian]). Very few users would catch that. Perhaps a solution is for browsers to automatically reformat mixed language links to indicate that there may be an issue.

Hurst and Rowley, who are both members of the recently formed CA Security Council, also warned that the CAB forum mandates aren't binding on CAs who aren't members, so there's no guaranty the requirements will be followed universally.

I wouldn't usually be the one to bring this up, but that should be guarantee. This one really stuck out, to me.

.local, .localhost and .domain have long been accepted generic TLDs for internal use so ICANN is unlikely to let them become delegated TLDs.

It's worth noting that .local. actually isn't safe for internal use, either-- it's reserved in RFC 6762 (Multicast DNS, aka Bonjour, Zeroconf, or Avahi) as the TLD for link-local domain names, and (in that spec) names in that space are supposed to be resolved through mDNS, not through traditional DNS.

This isn't a huge problem as long as you stay in the Windows world, but in a more heterogenous environment (containing Windows, Mac, and Linux machines) using the .local TLD for something it's not intended for can cause problems pretty quickly.

If you want an address space that's safe to use internally, register a public name and use it. Subdomains of a domain you control are guaranteed to remain unique and be safe to use.

Like I said, I used to think it was strange. But here we are.

By the way, am I seeing that wrong, or is RFC 6762 proposed by Apple? Early this year? Suggesting a TLD that Microsoft has been faking into use for years?

And all I can imagine the "leaking information" by a machine in an Internet cafe can mean is that the laptop would be trying to establish a connection to a public site using the public key corresponding to the private certificate.

It's not the encryption itself, it's the data being carried in the connection. If the FBI routes calls to your drug dealer's phone to their own phone, they can hear your order for another hit when you call that number. By intercepting the endpoint, they don't have to care about any safeguard on the in-flight data.

So if you send secrets around in email because it 'never leaves the exchange server' and someone can get you to talk to their own Exchange server instead, your secrets are visible to them (but protected in transit). I would like to say that premise (emailing confidential stuff without further protection) is so dumb it would never happen, but I'm not a betting man.

.local, .localhost and .domain have long been accepted generic TLDs for internal use so ICANN is unlikely to let them become delegated TLDs.

It's worth noting that .local. actually isn't safe for internal use, either-- it's reserved in RFC 6762 (Multicast DNS, aka Bonjour, Zeroconf, or Avahi) as the TLD for link-local domain names, and (in that spec) names in that space are supposed to be resolved through mDNS, not through traditional DNS.

This isn't a huge problem as long as you stay in the Windows world, but in a more heterogenous environment (containing Windows, Mac, and Linux machines) using the .local TLD for something it's not intended for can cause problems pretty quickly.

If you want an address space that's safe to use internally, register a public name and use it. Subdomains of a domain you control are guaranteed to remain unique and be safe to use.

Like I said, I used to think it was strange. But here we are.

By the way, am I seeing that wrong, or is RFC 6762 proposed by Apple? Early this year? Suggesting a TLD that Microsoft has been faking into use for years?

Weird, again.

Yes, it's Apple's design, but no, it's not new: mDNS has been on the IETF standards track (with the reserved .local TLD) since 2002. The February 2013 document is just the latest evolution of the standard on its way to becoming an official IETF standard-- it has now moved from draft status into IETF's "proposed standard" state, which is the last stage before it becomes a formal standard with the IETF.

Apple's also been shipping mDNS as part of OSX since 10.2 in 2002, but they're not the only consumers: it also ships as a standard component in many Linux distributions (including Linux), is very common on networked printers, and an increasing number of media devices are using it.

While the certificate issue is a possible security threat, the general obfuscation of domain structure is going to cause so many headaches and confusion for less savvy internet users. What is the actual gain in having appstore.apple instead of appstore.apple.com?

While the certificate issue is a possible security threat, the general obfuscation of domain structure is going to cause so many headaches and confusion for less savvy internet users. What is the actual gain in having appstore.apple instead of appstore.apple.com?

With applications costing $185,000 and maintenance of a gTLD costing $25,000/year, ICANN as a whole has a pretty substantial financial interest in seeing the gTLD system go live as soon as possible.

By the way, am I seeing that wrong, or is RFC 6762 proposed by Apple? Early this year? Suggesting a TLD that Microsoft has been faking into use for years?

Yes, it's Apple's design, but no, it's not new: mDNS has been on the IETF standards track (with the reserved .local TLD) since 2002. The February 2013 document is just the latest evolution of the standard on its way to becoming an official IETF standard-- it has now moved from draft status into IETF's "proposed standard" state, which is the last stage before it becomes a formal standard with the IETF.

Apple's also been shipping mDNS as part of OSX since 10.2 in 2002, but they're not the only consumers: it also ships as a standard component in many Linux distributions (including Linux), is very common on networked printers, and an increasing number of media devices are using it.

Ah, okay. So ".local" had only been in "common" use for maybe a year or so at the time. Less weird, I guess.