Saturday, 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)]

1 comment:

  1. Ordinarily, I wouldn't comment.

    But 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.

    ReplyDelete

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.