Certificate Authorities for SSL/TLS: Crypto’s Weak Link

In the wake of Comodo's announcement of a compromised ^[1] affiliate Registration Authority (RA) and their subsequent issuance of fraudulent certificates^[2], the information security community has given more scrutiny to the process of signing, revoking, and verifying SSL/TLS (Secure Sockets Layer/Transport Layer Security) certificates. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communications security over the Internet ^[3]. There's good reason for this heightened concern: certificates are often the only means of verifying the identity of the endpoint with which sensitive information will be exchanged. E-commerce, online banking, and other conveniences of the modern Internet would be unthinkable without the identity verification and transport security enabled by these certificates.

Security researchers have demonstrated many weaknesses against the current certificate infrastructure. Several of the issues focus on the role of Certificate Authorities (CAs) ^[4] and the trust that's placed in them. When a web browser trusts a CA, it does so completely. Any trusted CA can sign a certificate that will be valid for any domain. Web browser and operating system vendors such as Mozilla ^[5], Microsoft ^[6] and Apple ^[7] each have their own guidelines for CAs that are trusted by default. The result is that there are over 650 such CAs are trusted by either Mozilla, Microsoft, or both ^[8]. These root CAs often delegate their trust to other organizations, known as Registration Authorities (RAs). With this many authorities able to issue widely trusted certificates, problems are inevitably going to arise. As the Comodo breach and other past events ^[9][10] highlight, CAs can be coerced or compromised, resulting in the issuance of fraudulent certificates. Further, some of these CAs are under the direct control of governments that may eavesdrop on their citizens and others.

With the failures of CAs to live up to this trust clearly demonstrated ^[1][9][10], we must pay attention to how a cryptographic system handles the existence of untrustworthy certificates. Certificate Revocation Lists (CRLs) ^[11] aim to provide an updated list of certificates that have been revoked by their issuer and cannot be relied upon. This list is periodically checked by applications that use certificates, and the certificates on it are flagged as untrusted. The Online Certificate Status Protocol (OCSP) ^[12] improves upon the CRL model by providing a real-time certificate status mechanism. However, both CRLs and OCSP suffer from the fundamental flaw that they fail-open: the absence of a certificate's presence in either system functions as an indicator that the certificate can be trusted. This means if CRL and OCSP requests are blocked, perhaps by the same attacker presenting the untrustworthy certificate, then an endpoint will accept any certificate signed by a trusted CA as valid regardless of its revocation status. This flaw has been publicly demonstrated and significantly undermines the ability to successfully revoke certificates ^[13][14]. The response to the Comodo breach included web browser and operating system patches to blacklist these fraudulent certificates, which would have been unnecessary if a working and reliable revocation process were in place. New proposals such as DANE ^[15], HASTLS ^[16], MonkeySphere ^[17], and CAA ^[18] aim to shore up this foundational weakness but have not yet been agreed upon or implemented.

The latest news related to weaknesses in the certificate infrastructure comes from the EFF (Electronic Frontier Foundation), a U.S. non-profit digital advocacy group. EFF's mission of being a voice for Internet privacy has led to the creation of the SSL Observatory ^[19], a project that collects information on SSL certificates observed in public use. Google also recently announced the Google Certificate Catalog ^[20] and has made it available for querying using a DNS interface.

Mining of the SSL Observatory has shown ^[21] widespread use of unqualified names in certificates issued by several CAs. The use of unqualified names poses a problem that goes directly to the heart of SSL certificate verification. Under normal operation, a client (such as a web browser) contacts a remote site and obtains a certificate. The client compares the certificate's name to the requested site's name. If these values match and the certificate is signed by a CA that the client trusts, then the certificate is considered valid. Public CAs should therefore only sign certificates with public names that can be confirmed to uniquely represent a single host, which at this time means using a fully-qualified domain name. This concept is known as Domain Validation. When CAs sign private names, there's a risk that it may refer to different hosts in various environments, which directly impacts the client's ability to validate the remote endpoint's identity. There is also a question of how a CA issuing Domain Validation (DV) certificates could have actually validated the ownership of an unqualified name.

As an example, consider the unqualified name "localhost." This name will always point back to the system on which it's queried, leading to differences in its resolution from any given endpoint. A certificate signed by a trusted CA with the name "localhost" can be used to spoof a secure transaction from any system to itself. This example is of little practical use, but similarly unqualified names such as "mail" or "intranet" may resolve to servers relevant only within the environment in which they are queried. Thus the target of these names will vary between different organizations, making a certificate for these names valid for multiple hosts. The widespread issuing of certificates for these unqualified names means attackers can easily impersonate secure sessions established through the use of such unqualified names.

Organizations that use SSL/TLS certificates would be wise to follow these best practices when creating or handling certificates:

Unqualified names must not be used to access internal resources that require secure transport and identity verification.
The use of unqualified or non-public names must be confined to private certificate authorities, which are in turn trusted only by endpoints that trust the issuing organization.
Consider reviewing the default root CAs to determine if they are valid trustpoints for your organization. For example, governments may not want to trust CAs issued by foreign governments.

Public Certificate Authorities should also devote additional scrutiny when issuing certificates to ensure the authority of the requestor.

Specific actions that make a difference are few and challenging at present. The security community is struggling to find solutions for most of these issues. Given time, the development of better secure certificate signing, exchange, and revocation protocols should improve the security posture of certificate usage. In the interim, the CTU research team advises caution when performing sensitive transactions. That server on the other end just might not be what you think it is.

[1] http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/

[2] https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

[3] http://en.wikipedia.org/wiki/Transport_Layer_Security

[4] http://en.wikipedia.org/wiki/Certificate_authority

[5] http://www.mozilla.org/projects/security/certs/policy/

[6] http://technet.microsoft.com/en-us/library/cc751157.aspx

[7] http://www.apple.com/certificateauthority/ca_program.html

[8] https://www.eff.org/files/colour_map_of_CAs.pdf

[9] http://www.microsoft.com/technet/security/bulletin/MS01-017.mspx

[10] https://blog.startcom.org/?p=145

[11] http://en.wikipedia.org/wiki/Revocation_list

[12] http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol