UPDATE 1: A few of the facts outlined below are wrong. I will update this post in a few hours to make it both more balanced, and more accurate. Until then I refer to a response from Symantec here, and you can make your own minds up about it.

Okay, so in my last post I was not abreast of the full facts. Now that I am I will start by quoting the guy that discovered the security vulnerability, Chris Bryne:

My STRONG recommendation, is that anyone who purchased a Symantec certificate from a third party, between early 2013 and late 2016, revoke that cert and have it re-issued… either directly by Symantec, or simply revoking and having another trusted CA issue a different cert… as soon as they are able to do so.

As to first party certificates… I don’t know and have not been able to validate how extensive the exposure was, through which interfaces, etc… I do know that they fixed the specific issues that I found in the specific interfacecs I was able to validate, within six months as they agreed to. That said… It would be safer to revoke and re-issue, given the problems that Google themselves identified.

As to end users… I would be extremely wary of any site with a symantec cert issued before late 2016, and take some extra caution regarding any symantec cert period.

You can read all about it on his Facebook post. Chris is a fucking legend. In early 2015 he discovered a severe security vulnerability. The vulnerability is simple enough, and easy to describe and understand. When a customer purchased a security certificate from Symantec (all kinds of certs, not just SSL certs) they would be sent an email with links to retrieve/revoke/renew their certificate. There was no authentication performed besides a simple URI in the links. This could be easily modified to retrieve, revoke, or renew certificate for other customers. At the moment, this isn’t too horrible – after all every time you visit my site it sends you the TLS certificate so you can establish a secure connection, it’s not a secret. So at worst people could get up to mischief by revoking certificates other people had paid for, or issue fresh ones they have to pay for. However it’s still a very serious security breach because it means that an unauthorised person managed to get certificates issued – and it’s the CA’s job (CA = Certificate Authority, i.e. Symantec) to properly verify requests before issuing certificates.

But to make matters worse, and this is why you should NOT sign in to CBA’s Netbank or any other bank that uses a Symantec security certificate effective immediately, some resellers generated the private keys for their customers. Chris found that when this was the case it was also possible to steal customer’s private keys covertly using the same method to get the certificate. Symantec never told their customers that their private keys could have been stolen! Most websites never change their key pair, they will keep the same keys for year or even decades. That means if an attacker stole your private key using this method, they can use it any time they want so long as you keep getting new certificates generated from CSRs generated from the private key. It doesn’t matter if you change CAs and switch to say Let’s Encrypt or something, unless you change the private key all an attacker needs to do to decrypt your visitor’s traffic is perform a MITM attack a la PRISIM.

Symantec claims they don’t believe any attackers stole private keys. However, they outright lied when they issued this statement to several media outlets that ran the story (one such source for it is BleepingComputer):

We have looked into Chris Byrne’s research claim and could not recreate the problem.  We would welcome the proof of concept from the original research in 2015 as well as the most recent research.  In addition, we are unaware of any real-world scenario of harm or evidence of the problem.  However, we can confirm that no private keys were accessed, as that is not technically feasible. We welcome any feedback that helps improve security for the community.  Anyone who would like to share further details about real-world scenarios or proof of concept should contact us at https://www.symantec.com/contact/authentication/ssl-certificate-complaint.jsp.

Symantec has completely mismanaged this whole shitstorm. Chris Bryne now regrets not going public in the first place, and I can’t blame him. He states specifically on his Facebook post (in a comment) that Symantec failed to live up to their end of the agreement. They didn’t take any proactive or remedial action whatsoever to ensure everyone who was exposed to potentially having their private keys comprised generated new ones. They didn’t do shit. Since when do you need to confirm a malicious security breach first before you take action to protect your customers? You don’t – that’s not how security is done!! You assume that EVERYONE who had a private key generated by a reseller that could have been compromised was compromised, then you get all of your affected customers to generate new private keys, and then you tell them why. Symantec never even publicly disclosed the full details of this vulnerability, even after they believe they had finished fixing the problem.

So… if you have a Symantec certificate, and you bought it from a reseller like your host, and the reseller generated the private key and CSR, then revoke your certificate now, generate a new private key, and a new CSR, and use that to get a fresh certificate. Oh and, obviously do not trust any website with Symantec SSL certificate older than November 2016, especially including banks. Fuck Symantec! Chris… you’re a fucking legend.

Whirlpool Topic