Problem solve Get help with specific problems with your technologies, process and projects.

How the use of invalid certificates undermines cybersecurity

Symantec and other trusted CAs were found using bad certificates, which can create huge risk for internet users. Expert Michael Cobb explains how these incidents can be prevented.

Digital certificates are at the heart of cybersecurity, as they help us decide who or what we can trust online....

They keep communications safe over untrusted networks and provide independent verification of the authenticity and ownership of a website.

Every computer connected to the internet contains a list of trusted root certificate authorities (CAs) to which any certificate that the system encounters must have a chain of trust. If a browser accesses a server over HTTPS that presents an untrusted server certificate, it generates a warning message. The trust invested in these CAs stems from their honesty, competence and adherence to best practices and standards.

If, at any point, people lose trust in digital certificates or the CAs that issue them, then they begin to lose trust in using the internet, as the malicious use of invalid certificates severely compromises the security of communications and protected data. For example, in 2011, forged digital certificates issued by DigiNotar were used to hack the Gmail accounts of approximately 300,000 Iranian users, and, in 2013, a French government agency was discovered using fake digital certificates for Google-owned domains to perform man-in-the-middle attacks.

More recently, Andrew Ayer, founder of SSL certificate management service SSLMate, discovered that Korean registration authority Crosscert issued 127 invalid certificates. Crosscert was one of Symantec's Registration Authority partners audited under the WebTrust auditing program for certificate authorities. Staff at Crosscert had overridden compliance failure flags and issued certificates in violation of Symantec's own policy, a security advisory issued by the Internet Corporation for Assigned Names and Numbers (ICANN) and CA/Browser Forum Baseline Requirements.

The certificates in question were issued over a period of six months before they were spotted, even though they included distinguished names that were not validated or that contained the word test. Symantec reacted by disabling issuance privileges for all Crosscert staff, revoking all the reported certificates and, subsequently, discontinuing the Registration Authority program.

The Google Chromium browser development team reported that Symantec CAs issued up to 30,000 invalid certificates over several years, a number that Symantec disputes. Symantec and the web browser community are currently negotiating a remediation plan for the vendor's CA issues.

How digital certificates are abused

A digital certificate issued by a publicly trusted CA is meant to uniquely identify a resource across the scope of the entire internet. A fully qualified domain name (FQDN) is comprised of the following domain name system labels: the local hostname, such as www; the second-level domain name, for example, mycompany; and the top-level domain, like com, org, etc. There also has to be at least one public routable IP address associated with the FQDN -- www.mycompany.com, in this example.

Organizations will often identify machines on their local network with unqualified names, such as mail, wiki and exchange, so users can just type a short name to reach an internal resource. Devices that do not have a public IP address are regarded as having an unqualified domain name.

The Electronic Frontier Foundation discovered in 2011 that there were thousands of certificates issued by CAs for common, unqualified domain names that were being used to identify machines on local corporate networks. This created a security issue, as the names are unqualified, and therefore not unique; anyone could potentially obtain a certificate that validates for https://mail or https://wiki.

If an attacker obtains a certificate for the unqualified name mail that is chained to a CA in the browser or operating system trust store, they can use it in a man-in-the-middle attack for any mail server on any internal network called mail, as they have a perfectly forged proof of identity. Connections to the server would look normal, as the certificate check would show it was issued from a publicly trusted CA or private, enterprise-scope CA.

Due to the risk created by this attack vector, ICANN issued a security advisory regarding SSL certificates for internal domain names with unqualified extensions, while the CA/Browser Forum, an organization of certificate authorities and browser vendors, asked its CA members not to issue new certificates for internal server names that have an expiration date beyond Nov. 1, 2015. By Oct. 1, 2016, all CAs were expected to revoke the remaining certificates for internal server names that were still valid, putting a permanent end to this type of certificate. However, Crosscert clearly ignored these directives when it issued the erroneous certificates.

Google imposed sanctions on Symantec in 2015 because its CA improperly issued extended validation certificates for domains it did not own, including two domains owned by Google. Domain control validation is a security-critical task for any CA, and these incidents showed that delegating responsibility for it is a risky option unless strict controls and procedures are enforced with constant auditing and monitoring.

Crosscert was also already found in breach of ICANN's Registrar Accreditation Agreement in 2013.

Preventing invalid certificates

It is difficult to stop a CA from abusing its own certificate issuance controls, so the industry has to be in a position to spot invalid certificates and penalize the issuing CA, and this is starting to happen. Google responded to Symantec improperly issuing certificates for the second time in less than two years by requiring that it support Certificate Transparency for all the certificates it issues, not just extended validation certificates, and by mandating third-party audits of all its CA operations.

Starting in October 2017, Google is making Certificate Transparency mandatory for all publicly trusted website certificates in order for them to be considered trusted by Google Chrome. Google's Certificate Transparency initiative is an open framework for logging, auditing and monitoring certificates that CAs have issued, and it seems to be catching invalid certificates. Individuals and companies can also use the Certificate Transparency log to monitor how many digital security certificates have been issued for their domains.

The current CA-based system of trust is far from perfect, but there is no obvious alternative, so it's imperative that industry leaders enforce best practices. The CA/Browser Forum tries to enforce its baseline requirements for certificates that are capable of being used to issue new certificates, but only browser and OS vendors have the power to fully revoke support for certificates deemed untrustworthy.

Some may think that Google and Mozilla's recent actions toward Symantec constitute bullying, but they don't -- they're behaving reasonably. There must be consequences for violations that undermine trust in the internet, and to be truly effective, it requires a united front.

This is not so easy to achieve, as there's not a unified industry vision of how to handle trust and security breaches. Despite strong action from Google and Mozilla against the Chinese Internet Network Information Center (CNNIC) and MCS Holdings, for example, Microsoft only released a security update that invalidated certificates issued by MCS Holdings, and didn't take any direct action against CNNIC. It's not clear if Apple ever trusted MCS Holdings.

Conclusion

Enterprise administrators should not use unqualified names to access internal resources. For example, a mail server should only be accessible at the FQDN -- https://mail.mycompany.com/ -- and not by going to https://mail/.

Enterprises issuing certificates using their own private CA, such as Microsoft's Certificate Server, should not sign certificates for unqualified names or private, nonroutable IP addresses, and should revoke any existing noncompliant certificates. Everyone involved in the lifecycle of digital certificates has to use all possible safeguards to protect them.

Internet security is a collective responsibility. Though it may take naming and shaming and applying financial pressure in order to raise everyone's game and support collective efforts preventing careless errors and poor practices, it will result in a more secure cyberspace.

Next Steps

Find out how Google and Mozilla are addressing Symantec CA's improprieties

Learn how your enterprise might benefit from having its own internal public key infrastructure

Discover how to evaluate digital certificates when buying them for your enterprise

This was last published in June 2017

Dig Deeper on PKI and digital certificates

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What changes do you think would help secure the Certificate Authority model for issuing digital certificates?
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close