Let's face it, SSL/TLS (HTTPS) is vital to user security and privacy on the Internet. Which is why recent news about SSL/TLS certificates and articles like my last one about surf jacking, "HTTPS: Surf Jacking Makes It Vulnerable ," are troublesome.
The problem, quite simply, is that human intervention is required to verify the authenticity of certain types of certificates. This became apparent when Mozilla changed how its newest Web browser (Firefox 3) handles Web sites with expired or self-signed SSL/TLS certificates. The article "New SSL Policy in Firefox Hurting Tens of Thousands of Sites " on Pingdom's Web site does an excellent job of explaining the changes:
"If you visit a Web site with either an expired or a self-signed SSL/TLS certificate, Firefox 3 will not show that page at all. Instead, it will display an error message, similar to any other browser error (for example a "page not found" 404 message). To get past this error page, users have to go through four different steps before they can access the Web site, which from a usability standpoint is far from ideal."
The error occurs because Mozilla has decided to take SSL/TLS Web page security to the next level, challenging any certificate that isn't in the Web browser's certificate database, has incorrect information, or is expired. This is a good thing; it will make Web browsing and online commerce a great deal safer. In order to understand why, let's take a quick look at the SSL/TLS process.
SSL/TLS consists of two important and independent processes: authentication and data stream encryption. With today's tough Internet environment, it's vital to have strong encryption to protect the data packets as they travel to their destination. Thank goodness that using a SSL/TLS VPN is secure and working properly. The weak link, I'm afraid, is part of the authentication process, so I'd like to focus on that.
Authentication is all about digital certificates, so it might be best to start by describing what a digital certificate is. A digital certificate is a data file that contains information about the Web site's certificate holder and is used to verify that the Web site is indeed what it portrays to be. The Web server's host name, issue and expire time, and the public key for the Web server are just a few of the details contained in a certificate. To look at certificates installed on your computer, use the following paths:
- Internet Explorer: Tools | Internet Options | Contents | Certificates
- Firefox: Tools | Options | Advanced | Encryption | View Certificates
The following image shows certificate details:
I can hear everyone saying that's nice, but it doesn't help me at all. I'm happy to say that understanding the exact details isn't important, but the overview explanation will help make the following concepts easier to fathom. Just remember — digital certificates verify the identity of the Web server to the Web browser that's trying to set up a SSL/TLS connection with the Web server.
Different types of SSL/TLS certificates
There are two major categories of certificates, trusted and untrusted. Trusted certificates are those residing on the Web browser and signed by a trusted certificate authority (CA). In order to understand this, let's say I want to create a trusted Web server SSL/TLS certificate that's signed by VeriSign. a well-known and respected CA. The following example will show the steps I need to take:
Now my Web server has all the required components to set up a SSL/TLS connection with Web browsers. So let's take a look at how a Web browser goes about the SSL/TLS certificate exchange.
Web server/Web browser certificate exchange
Begging your indulgence, I'd like to continue using the above example to explain the certificate exchange between the Web server and Web browser. Since everything is now in place in the example, I can set
up a test SSL/TLS connection. Let's see what happens by following the certificate exchange steps during a SSL/TLS connection setup:
That's how a SSL/TLS certificate exchange works. If you remember anything from the above process, it should be step 4 and the reasons why my Web browser trusted www.mysecuresite.com:
- My Web browser lists VeriSign as a trusted signing CA.
- VeriSign verifies that www.mysecuresite.com is what it claims to be, so my Web browser trusts the Web site as well.
It's vital to realize there's a pre-installed list of trusted certificates on every Web browser. This is done to set up a "chain of trust." This chain of trust starts with the Web browser developers, who include this list of trusted signing CAs in the Web browser installation program. So, it's automatically installed and presumed to be secure and accurate.
Therefore, if everything is as it should be (Web sites using certificates signed by trusted signing CAs) the whole SSL/TLS connection process is automatic. In fact, so automatic that we tend to become complacent about whether or not the connection is indeed encrypted and authenticated. When the automated process breaks, we get into trouble as exemplified by the new Firefox Web browser.
Self-signed certificates aren't automatically trusted
Self-signed certificates are the next most widely used certificates and belong to the untrusted category. This type of certificate requires manual approval and installation on the Web browser. It might be best to walk through a SSL/TLS certificate exchange with a Web server that's using self-signed certificates:
This is where it gets complicated. I have to decide whether I trust this site or not. I can look at all the certificate information and make a decision from that or I can do further research to increase my confidence that the certificate is real. The only way to truly validate the certificate is to get a copy of the self-signed certificate via some other trusted method (fax, e-mail, or even snail mail) and manually verify the electronic certificate with the one you asked for.
I realize it's very cumbersome, but it's the only way to positively determine the validity of a self-signed certificate. I also know that once the window pops up asking whether to accept the self-signed certificate or not, most people automatically accept the certificate. They want to get to the Web site, all the time wishing this window would just go away.
Firefox 3 and raising the bar
It doesn't take much effort to visualize the potential attacks that can be precipitated by malicious self-signed certificates. This is why the people at Mozilla took a stance, and I agree with them. Just raising user-awareness of what it means to automatically okay a self-signed certificate is a huge leap forward.
Thanks for reading through yet another long article. It's a tough topic to understand completely, but that's not required. Everyone just needs to know what his or her options are when the "Unknown Authority" window pops up in the Web browser.
Michael Kassner has been involved with wireless communications for 40 plus years, starting with amateur radio (K0PBX) and now as a network field engineer for Orange Business Services and an independent wireless consultant with MKassner Net. Current certifications include Cisco ESTQ Field Engineer, CWNA, and CWSP.