An intermediate certificate authority (CA) registered to the French Ministry of Finance issued rogue certificates for several Google domains without authorization.
Google detected the use of the unauthorized certificates and launched an investigation Dec. 3, Adam Langley, a security engineer at Google, said Saturday in a blog post.
The intermediate CA that issued the rogue certificates linked back to the Agence nationale de la sA(c)curitA(c) des systA"mes d'information (ANSSI), a French national agency that protects government systems against cyberattacks and also operates the French government's public key infrastructure and root certificate authority called IGC/A.
Web browsers use a chain of certificates to determine if a secure website is authentic. Fake SSL (Secure Sockets Layer) certificates are used by hackers, but they also are sometimes used for internal surveillance purposes that do not have nefarious aims, such as the case with the French Ministry.
An intermediate or subordinate CA certificate inherits the authority of the root CA that issued it and can be used to sign certificates for any domain names that would be trusted in all browsers, unless certain technical restrictions are put in place.
According to Langley, Google immediately blocked the misused intermediate CA certificate -- and the certificates it issued -- in Google Chrome and alerted ANSSI and other browser vendors.
The intermediate CA certificate involved in the incident had been issued to the Direction gA(c)nA(c)rale du TrA(c)sor, the Treasury department of the French Ministry of Finance, and its use to sign certificates for domain names that don't belong to the French administration was the result of human error, ANSSI said in a statement on its website.
"The mistake has had no consequences on the overall network security, either for the French administration or the general public," ANSSI said. "The aforementioned branch of the IGC/A has been revoked preventively."
ANSSI found that the intermediate CA certificate had been used in a commercial device to inspect encrypted traffic on a private network with the knowledge of the network's users, Langley said.
ANSSI can confirm the Google statement, spokeswoman ClA(c)mence Picart, said Monday via email. "This use is clearly against the policy of the IGC/A."
The incident follows a similar case late last year when a subordinate CA certificate issued by a Turkish certificate authority called Turktrust to the Municipality of Ankara was installed in a firewall appliance and was used to inspect SSL traffic. In February 2012, Trustwave, another CA trusted by browsers, publicly admitted to issuing a sub-CA certificate to a third-party company so it could inspect SSL traffic passing through its corporate network.
The inspection of SSL traffic on their own networks can help organizations prevent data leaks or discover malicious connections initiated by malware. Many gateway security appliances offer this capability, but the generally accepted method is to use self-generated CA certificates for this purpose. These certificates are not automatically trusted by browsers and need to be deployed by administrators on machines targeted for monitoring.
The use of sub-CA certificates issued by trusted CAs for SSL traffic inspection is considered dangerous because if such a certificate gets stolen it can be used in man-in-the-middle (MITM) attacks to intercept traffic outside of private networks on the Internet.
In 2012, Mozilla said that issuing sub-CA certificates to third parties for traffic inspection is unacceptable and asked CAs to revoke certificates issued for this purpose. In February 2013, the software developer updated its CA Certificate Policy to improve the accountability for the intermediate CA certificates.
The policy change requires CAs to implement technical constraints for sub-CA certificates issued after May 15, 2013, or to publicly disclose such certificates and subject them to the same audits as their root CA certificates. The technical constraints the policy refers to include the name constraints extension that can be used to restrict a sub-CA certificate's usage to a particular domain name.
CAs received a grace period until May 15, 2014, to update their sub-CA certificates issued before May 15, 2013.
"The intermediate CA was not yet constrained, but there is a plan to implement such limitations," Picart said. "We are currently under the process to review all the intermediate CA issued by IGC/A in order to make sure this incident cannot happen again."
According to Picart, the intermediate CA certificate was issued on July 18. This means the agency might have violated Mozilla's policy by issuing a sub-CA certificate with no technical constraints after May 15, unless the certificate was publicly disclosed and audited in accordance with the policy.
Mozilla did not immediate respond to a request for comment.
Preventing sub-CA certificate abuse going forward will require a combination of technical and policy-based measures, said Ivan Ristic, director of application security research at security firm Qualys, which runs the SSL Labs and SSL Pulse projects, Monday via email.
"First, we need to get Public Key Pinning widely supported and have the violations reported," he said. "That, in combination, with clear rules that the use of public CAs is not allowed for MITM, will hopefully do it."
Public key pinning is a browser feature that caches information about legitimate SSL certificates used on visited websites, so that if traffic interception is attempted in the future using rogue certificates, the browser would be able to detect and block those attempts. A version of this feature is already implemented for some high-profile websites in Google Chrome, but is being considered as an Internet standard.
Policy-based restrictions need to be backed by enforcement, Ristic said. They won't work unless browser and operating system developers are prepared to temporarily or permanently revoke their trust in root CA certificates for violations, he said.