Enhancing digital certificate security

Thursday, January 3, 2013 10:01 AM



Late on December 24, Chrome detected and blocked an unauthorized digital certificate for the "*.google.com" domain. We investigated immediately and found the certificate was issued by an intermediate certificate authority (CA) linking back to TURKTRUST, a Turkish certificate authority. Intermediate CA certificates carry the full authority of the CA, so anyone who has one can use it to create a certificate for any website they wish to impersonate.

In response, we updated Chrome’s certificate revocation metadata on December 25 to block that intermediate CA, and then alerted TURKTRUST and other browser vendors. TURKTRUST told us that based on our information, they discovered that, in August 2011, they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates. On December 26, we pushed another Chrome metadata update to block the second mistaken CA certificate and informed the other browser vendors.

Our actions addressed the immediate problem for our users. Given the severity of the situation, we will update Chrome again in January to no longer indicate Extended Validation status for certificates issued by TURKTRUST, though connections to TURKTRUST-validated HTTPS servers may continue to be allowed.

Since our priority is the security and privacy of our users, we may also decide to take additional action after further discussion and careful consideration.
The comments you read here belong only to the person who posted them. We do, however, reserve the right to remove off-topic comments.

16 comments:

Vincent Allen said...

MSFT is pushing update

Microsoft Security Advisory 2798897

Fraudulent Digital Certificates Could Allow Spoofing

http://technet.microsoft.com/security/advisory/2798897

dwoz said...

Its a good example of how the best security pracitces we have still go terribly wrong at times.

Daniel Wozniak

The Locksmith said...

Why does plus.google.com use a *.google.com cert? Seems like extremely poor decision by the plus team and Google Online Security to allow use of a domain wild card cert. In fact, why does a *.google.com cert exist? If you think, nothing wrong with the practice then is plus the only product/service to use a wild card cert?

Sebastian Schmidt said...

That's why we should finally switch to TLSA RRs, which only make sense with DNSSEC.

If you, fellow readers, administrate a DNS service at your company, get DNSSEC set up. TLSA or CAA afterwards is trivial. Chrome already verifies it, Mozilla has plans to do so (also a nice introduction): https://wiki.mozilla.org/Security/DNSSEC-TLS-details#Embedding_Certificate_Information_in_DNS

mds_ said...

@Sebastian, yes, let's put registrars and NICs in charge instead... no, thanks!

Collin said...

The conclusion of the post notes that Google "may also decide to take additional action after further discussion and careful consideration," which to me hints that the Chrome team, as others, are likely considering whether to continue including TURKTRUST root. While I fully appreciate the ramifications of the breach, I would inveigh upon the community to take time to consider subsequent actions. Unfortunately, due to banking embargoes against sanctioned states, there are very few CAs that accept customers from Iran and Syria. TRUSTTRUST and ipsCA (not trusted) are likely the primary CAs for these audiences. Unfortunately if this CA is removed, it is likely that the decision will push many sites into the national, not-trusted and completely compromised CA ParsSign.

Schmaltz Herring said...

Diginotar CA is gone after what happened. I hope the same will happen to TURKTRUST.

Mustafa Serdaroglu said...

As a Turkish citizen, I agree that Turktrust should be condemned. However, previously and duly issued certificates should not be revoked, it is not fair for the merchants who may not (and in all likelihood do not) understand what is going on. That said, I'd like to reiterate that I agree with Google's decision.

Nephilim said...

@Google: Can you tell us, *how* did you find this out?

Tritonio said...

Google should ASAP improve the extensions' API to allow extensions like SSL observatory and Convergence to be created for Chrome. Firefox had the proper API for years and I am really thinking of switching back to Firefox because of Chrome's crippled API.

In other words if you actually care about user privacy, give the users tools to make stuff to protect their privacy as *they* see fit.

Paul B said...

Locksmith: Google probably do NOT use a *.google.com certificate.

The issue here is that SOMEONE ELSE managed to create one (and one that was TRUSTED) and use it for a man-in-the-middle attack against Google.

Neil Rashbrook said...

@Nephilim My understanding is that Chrome knows who the issuers of the real Google certificates are, so that it can immediately identify a fraudulent certificate.

Unknown said...

@Paul B:

Google uses *.google.com certs a lot. With quite a lot of Subject Alternative Names.

An example of *.google.com certs for various hosts collected just by browsing (note that some repeat, they are shared for multiple google services).

Another count from an observatory (those are all unique certs, most of which, if not all, belonging really to google):

select count(id) from ee_certs where subject like '%CN=*.google.com%' and not_after >= '2013-01-01';
count
-------
1188

(Sorry if this is double-posted, the comment system does not make it easy).

newsham said...

Please scope the CAs already. I don't need turktrust or any of its intermediaries signing for anything but *.tr!

abodeqa said...

so still intermediate CA are issuing such kind of digital certification. If this is happening then how actual digital certificate can be redeem with the parent CA.

mdav said...

It seems the time is right for DANE (RFC6698), so I hope it will be incorporated in Chrome and other browsers some day soon.