The latest news and insights from Google on security and safety on the Internet
December 7, 2013
Further improving digital certificate security
Late on December 3rd, we became aware of unauthorized digital certificates for several Google domains. We investigated immediately and found the certificate was issued by an intermediate certificate authority (CA) linking back to ANSSI, a French 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 immediately to block that intermediate CA, and then alerted ANSSI and other browser vendors. Our actions addressed the immediate problem for our users.
ANSSI has found that the intermediate CA certificate was used in a commercial device, on a private network, to inspect encrypted traffic with the knowledge of the users on that network. This was a violation of their procedures and they have asked for the certificate in question to be revoked by browsers. We updated Chrome’s revocation metadata again to implement this.
This incident represents a serious breach and demonstrates why Certificate Transparency, which we developed in 2011 and have been advocating for since, is so critical.
Since our priority is the security and privacy of our users, we are carefully considering what additional actions may be necessary.
[Update December 12: We have decided that the ANSSI certificate authority will be limited to the following top-level domains in a future version of Chrome:
.fr
.gp (Guadeloupe)
.gf (Guyane)
.mq (Martinique)
.re (Réunion)
.yt (Mayotte)
.pm (Saint-Pierre et Miquelon)
.bl (Saint Barthélemy)
.mf (Saint Martin)
.wf (Wallis et Futuna)
.pf (Polynésie française)
.nc (Nouvelle Calédonie)
.tf (Terres australes et antarctiques françaises)]
18 comments:
You are welcome to contribute comments, but they should be relevant to the conversation. We reserve the right to remove off-topic remarks in the interest of keeping the conversation focused and engaging. Shameless self-promotion is well, shameless, and will get canned.
Note: Only a member of this blog may post a comment.
I guess that when you say "to inspect encrypted traffic with the knowledge of the users on that network", you meant in fact "to inspect encrypted traffic without the knowledge of the users on that network" ?
ReplyDeleteOkay well, how and when did it happen? The CA gets a free pass as usual, I presume?
ReplyDeleteThat's good news.
ReplyDeleteSeems like if Google really wanted to give this issue the attention it deserves, they would revoke ANSSI entirely.
ReplyDeleteThe Certificate Authority structure is profoundly broken. There are too many points of failure where a valid cert could be issued to untrustworthy people. What's the solution at this point aside from users individually deciding which certs to trust? Can something be set up where once a cert is issued it has to be in some way countersigned by the receiving party, like using your private key to generate a signature for an email message?
ReplyDeleteDoes Google Chrome feedback when certs don't mach the pin? Also is there a way to look for the sending of these logs so I can load them into a SIEM?
ReplyDeleteP.S. If so, what certs were MitMed?
Please be aware of the HN discussion on this post and how certificate transparency could be improved further: https://news.ycombinator.com/item?id=6869705
ReplyDeleteLet's translate this into proper English.
ReplyDeleteThe French NSA was spying, doing man-in-the-middle attacks using a certificate authority that it publicly controls. They used it to spy on Google SSL encrypted traffic, and Google found out. If I were to guess, I bet they monitor the fingerprints of all SSL certs in Chrome. Google found out, they revoked the CA and told ANSSI that they were busted.
Then everybody pretended it was some kind of mistake....
Ordinarily, I wouldn't comment.
ReplyDeleteBut this is important.
So I'll do the, rather pointless, Google verification dance.
Basically, I think there are two circumstances here:
1. Where the CA identifies a problem and reports it to browser vendors.
The problem might be the one you describe above, or something else (like a possible intrusion).
In this case, the trust bits for the problem certificate (the intermediary in this case) should be revoked.
2. Where you, or a 3rd party, identifies a problem.
In this case the trust bits for the CA root should be revoked.
The intention here is to provide an incentive for CAs to proactively monitor and report problems themselves.
Lest someone else report the problem and they be entirely disabled.
I have written several times to security team, but they don't take this seriously. So I decided to post my comment here. My issue is how easy it is to recover your password, even though you answer the most of the security questions wrong.
ReplyDeleteI have received an email from Adam at security team, but he does not seem to understand the core. Basically, what I gather from his email, Google looks at Device ID and IP address, and put so less focus on what users put in as an answer.
Here is one example - I used a shared computer in my company that I used to access Gmail a few years ago for only few times, and I gave wrong answer all to "password you can remember", "recovery address," "time you opened your account," but nonetherless, I was able to "hack" into my account. No questions asked.
That means that, if devide is stolen, or if one use shared computer (even that was years ago), the password is easy to crack even with wrong answers. I think Google should look at what users's answer more closely, and don't put too much reliance on whatever the mechanical algorism you Google using. At the least "last password you can remember" should match - in my case, I gave completely wrong one, "googlemail," which I never used - it went through! I gave completely different opening date, backup email, too, but but I was able to hack into my account using the computer and IP address that I used a few years ago for only few times.
This is very grave problem which needs serious solutions. I think users will prefer much tighter security control, as Google service spans a broad range of things. If Google does not act on this, I have to flag this issue to security journalist, such as Wired ITworld, and many of them out there, because using Google is insecure!. If cracking password is this easy, nobody will use Gmail. I will stop using Gmail and switch to Hotmail.
I am dismayed that the event took place months ago, but only now are we hearing about this. I would think that support for DNSSec across the Google Properties and inclusion of DANE in the Crome browser would provide a realtime and strong level of protection against detect this type of fraud. This would also go a long way to protecting your customers!
ReplyDeleteYou say that the intermediate certificate was used "to inspect encrypted traffic with the knowledge of the users"? You mean that users of the network knew that this would happen?
ReplyDeleteWhy doesn't Chrome check the Certificate Revocation List (CRL)? If in this instance the CA revoked these certificates Chrome wouldn't know any better. Chrome would have to wait for it's certificate revocation metadata to be updated. Chrome doesn't just surf the Internet it's used on the Intranet for accessing applications. Many company internal CA's rely and think that there CRL process is working when it appears Internet Explorer is the only browser that checks CRL's anymore.
ReplyDelete
ReplyDeleteThanks for your advise.
I don't understand how you detected the unauthorized certificate if it was signed by a valid intermediate CA.
And what does "to inspect encrypted traffic with the knowledge of the users on that network" mean ? Did the users allow to be spied their Google accounts ?
Thanks and regards
It's a serious problem...Suppose if any rogue employee of CA or Intermediate CA can impersonate any domain and do what he wants.
ReplyDeleteOk, this is be off topic, but I just received a notice saying that my inbox has been restored. Even though I was converting it over from a Win 7 to Win 8 machine, I didn't recognize the address or URL. Tell me if I'm being paranoid. Here's the notice:
ReplyDeleteGmail Team
5:09 PM (9 minutes ago)
We've finished restoring your inbox To make your transition easier, You are required to upgrade to newly secure server by clicking on follow below:
Follow
Regards,
Administrator
This is a great post. It’s Very informative and well writing.
ReplyDeletewebsite design baton rouge
this is really a great blog.... thanks for sharing the blog...
ReplyDeleteISO Certification Agencies