Ripping Off the Bandaid: Chrome and Firefox to Distrust Symantec SSL Certs
Derek Kuhnert Sep 6
Today, Firefox 62.0 was released, which means we are one major release away from an event that will significantly impact the state of the web. Upon the release of Firefox 63.0, Firefox will distrust SSL certificates issued by Symantec-owned root authorities. Let's talk about that.
Background: What do certificate authorities do?
Before we talk about certificate authorities, we need to talk about the very basics of SSL. If the concepts of certificates and encryption are starting to push you away from this post, fear not: I'm going to keep this pretty high-level.
SSL tries to solve the problem of people being able to look at your internet traffic, while it's in-transit. It relies on encryption, which means the data that goes from you to a server (and vice-versa) is jumbled up in a way such that third parties can't read it. This requires your browser to send some introductory information to the server, and the server to send some introductory information back. This "handshake" happens in plaintext (i.e. not encrypted), but due to the mathematical properties involved, third parties are not able to use that information to decrypt the traffic.
This process is mathematically sound, with a major assumption: That the entity that you're talking to really is the server that you want to talk to. If a third party somehow manages to trick your browser into talking to IT instead of the server (called a "man-in-the-middle attack"), it can set up an SSL connection with you, and a separate SSL connection with the server. Thus, it tells you that it's the server, and it tells the server that it's you.
The idea of certificates is intended to cover this vulnerability.
When you encrypt a message for sending over an SSL connection, the process takes an additional input, called a "public key". This ensures that, when someone else knows the "private key" that corresponds to the public one, they can read it. So, you use the public key for the server (that potentially everyone knows) to encrypt the message, and the server uses its private key (that only the server knows) to decrypt it.
Here's the kicker. If a third party wants to get in the middle, then, they have to tell you to use a public key that is NOT the server's. If the person on the other end gives you the wrong public key, then they are not really the server. So, how do you know that the public key is correct? Some entity that you trust, called a "Certificate Authority", tells you. In short, this certificate authority (or CA) does some investigation to find what the public key of the server is, and they tell you.
Note to nerds: Yes, you're not really talking TO the CA in this process. I'm keeping it high-level.
Of course, this brings up a new question: How do you know that the info you're getting from the CA is correct?
This is solved by having a public/private key for the CA as well. In short, if you have the public key of the CA, then you can ask the CA to prove that they own the private key by encrypting/decrypting something. With this idea, you can also ask them to prove that they really issued a certificate to the server (i.e. saying "I trust them"). But then how do you know that you have the right public key for the CA?
These issues basically form a chain of trust that goes from the server all the way to a CA that is automatically trusted by the browser developers, called a "Root CA". So, for example, if A trusts the server, and B trusts A, and C trusts B, and your browser trusts C, then you know that you're talking to the server.
If you have ever seen the big warning pages that show up sometimes in Firefox or Chrome about invalid certificates, basically what's happening is that the chain of trust is broken at some point, and you don't know for sure that you're really talking to the server.
Symantec and the problem with CAs
The certificate idea is already shaky at best from how convoluted it can be, and the fact that it was never really intended to live this long in the first place. This gets even worse when you realize that CAs have an incentive to sell as many certificates as possible, instead of being diligent in making sure they're trusting the right people.
Symantec has been caught up in this issue for a while now, and they've honestly gotten far too much leniency already. Last year, Mozilla decided to put forth a plan to officially distrust Symantec-owned root CAs, and Chrome shortly followed suit. In short, when the plan reaches its conclusion, sites that have certificates that ultimately end in being trusted by a Symantec-owned CA will no longer be trusted, and will display the error message shown above when viewed in Firefox or Chrome.
When Symantec is finally distrusted by Chrome and Firefox, that will affect a relatively large portion of the internet (potentially up to 6% of sites with SSL enabled). We used to have better numbers on how much of the internet's SSL certificates come from Symantec, but Symantec recently sold ownership of those root CAs to DigiCert. Firefox and Chrome still plan to distrust the CAs, but now it's a bit harder to tell statistics-wise how many certs come from those CAs. We do know that DigiCert certificates account for about 6.5% of the internet's SSL certs at the time of this writing, and that amount is dropping as more sites switch to other CAs so they don't have error messages pop up in Firefox and Chrome.
The long story short is that, soon, we're going to see things get a bit hectic as people start seeing error messages on websites that are still using a Symantec CA. However, that should serve as a kick-in-the-pants for those websites to switch to a new CA.
The great part about all of this is that, in the long run, this example is going to serve as a warning to CAs who don't put in the effort needed to properly verify public keys. If even a company as big as Symantec can be distrusted by major browsers, that's a big incentive for any CA to make sure that they're doing things right, or else their certs that they're selling will become worthless.