Cracking the Code of SSL and TLS – Part 1
Part 1 – Decoding the basics
Do you ever have the feeling that someone just said something to you and yet you have no idea what they just said?
Encryption has been around for centuries. The word comes from the Greek “kryptos” (meaning hidden or, secret). It’s one of those topics that stirs up images of espionage, eavesdropping and perhaps skulduggery or other nefarious deeds.
The challenge for many people in the world of IT is that when engaging in a conversation on this subject (errr, encryption, not spying), unless you are some kind of CISO, firewall guru, or some other kind of security specialist, you quickly realise that you need a crash course in order to avoid losing your way in the discussion.
Maybe the next few paragraphs will help…….
Let’s begin with a few fundamentals. What are we actually talking about here?
In today’s IT infrastructures the application traffic is encrypted using a protocol called Secure Sockets Layer, or SSL. To be pedantic, SSL has evolved during the last few years and has been replaced with something called Transport Layer Security, TLS. But I frequently find that most people still use the term “SSL” generically.
If you didn’t already know, the “S” in HTTPS refers to “secure” and this is provided by TLS. In other words, almost every time you use your web browser to visit a website these days, your traffic will be encrypted using TLS. This includes everything from your personal on-line banking, social media, and even YouTube. More importantly, it is also used by business applications like email, SharePoint and OneDrive, etc. hosted by Microsoft Office 365, or other SaaS providers like Salesforce, Workday, Box, ServiceNow and so on.
To put it bluntly, TLS and/or HTTPS is the new TCP.
How does it work?
Let’s pretend you and I are going to have a secret conversation. Before we actually start our encrypted dialogue, we have to go through a short sequence of important exchanges.
First of all, there needs to be some kind of trust between us. If I am going to have a secure conversation with you, I need to make sure that you are who you say you are. I might not have met you before and even if I have, how do I know what appears to be you isn’t actually somebody else in disguise?
So, how do I decide that you are who you say you are?
Well, when traveling from one country to another, you take your passport with you. This document contains sufficient biometric data to prove to the border guard that you are the person described in the passport. Because the passport was issued by the government’s passport office of your home country, and the border guard has a list of countries and governments that can be trusted, the guard compares with his list, recognises that the passport is genuine, and allows you to enter.
If we were to really stretch this analogy, the list that the guard has, consists of public examples of different passports and their governments.
In SSL parlance, the passport is called a certificate and the government office who issued the passport is called the certificate authority, or “CA”. The guard’s list is known as a certificate store.
Therefore, if I check your passport, to confirm the picture, name, age, etc. matches everything I expect, and I recognise the country of origin of the passport, then I’ll be satisfied that I can trust you.
Of course, if I don’t think the photo is a good likeness, or I don’t recognise the passport country, issuing government, or the passport is past it’s expiry date, then I’m not going to trust you.
No trust, no talk.
One more thing while we’re on the subject. Do you remember how you got your passport? Yes, of course! You filled in a form with all your details, added a photo, etc. sent it to the passport office, along with some money, and within a short while your new passport arrived back with you. Think of this form as a certificate signing request, or “CSR”.
Still with me? Good! Because we now trust each other, let’s talk about SSL and TLS encryption.
First of all, we need to agree on what code (or cipher) to use for encryption. In really simple terms, the “cipher” might be a substitution of letters from the A-Z alphabet, where you take every character and substitute with another letter further along in the A-Z sequence.
Finally, because we both know that the same cipher could be known by other people, we also need to agree on a unique key for our conversation so that the cipher is implemented in a way that no-one else who may be listening in, can recognise.
For this substitution cipher in our example, the “key” is how far along the sequence you make the substitution. In other words, you start out with ABCDEFGHIJKLMNOPQRSTUVWXYZ and then if the key is 5, the new alphabet is FGHIJKLMNOPQRSTUVWXYZABCDE. This means that the letter “A” is replaced with “F”, “B” is replaced with “G”, and so on through to “Z” which is replaced with “E”.
If we have another conversation later on, we could agree on the same cipher, but we would use a different key. This would mean that even if someone guessed the cipher and key from the previous conversation, the subsequent conversation would not be able to be decrypted using the old key. Because the key is different each time, we call it a session key.
Here’s another scenario.
What happens if the only way I can have a secret conversation with you is to talk to somebody else, who in turn relays the conversation to you? This might seem a bit strange, but in the world of secrets, it’s not so unusual.
But how would this be handled? Simple! So long as I trust the “middle man”, and the middle man trusts you, we can set up two separate, secret conversations. The setup process is exactly the same as before, except I’m now talking to the middleman, who in turn is passing on my words to you. The response from you comes back to me via the “trusted man in the middle”. But in both cases, the conversations are still encrypted.
Of course, I have hugely over-simplified things in my examples. In the world of SSL/TLS things are more complex, but hopefully you get the general idea of what’s involved, and the terminology used.
To summarise so far, we have;
- Certificate – something to say that I am who I say I am.
- Certificate Authority, CA – a recognised/trusted official body who issues certificates.
- Certificate Signing Request, CSR – a form that includes details describing a new certificate to be created and issued by a CA.
- Certificate Store – a list of certificates and their CAs that can be trusted.
- Cipher – a type of encryption.
- Session Key – a unique key used to apply encryption of data.
- Trusted Man in the Middle – someone acting as a go-between and who also has a certificate.
OK, so we now have all the basic terminology that we need for the next step in my explanation.
Tune in next time for part 2 where we will apply this knowledge to a real-world scenario.