As browsers move away from unsecured HTTP, SSL certification has become an increasingly more public topic. Free services such as Let's Encrypt simplify the process of acquiring certificates, but the likes of Symantec still offer pay-for options if it makes you feel better. Except it shouldn't, as security researcher Hanno Böck recently discovered.
Motivated by the fresh conversation around web security and encryption, Böck decided to test the thoroughness of two certificate authorities: Symantec and Comodo.
An SSL certificate is comprised of a public and private key, which facilitate encrypted communication between client and server. However, if the private key is compromised or a problem occurs with the certificate, the issuing authority will almost always revoke it.
After legitimately acquiring certificates from the aforementioned services, Böck generated fake private keys from them. The keys would pass superficial checks, but would fail deeper investigation.
He then laid the trap, so to speak:
I created such fake keys for both domains and uploaded them to Pastebin. If you want to create such fake keys on your own here’s a script. To make my report less suspicious I searched Pastebin for real, compromised private keys belonging to certificates ... These additional keys allowed me to make my report to Symantec and Comodo less suspicious: I could hide my fake key report within other legitimate reports about a key compromise.
Turns out Comodo didn't go for it. Symantec, on the other hand:
Symantec however answered me that they revoked all certificates -- including the one with the fake private key. No harm was done here, because the certificate was only issued for my own test domain. But I could’ve also fake private keys of other peoples' certificates. Very likely Symantec would have revoked them as well, causing downtimes for those sites. I even could’ve easily created a fake key belonging to Symantec’s own certificate.
Not exactly a great look for Symantec, whose certificates are already set to be blacklisted by Chrome.
To its credit, Symantec didn't sweep events under the rug, with the company's Rick Andrews publishing the following update:
First, a gap was identified in the public and private key matching process where keys are verified during the revocation request procedure ... Once we became aware of this, we immediately corrected the procedure. Secondly, we are reviewing how we communicate with customers during the 3rd party revocation request process to be more consistent and transparent with certificate owners.
Which is good news, I guess, but one could argue the damage to Symantec's reputation has already been done.