Mozilla is taking steps to limit the risk of powerful subordinate Certificate Authority (CA) certificates falling into the hands of attackers and potentially being used to issue rogue certificates for use in SSL snooping attacks.
The browser maker updated its CA Certificate Policy with new requirements that will improve accountability for subordinate CA (sub-CA) certificates and will subject them to restrictions and independent audits.
Sub-CA certificates inherit the powers of the issuing Certificate Authority (CA) and can be used to issue SSL certificates for any domain names on the Internet that will be accepted by any browser trusting the issuing CA. Until now, this type of powerful certificate has not been strictly regulated and has not been subjected to the same security audits and controls as the root CA certificates that signed them. In some cases CAs do not even publicly disclose the sub-CA certificates they issue.
"Version 2.1 of Mozilla's CA Certificate Policy encourages CAs to technically constrain subordinate CA certificates using RFC 5280 extensions that are specified directly in the intermediate certificate and controlled by crypto code (e.g. NSS)," the Mozilla Security Team said Friday in a blog post. "We recognize that technically constraining subordinate CA certificates in this manner may not be practical in some cases, so the subordinate CA certificates may instead be publicly disclosed, and audited in accordance with Mozilla's CA Certificate Policy."
What this means is that sub-CA certificates must either have their power restricted through a set of extensions, or be held to the same standards as root CA certificates. In order for a sub-CA certificate to be considered publicly disclosed and audited, the CA must publish the certificate and the Certificate Policy or Certification Practice Statement used by the new subordinate CA, and the new sub-CA's internal operations must be audited annually by an independent party in order to attest its conformance to the certificate verification requirements.
All sub-CA certificates that are issued after May 15, 2013 must comply with the new version of Mozilla's CA Certificate Policy, and pre-existing sub-CA certificates must be updated to comply with the new policy by May 15, 2014.
"With these updates to Mozilla's CA Certificate Policy, we re-iterate our belief that each root is ultimately accountable for every certificate it signs, directly or through its subordinates," the Mozilla Security Team blog reads. "Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe, up to and including the removal of root certificates that mis-issue, as well as any roots that cross-sign them."
In February 2012, Trustwave, one of the CAs trusted by browsers, publicly admitted that it had issued a sub-CA certificate for use by a third-party company to inspect SSL traffic passing through its corporate network. Trustwave defended itself at the time by saying that the issuing of subordinate root certificates to private companies so they can inspect the SSL-encrypted traffic in and out of their networks is a common practice in the industry.
This type of sub-CA certificate usage is frowned upon in the security community, because it subverts the trust of the entire SSL ecosystem. If it falls into the wrong hands, a sub-CA certificate can be used by attackers who control a network's gateway to snoop on the SSL connections of that network's users. This can even be done at the ISP level, or at national level, in countries where the government controls all Internet gateways.
Mozilla said at the time that the use of sub-CA certificates for man-in-the-middle SSL traffic monitoring, even if performed on closed corporate networks, is unacceptable. The browser maker sent an official email to all certificate authorities asking them to immediately revoke all sub-CA certificates used for such purposes and destroy the hardware security modules -- special hardware devices for storing encryption keys -- that contained them.
The generally accepted method of performing SSL traffic inspection on private corporate networks is to generate self-signed CA certificates that then deploy them on all systems and browsers within those networks, in order for them to be trusted only in those environments. This method, however, can be costly and time consuming, especially on very large networks.
The Trustwave incident was not the only case of sub-CA certificate misuse. Back in January, Google, Mozilla and Microsoft blacklisted two sub-CA certificates issued by Turkish Certificate Authority Turktrust, after one of them was used to issue a wildcard certificate for *.google.com without authorization from Google.
Turktrust said at the time that the blacklisted certificates had been issued with sub-CA status by mistake in August 2011 and were actually supposed to be regular certificates. One of them was issued to an agency of the Municipality of Ankara, which later installed it in a firewall appliance with SSL traffic monitoring capabilities.
The new version of Mozilla's CA Certificate Policy formalizes the browser maker's position on the issuing and use of sub-CA certificates and might indirectly improve security in enterprise environments, said Ivan Ristic, director of application security research at security firm Qualys, which runs the SSL Labs and SSL Pulse projects.
The technical constraints for sub-CA certificates that Mozilla refers to include the name constraints extension. This is a special extension that can be used to restrict a sub-CA certificate's usage to a particular domain name. For example, a CA can issue a sub-CA certificate with a name constraints extension that allows it to only be used to sign digital certificates for a single domain name.
This type of sub-CA certificates can be useful in corporate environments that use domain names internally and have internal SSL-enabled websites.
"In my experience many companies have lots of internal certificates and more often than not they are self-signed, they're invalid and there's no central control over who's issuing them," Ristic said. "As a result, if you visit some of these internal websites, it's often that security is not very good, the encryption keys are small and so on. If you have to use self-signed certificates every day it sort of limits the advantage of using SSL in the first place."
"If we go forward into a different world where restricted sub-CA certificates are affordable, then we might actually see a security improvement overall," Ristic said. However, there are some issues with the name constraints feature, because not all modern browsers support name constraints the way they should, he said.
Apple Safari and iOS devices do not respect name constraints, meaning that even if restricted in this manner, sub-CA certificates could still in theory be used to launch man-in-the-middle SSL attacks against Safari and iOS users, Ristic said. In practice, this won't be very useful for mounting large scale attacks, but could be used in targeted attacks against users of that software, he said.
The problem stems from the fact that not all clients -- browsers and other software that supports SSL -- understand name constraints.
Certificate extensions can be set as critical or non-critical, Ristic said. RFC 5280, which defines the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" specifies that if the name constraints extension is used, it must be marked as critical. At the same time, conforming clients must reject a certificate if it has an extension marked as critical that they don't understand.
In practice, this means that CAs can't issue sub-CA certificates with name constraints extensions marked as critical, as required by the specification, because some clients will reject the certificates. As a result, version 1.1 of the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" guidelines released by the Certification Authority/Browser (CAB) Forum allows CAs to issue sub-CA certificates with name constraints set as non-critical.
"Non-critical Name Constraints are an exception to RFC 5280 that MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide," the Baseline Requirements (BRs) say.
The Mozilla Security Team said that version 2.1 of Mozilla's CA Certificate Policy requires CAs to update their operations and SSL certificate issuance to comply with version 1.1 of the CAB Forum's BRs. However, it's not immediately clear if Mozilla's new policy will allow name constraints extensions to be marked as non-critical or not, Ristic said.
