A few weeks ago I decided that I’d write a blog post about SSL and certificates (in particular in terms of websites.) As luck would have it, the recent media outburst caused by the recently revealed Heartbleed bug in OpenSSL makes the post more relevant that I could ever have hoped it would be.
What is SSL?
SSL is an acronym for “Secure Sockets Layer” and is a computer protocol that can be used by 2 systems to communicate with each other securely. This means that no-one else can read the messages passed between the two. This is achieved by encrypting (scrambling) the messages between the two computers. When reading about SSL, you might also see the acronym ‘TLS.’ TLS stand for “Transport Layer Security” and this is essentially a new name for SSL, and you will often see them referred to together as “SSL/TLS” in computer literature.
What is HTTPS?
HTTPS is “HTTP within SSL/TLS.” This means that the web browser communications with the server are using an SSL/TLS connection, which in turn means that the data transmitted between the two systems is encrypted and cannot be read by anyone else. If you have an HTTPS connection, you will usually see a padlock (or some other icon) in the browser address bar to indicate that you’re using a secure connection.
Here’s an example:
What are ‘certificates’?
In the context of website security, a certificate is a way for a website to ‘prove’ that it is legitimate and that it is what it claims to be. How does this work?
Certificates rely on the concept of trust. Any certificate used by any site on the web has been ‘issued’ (created) by someone, and that someone is identified in the certificate itself. The issuer has, in turn, been issued a certificate by some higher authority, and this continues, creating a ‘chain’ of certificates until it ends at a ‘root certificate.’ So as long as you ‘trust’ all the issuers in the certificate chain, you can trust the owner of the certificate you are dealing with.
This all sounds a bit complicated, but you can easily see the certificate chain by using your web browser. For example, using Chrome, you can right-click on the padlock icon in the browser bar, to see a pop up like this:
If you then click on “Connection”, you will see technical information about the SSL/TLS connection with that website:
Click on the “Certificate Information” link and can see some information about this certificate:
Finally, by selecting the “Certification Path” tab, I can see all the certificates in the chain for this particular certificate:
In this case, NAB got their certificate issued by Verisign, who issued their own certificate as they are a ‘root’ Certifying Authority (CA.) So as long as you trust VeriSign, (and you probably should –they are a highly trustworthy CA), then you can believe that the server you are connected to is, in fact “ib.nab.com.au”, and not some rogue site that wants to steal your banking information.
You might have noticed that the certificate status is “This certificate is OK.” There are several mechanisms built into the certificates that allow your browser to ensure that the certificates have not been tampered with, and that they are current. If a certificate (or set of them)is deemed to have fallen into the wrong hands, they can be ‘revoked’ – and then you’ll get a warning from your browser that something is wrong with the certificate. Here’s an example of the kind of screen you might see if there is a problem with a certificate:
If you encounter a warning like this, you should only continue on to the site if you are SURE that it’s OK.
As an aside, certificates can be used for certifying other things than just websites. If you are a Microsoft Windows user, you might encounter a warning message like this:
What has happened here it that Windows has tried to verify the certificate chain for the piece of software, and it cannot follow an unbroken chain of ‘trusted’ certificates to a trusted CA. This means that Windows (and therefore you) cannot be sure of who wrote the software. In today’s increasingly insecure internet, you should be very wary of installing software if you cannot be sure of where it originated.
Putting it all together
So, you’re surfed to an “https://” website, the browser deems the site’s certificate to be good. What happens next?
Using information contained in the certificate, the browser and the remote server can create and share a set of mathematical ‘keys’ which they can use to create an encrypted connection between each other. This, in a nutshell is how your browser creates an “SSL/TLS” connection to the remote server.
In my next blog post, I’ll discuss the different type of certificates which web servers use, what the difference is between them, and why you would choose one kind over another.