Google has caught and blocked unauthorised digital certificates for several Google domains that were issued by a unit in India’s Ministry of Communications and Information Technology.
Google has warned of a potentially serious security and privacy threat affecting only Windows users thanks to mis-issued secure sockets layer (SSL) certificates that could allow an attacker to snoop on encrypted communications between a user’s device and a secure HTTPS website.
According to Google security engineer Adam Langley, on Wednesday July 2, Google discovered that India’s (NIC) had issued rogue SSL certificates for “several Google domains”.
It’s the second high-profile incident of a government intermediate certificate authority caught issuing rogue SSL certificates since December, when Google announced that a French agency had issued rogue certificates for several of its domains.
NIC holds “several intermediate CA certificates” that are trusted by the Indian Controller of Certifying Authorities (CCA), which governs India’s root certifying authority (CA). Root CAs bestow trust that web browsers place in them to intermediate certificates. These lower-level certificates can also create their own certificates, which an attacker could use to impersonate any website they wish to.
However, because NIC’s certificates are tied to CCA’s, the rogue certificates in this case only impact applications on Windows systems, according to Langley.
“The India CCA certificates are included in the Microsoft Root Store and thus are trusted by the vast majority of programs running on Windows, including Internet Explorer and Chrome. Firefox is not affected because it uses its own root store that doesn’t include these certificates.”
Unlike Firefox, Chrome relies on the root certificate store of Windows and Apple OS X -- in other words, the operating system. And in the case of Linux, Chrome uses the Mozilla Network Security Services library to perform certificate verification.
A Microsoft spokesperson told CSO.com.au that it was aware of the NIC issue.
“We are aware of the mis-issued third-party certificates and we have not detected any of the certificates being issued against Microsoft domains. We are taking the necessary precautions to help ensure that our customers remain protected,” a Microsoft spokesperson said in a statement.
Google invokes CRLSet to block rogue certificates
Google’s method of blocking the rogue certificates is likely to stir up tensions in the CA community, which doesn’t like the fact Google is forging its own path to blocking rogue certificates.
As Langley notes, Google blocked the rogue certificates in Chrome with a “CRLSet push” -- a custom Chrome function that Google reserves for “emergency situations” when it wants to revoke a certificate.
“On July 3, India CCA informed us that they revoked all the NIC intermediate certificates, and another CRLSet push was performed to include that revocation,” wrote Langley.
“Chrome users do not need to take any action to be protected by the CRLSet updates. We have no indication of widespread abuse and we are not suggesting that people change passwords.”
Following the Heartbleed OpenSSL vulnerability disclosure, the CA Security Council criticised Google’s CRLSets — certificate revocation lists — for breaking away from the CA industry’s preferred protocol for handling certificate revocation, called Online Certificate Status Protocol (OCSP), which is still supported by Microsoft and Apple.
The council said Google was cherry-picking ‘high-profile” certificates that should not be trusted, claiming that while OCSP wasn’t perfect it could still be valuable and should be recognised by Chrome.
“Even if revocation checking by OCSP isn’t 100 percent accurate, it can still protect a high percentage of users who navigate to a site with a revoked certificate and receive an OCSP response indicating revocation. Turning off revocation checking for everyone means that no one is protected,” the CA Security Council said.
This article is brought to you by Enex TestLab, content directors for CSO Australia.