Google takes Symantec to the woodshed for mis-issuing 30,000 HTTPS certs

Chrome to immediately stop recognizing EV status and gradually nullify all certs.

Read the whole story

 

[sjl]

Good job, Google. 30,000 unauthorised certificates being issued is 30,000 too many; five or ten you could maybe, kinda, sorta understand, but 30,000 smacks of huge incompetence at best.

Companies who have their root certificates entrusted as part of the TLS core infrastructure need to have better checks and balances than to simply say "oops, we done goofed" after the fact. If they demonstrate - as Symantec has demonstrated - that they can't manage that, their root certificates need to be yanked out of the chain of trust as soon as possible.

It sucks, royally, for those who have paid for their certs in good faith, but this is too important an issue to simply let slide just because Symantec has signed a lot of the certificates out there.

"Their proposed action is irresponsible", claims Symantec. Would that be more, or less, irresponsible than letting 30,000 certificates get improperly issued? Symantec: get your systems in order, fix the problems, show us a reason to trust you, and then, maybe you'll have moral grounds to bitch about irresponsible actions.

 

[sjl]

Google isn't responsible to your customers and partners, they are responsible for all Chrome users, and even to site owners that are not your customers as well.

Except many of those customers / users on both sides are going to be punished despite not being bad actors.

So how would you deal with this?

It is an undeniable fact that Symantec has improperly issued certificates, with huge potential implications for the security of TLS communications - security that literally just about everybody on the Internet implicitly relies upon. Given that Symantec has improperly issued so many certificates, that renders all their certificates suspect - a simple revocation list is not sufficient; what if you miss some? What if Symantec deliberately chooses to not give you a complete list?

So what can be done without impacting upon at least some innocents, knowing that if you don't act, you're leaving a huge number of innocents - including a huge number of sites that have never done business with Symantec's CA arms - at risk of MitM attacks?

Google have said that they will be reducing the validity of Symantec certificates over time - extended validation is declared null and void immediately (which is simply a reduction in the level of trust given to a certificate, not a repudiation of the certificate in its entirety), whilst the ability to use those certificates for encrypted communication will be dropped over time. People who have Symantec-issued certificates have time to find an alternate supplier and get new certificates; it's not like they're being left abruptly out in the cold.

So again: what would you do differently?

 

[sjl]

In this case, it seems that they were supposed to be "test" certificates. Of course, for example test.com may look harmless, but there is a website at https://www.test.com/.

Point one: don't issue test certificates.
Point two: if you must issue test certificates, issue them for a domain you own and control.
Point three: if you must issue test certificates for a domain you don't own and control, don't use the CA certificate that is trusted by just about every damn web browser out there.

This is not freaking rocket science. It's not hard to add a new root certificate to a web browser off your own bat; the reason why CAs like Symantec are trusted is because their root certificate is included by default (and the reason why it's hard to break into that market is because getting your root certificate included by default is a non-trivial exercise.) If you're doing testing, you control which browsers or other software you're using, and that means you can control which root certificates are trusted.

I can think of no good reason for using a broadly trusted root certificate to sign a certificate that won't be owned and used by the owner of a given domain. Every scenario I can think of can be managed either by using a "test purposes only" root certificate (and installing it in the test systems' trusted CA list), or by issuing a test certificate for a domain that the company owns and controls.