I trust Certificate Authorities, but I have no idea why

I’ve seen statistics that claim between 40% and 60% of all sites on the Internet use encryption to protect their web application traffic.  Regardless of the true number (which changes on a daily basis), it’s fair to say that encryption is a huge issue for sites today, and it’s never a bad idea to understand a little bit more about it.  In order to protect web traffic, sites use the SSL/TLS protocol, and the address bar on your Internet browser shows “https://” instead of “http://” when visiting those protected sites. 

Did You Know?   Google uses HTTPS as a ranking signal…meaning that you will get a better place on Google search pages if you use HTTPS on your website.

Before you can view the contents of a secure website, several “handshake” steps have to take place between your browser and the secure server that hosts the site.  Essentially, the browser and the server have to agree on how they will securely communicate (encryption keys, compression methods, etc) before the communication can take place.  One critical piece of this initial handshake is the exchange of a “certificate” between the browser and the server.  The certificate contains (among other things) the public encryption key that is used to encrypt your secure connection.  Without this certificate, the encrypted communication would never happen.  A Certificate Authority (CA) issues these certificates, and your web browser allows you to see an encrypted website…or not…based on its trust relationship with the CA.

Since we inherently trust our web browsers (Internet Explorer, Firefox, Chrome, Safari, etc) to only show us what is safe, and since our web browsers trust the certificates that are issued by these CAs, I thought it might be useful to spend a little time exploring the CAs themselves.  Who are they, what do they do, and why should you care?

To start off, let’s take a quick look at the basics of how a browser and a web server interact with one another.  Here’s a very simplified representation of the secure handshake process that takes place between your web browser and a secure server.  The browser initiates communication with the server (asks to view a secure website), the server sends the certificate to the browser, and the browser checks to make sure the certificate was issued by a trusted source.  If the certificate was issued by a trusted CA, then the browser is happy and you get to view the website.

What if the certificate is issued by a non-trusted source?  If a web server sends a bad certificate to the browser, what should the browser do?  After all, if a user were to accept a certificate from an attacker, the attacker could easily steal sensitive information from that session (maybe login credentials, maybe something else?) because he would have the encryption keys that he could use to decrypt and read everything.  Well, how many times have you seen the following screen pop up on your computer…and how many times have you clicked “Continue…”?

Now that we know a little bit about how certificates are used in the communication process between browser and server, let’s take a quick look at what these certificates actually look like and what they contain.  While the certificate contains the public encryption key for the website, it also contains many other useful parts and pieces like issuance date, expiration date, signature algorithm, issuing company, etc.  Here’s a quick screenshot of the Google.com certificate.  The one on the left shows all the details of what the certificate contains, and the one on the right shows the top-level CA who is responsible for issuing this certificate (GeoTrust Global CA).

Now we know what a certificate looks like, but who’s to say it can actually be trusted?  How would a browser know to accept the certificate from Google?  The answer is found in the list of Trusted Root CAs on your computer.  Here’s a quick snapshot of the Trusted Root CAs on my standard Windows 7 box.  Notice the “GeoTrust Global CA” listed there. 

Since that CA is in the trusted list on my machine, and because GeoTrust Global CA issued the certificate for https://google.com, do you think I had to worry about any pop-up windows warning me about a possible security problem when I visited Google’s website?  Nope!

If you are an awesome company and you protect your web applications using SSL/TLS, you’ll probably want to use one of the trusted CAs listed in the Windows and/or iOS operating systems.  You wouldn’t want your customers to visit your site only to be met with a crazy “We recommend you close this webpage” message. 

Just so you know, Microsoft determines which Trusted Root CAs are automatically loaded into their operating system.  It’s the same story with Apple.  By the way, if you use a BIG-IP to handle all your encrypted traffic, you can configure the list of trusted CAs when you create the SSL profile. 

It can be a daunting task to figure out which CA to use when purchasing a certificate…especially since there are so many to choose from.  Here’s a really cool diagram that shows over 650 organizations that are trusted by Microsoft or Mozilla alone.  As a guide to help you make the right choice, some users will offer a review of various CAs so that you can choose the best one for your needs.  Here’s a partial list from SSLShopper.com:

When choosing a CA, you understandably want to get the most for your money.  As you consider all the aspects of why you want to choose one CA over another, keep in mind the security, trust, and reputation of the CA themselves.  How well does the CA check and validate the information of the buyer prior to issuing the certificate?  How well does the CA protect themselves from being attacked? 

If anyone hacked a trusted CA, they could fake a certificate for any website using that CA and then decrypt all the traffic.  Not cool at all.  I guess the good news is that no one has ever hacked into one of these CAs before…or, have they?  Here are just a couple of examples of CA attacks from recent years:

• The respected COMODO CA (found in both Windows and iOS trusted CA lists) was hacked and subsequently issued certificates for sites like google.com, yahoo.com, skype.com, mozilla.org, etc.
• The TurkTrust Inc CA issued a fraudulent certificate for google.com, and all the major Internet browsers were sent scrambling to revoke that certificate. 

Again, this is a big deal because a user could navigate to what they think is a valid website (maybe they followed a link from a malicious email), and their browser would never warn them about being on the wrong website…at least not until it’s too late.  I’m not trying to freak everybody out here, but I am trying to highlight one of the many aspects of how your Internet traffic stays “secure” today.  I hope this info has helped, and I hope you understand a little bit more than you did when you started reading this article.  Feel free to discuss in the comment section below!