Digital Certificates and ‘HTTPS’

If we really wanted to thoroughly discuss ‘HTTPS’ and Digital Certificates, then we’d need to talk about cryptography, but don’t worry, because we’re going to go ahead and spare you the grief. Understand this though: strong encryption is about the best guarantor of strong security and privacy that we have at this point.

By now, we’ve all been told to look for the little green or grey padlock that, in most browsers, signifies the presence of the secure variety of the hypertext transfer protocol (HTTPS). We’re told – in as many words – that ‘HTTPS’ means security and that we should make sure we see ‘HTTPS’ in the browser bar before we enter sensitive information into a Web field, especially when entering payment data or banking logins. But what is ‘HTTPS’?

‘HTTPS’ stands for hypertext transfer protocol secure, the secure variety of the hypertext transfer protocol, which, in turn, is the basis of how we move data on the World Wide Web. Basically, connecting to a website via ‘HTTPS’ (rather than the standard ‘HTTP’) means that any data that you trade with that website – whether you’re entering account login information, leaving a comment on a blog, or paying a parking ticket – will pass over the encrypted transport layer security (TLS) or its predecessor, the secure sockets layer (SSL).

Okay, so ‘HTTPS’ means encryption and encryption means security, but, encryption aside, how do I know that I’m communicating with the person or service that I want to be communicating with online?  I’m sure you’ve thought about it: how can you possibly be certain that the site you’re looking at and about to log into isn’t an elaborate fake? Say you’re buying an antivirus product from Kaspersky, how do you really know that your payment information is coming to us and not to some sketchy hacker in a dark room in Romania? Beyond that, how do you know that some third party isn’t eavesdropping on your data transfer? This is where certificates come into play.

You can go ahead and just type ‘HTTPS’ into the address bar on any old site. If the site has a valid certificate, then the server hosting the site will present that certificate to your browser (which has a built-in list of trusted certificate issuers) and nothing really noticeable happens. Simply put, a certificate is the thing that certifies that a site or service is what it claims to be. Depending on the browser, you can click on that little padlock (or its equivalent) to find certain information about the certificate and its issuer. However, if you try to access the ‘HTTPS’ version of a site that does not have a valid certificate, you’ll see an SSL warning like this one:

This warning is just your browser’s way of telling you that it cannot verify the identity of the site’s server you are trying to connect with. You can probably imagine why it’s important to have a certificate system like this to verify that sites and services are who they say they are. If your imagination is failing you, then read up on man-in-the-middle attacks.

Now that you have a rudimentary understanding of ‘HTTPS’ and certificates, you may be wondering how the two things are related. In summary, ‘HTTPS’ means that the information you send is securely encrypted in transit and the digital certificate certifies that this data is going where it is supposed to go.

I’ve explained how certificates work and what purpose they serve, but certificates aren’t just intangible ideas, so what are they? A digital certificate is an electronic statement containing it’s own unique algorithmic digital signature, the identification information for the website or service to whom the certificate was issued, the identification information of the issuer itself, and a validity period indicating when the cert was issued and for how long it is valid. This algorithmic signature is the business-end of a digital certificate. The signature is the part of the certificate that confirms that you are indeed communicating with whatever it is you want to communicate with and that the communication is encrypted en route.

The last piece of the puzzle that needs explaining here are the certificate issuers. A number of organizations sell or issue digital certificates. They are called certificate authorities. GoDaddy, VeriSign, and Entrust are three certificate authorities that come to mind immediately. I could call myself a certificate authority right now and start selling certs right and left if I really wanted to. The problem is that no one would trust my certificates and therefore no one would buy them. That’s the thing about certificate authorities: they’re only good if they’re trusted.

So the way this whole trust thing works is that there is a list of what are called ‘root certificates’. These are trusted by default in most browsers. They also have the power to extend their trust to other certificate authorities. Let’s say that some guy named Larry issues certs and is a root certificate authority. Your browser is going to trust any certificate that Larry issues. Your browser is also going to trust any other certificate that Larry vouches for. There are a whole lot of certificate authorities out there, and this is what we’ve come up with for verifying them. We let the 36-or-so trusted certificate authorities decide which other certificate authorities are trustworthy and everyone lives happily ever after, right? Not really.

It should be acknowledged that the current system of digital certificates is complicated, convoluted, and controversial. Digital certificates and the signatures they contain and the certificate authorities that vouch for them provide the foundation for authentication and trust online. Ironically enough, it’s well known throughout the industry that the current certificate authority and digital signature system is hopelessly broken and woefully inadequate. Yet, here we are, relying upon it to make payments and communicate with one another on a daily basis.

Breaches at large certificate authorities like DigiNotar and Comodo and the revelation that not one but two forged certificates vouched for the Stuxnet virus have clearly shown that a new system is needed. Security researcher Moxie Marlinspike has suggested that his “Convergence SSL” system is the solution to the certificate problem. Despite debuting Convergence at the Black Hat Security conference almost two years ago and its near-universally positive reception, we still rely on the broken certificate system. We’re sort of just assuming the best about the certificates operating in the background as we communicate and spend money online. Every now and then we hear about a breach at certificate authority, we groan and bemoan the problem, and we ultimately move on without fixing anything.

So what can you do? All you can really do is make sure that you are browsing in ‘HTTPS’ when you enter sensitive data, like payment information or login credentials or even email messages. Beyond this, you can click on the padlock or its equivalent in your browser bar and examine the certificate yourself. For the savvy among us, we can stay abreast of the security news and manually revoke trust from certificate authorities when and if they’re compromised. Revoking that trust means that your browser will no longer trust the certificates issued or vouched for by that authority. The best practice is to revoke trust from a compromised certificate authority in your browser settings immediately upon hearing news of a certificate authority breach, but don’t worry too much, because Microsoft, Mozilla, and Google have been pretty quick to act about revoking trust in the past (too bad we can’t say the same for Apple). As long as you stay up-to-date with your browser and operating system patches you’ll be as well protected as anyone against bad and forged certificates.