Understanding SSL Certificates for client to server encryption

Back in January I made a post, which I called Part 1 of Understanding Certificates.  In this post I talked primarily about how the server is authenticated to the client by using a “root” certificate that the client already trusts, thus establishing a trust relationship with a website you are at without actually having been there before.  If you haven’t read it, it’s a good overview on how that works.

In this Part 2, I want to talk about the encryption between client and server.

Part 1 was all about authentication of the server, this part (2) is going to talk about the encryption portion.  Encryption is important on many networks to prevent prying eyes from seeing the data being sent.  The larger and/or more un-trusted the network, the greater the need for encryption.  The Internet of course being the largest of all public and un-trusted networks.

First the easy stuff, when you go to an SSL based website, you’re using the prefix of HTTPS in your browser.  Additionally, many mainstream browsers such as Internet Explorer or Firefox will show a “Lock” symbol to show that your connection is locked, and safe:

(Internet Explorer)

(Fire Fox)

Each browser will show it differently, but I think most of the mainstream one will use a little lock icon.  You might also see different colours (Red means bad, white or Green mean good).  While we’re on the subject of colours.  Some SSL certificate providers will provide you with extra security and extra validation, which will make the address bar go green.  In the captures above it’s important to note that Firefox and Internet Explorer use a completely different certificate store.  Internet Explorer uses the built-in Windows Certificate store, while Firefox manages its own.  There are pros and cons to each approach, but both are just as secure.

So how secure are you?

Well, in the details of the certificate, you can check out the encryption level of the certificate by looking at the public key:

 

This certificate used here for passport is a 1024-bit encryption level.  This means that the keys used to encrypt or decrypt this traffic uses a 1,024 character key length.  That means that in order to decrypt this network traffic, you need 1,024 ASCII based characters in exactly the right order.  That’s a tall order to boot!!  Anything less than 1024 at the time of this printing is not considered industry standard encryption.  Hackers have horse-power to crack 512-bit certificates in just a few weeks, this isn’t new news, this has been done back in 2002!  It also states that even 1024 can be cracked, but it would take a lot longer, given the cracking method used is “Brute Force”. It would take a large number of years to crack this, and you’ll notice if you review your certificates, they are only used for 1 year, and then the key is changed with a new certificate, forcing your hacker to start over.

However, with the introduction of this, 2048-bit certificates are already shipping today.  The bigger the number, the harder it will be to decrypt. What’s the hold up?  Processor power.  Not necessarily in your PC, but on your phone, in your router, even on the server processor!!.  Using higher-level encryption, means that each packet sent over the internet needs to be encrypted on one side, and decrypted on the other.  Does your phone have the processor to deal with higher level of encryption? what about servers that process millions of requests per second, that would double the CPU load for decryption/encryption!  So don’t be surprised if you see 1024-bit for a while longer: it’s still considered industry standard.

You may notice that root or chaining certificates last longer.  This is because their public key is typically not out in the open for all to see, and potentially use to hack.  So it’s generally accepted for these higher certificates to have a longer lifespan.

But how does it work Technically?

Let’s dive into how it works.  When you buy a certificate from a 3rd party, they ask for a CSR (Certificate Signing Request).  The website generating the CSR generates two pieces of information:

1. The Public Key
2. The Private Key

The public key is encoded in this request, along with the final public public certificate.  The certificate provider validates that this is in fact the server it’s issuing a certificate for (the more expensive the certificate, the more validation is done).  The private key NEVER EVER leaves the website generating the certificate.  Think of a mailbox that the post office runs that sites outside the convenience store.  the public key is the slot in the top.  Anyone can get access to that to send stuff into the post office, but the key to open and get access to all this sent mail, only the post office has, and never leaves around anywhere.

Once the certificate request is signed, the public key is placed right on the website for all the world to see, and the private key is kept safe inside the certificate store, hidden from view and access only to administrators!

The private key is used to decrypt everything encrypted with the public key, and vice versa.  Additionally, a per-session key is established and everything is encrypted using that as well.  This prevents when the server sends something to the client encrypted with the private key, any listening clients from decrypting it with the very public “public key”. If you want to go deeper,  you can dive into the nitty-gritty details over on Wikipedia on Transport Layer Security.

What if something goes wrong?

If something goes wrong, or something changes, a certificate is revoked.  A client will check the CRL (Certificate Revoke List) embedded in the certificate to see if the current one is still valid.  If a website cert has been compromised, or a name changed, or anything changed, the certificate is revoked and another one issued.  Clients will know which one to use simply by checking the CRL distribution point.

Here we see that Verisign has their CRL hosted up online that anyone can go and see if this cert is revoked or not.  Clients will known not to trust or use a revoked certificate.

Remember, if you end up at a site that has a certificate that you don’t trust and your address bar in Internet Explorer is red (after you mistakenly continued onto the website), you’ll still get the encryption between the server and the client, BUT you won’t know for sure you’re talking to the right server.  So you should ALWAYS make sure you do not continue onto these types of servers.  Even if you *think* it’s going to the right place.  Imagine if it’s not, and you logged in with your username and password.  You just gave your username and password to some random site! 

Be careful out there, look for the lock icon (), look for the https:// in the address-bar, and be  weary sending personal information anywhere!!