The practice of issuing SSL certificates for internal domain names with unqualified extensions could endanger the privacy and integrity of HTTPS communications for upcoming generic top-level domains (gTLDs), according to a security advisory from the Internet Corporation for Assigned Names and Numbers (ICANN).
The advisory was finalized by ICANN's Security and Stability Advisory Committee (SSAC) last week and warns that existing SSL certificates which have been issued for non-public domain names like those used to identify servers inside private networks, could be used to hijack HTTPS traffic for real domain names as new gTLDs become operational. ICANN oversees the Internet's top-level domain name space.
[ Build and deploy an effective line of defense against corporate intruders with InfoWorld's Encryption Deep Dive PDF expert guide. Download it today! | Learn how to protect your systems with Roger Grimes' Security Adviser blog and Security Central newsletter, both from InfoWorld. ]
SSAC gave the example of an SSL certificate issued by a Certificate Authority (CA) to Australian clothing retailer Quiksilver for its webmail.quiksilver.com.au domain. That certificate is also valid for alternative non-publicly-recognizable domain names like qsauhub01, qsauhub01.sea.quiksilver.corp, qsauhub02, qsauhub02.sea.quiksilver.corp, and autodiscover.sea.quiksilver.corp.
The .corp domain extension has been used internally on private corporate networks for a very long time, but is currently being considered for future public use as a new gTLD. According to ICANN's website there are six different organizations that applied to become .corp registries.
"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 SSAC said in the advisory. "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 email communication)."
In a test case, a researcher working with SSAC successfully applied for and obtained an internal-use certificate for www.site from a CA. While .site is not a gTLD yet, it will most likely become one. Some .site registry applicants already offer the possibility to pre-register domain names with this extension.
The researcher set up https://www.site with the newly obtained certificate and verified that various browsers recognized the certificate as valid.
The SSAC also searched SSL certificate data collected in 2010 by the Electronic Frontier Foundation's SSL Observatory project and found 37,244 internal name certificates issued by 157 CAs. Out of those, 1,053 certificates were for domains that ended in one of 63 applied-for gTLDs.
The real number of existing internal name certificates that would conflict with upcoming gTLDs is probably much higher, the SSAC said. The SSL Observatory data is from 2010 and only contains publicly available certificates on the IPv4 (Internet Protocol version 4) network, like the Quiksilver one, that are valid for both public and non-public domain names, it said.
"Its methodology is not capable of discovering internal certificates that are not associated with a public certificate," the SSAC said. "Since the key purpose for internal name certificates is for internal use, it is highly likely that many internal certificates are unaccounted for."
The CA/Browser (CA/B) Forum, an organization of certificate authorities and browser vendors that drafts and publishes guidelines for the issuance of publicly trusted certificates, asked its CA members in July 2012 not to issue new certificates for internal server names that have an expiration date beyond Nov. 1, 2015. On Oct. 1, 2016, all CAs are expected to revoke the remaining certificates for internal server names that are still valid on that date, putting a permanent end to this type of certificate.
"Although this is welcome news, this is still problematic because ICANN plans to delegate new TLDs in 2013, introducing vulnerability for potential new gTLDs until October 2016," SSAC said.
ICANN reached out to the CA/B Forum about the problem and presented the SSAC's advisory at the organization's annual meeting in February. As a result, the CA/B Forum passed a ballot requiring all CAs to cease issuing new certificates that include gTLDs within 30 days of those gTLDs becoming operational. The CAs will also have to revoke all existing certificates for domain names under a new gTLD within 120 days after ICANN publishes the contract for that respective gTLD on its website, unless certificate owners register their private domain names publicly under the new gTLD.