It’s very easy to get bogged down in terminology when it comes to staying secure on the internet.
“SSL, TLS, Certificates, RSA, SHA256, keys, authorities, signing, protocols”
If you have heard of some of these terms but can’t remember what they are then this blog is for you! Each of these are large topics in themselves and it’s often hard to see how they all fit together to make things secure when you are browsing the web. So let’s start with a refresher of why we would do any of this in the first place, and then take a look at the difference between a regular HTTPS connection, and a connection with Mutual TLS.
“Transport Layer Security (TLS) is a data encryption technology that provides secure data transfers”
To get us started, let’s define TLS as the magic protocol that lets HTTP become HTTPS (Secure HTTP or HTTP over SSL/TLS).
What does it mean to be secure?
When you send information to another computer, for example sending your password to Facebook, you want two questions answered to feel safe:
- Can someone else view my data in transit?
- Is the person receiving my data who I think they are?
Let’s break down these two questions and see what security features are used to ensure satisfying answers to both these questions.
1. Can someone view my data in transit ?
Everyone can see what you send. So make sure what you’re sending is not readable!
When you send your username and password from your computer to Facebook’s servers, the packets of information can be easily viewed. A malicious person does not need any advanced hacking skills to be able to view all the information being sent. Someone sitting in a cafe with you using the wifi could take two minutes to download a programme to read everything that everyone in the cafe is sending.
When you navigate to a website that uses HTTP, the packets you send are not encrypted. This means the text of your password is fully readable to, for example, the person sitting in the cafe with you.
Browsers are kind enough to warn you when your information is travelling in plain text, HTTP. It’s sensible to heed this warning, even if you aren’t entering credit cards or passwords. This is because it’s also possible a malicious person has added information into the data you are receiving, for example editing a web page that is returned to change some information like a phone number or bank account. As we will see later, you are not fully secure until all of these browser warnings have been resolved.
Encryption solves this problem, and is a large part of SSL/TLS. Encrypting your messages does not prevent the packets of information from being visible, but rather it makes the contents meaningless to anyone intercepting them. That hacker on your cafe wifi network can still see what you are sending, but it is scrambled in such a way to become meaningless to them.
This encryption is achieved with Public and Private keys. Messages encrypted with the public key can only be decrypted by the private key. And vice versa. If you encrypt a message with a public key, you can be confident that only the private key holder will be able to decode your message. Anyone can get the public key, but only one person should hold the private key – in this case, only Facebook would own this private key.
These keys are generated using something called a Cryptosystem – cryptographic algorithms which are designed to be near impossible to decipher. There are many different types of cryptosystems, a common one is called RSA. You do not need to learn too much about how these work (other than to avoid ones that can be easily deciphered). A tool called ssh-keygen allows you to easily generate keys from the command line, specifying which cryptosystem to use:
$ ssh-keygen -t rsa
Keys can be sent in many different formats such a text or binary form but the main thing to know is that they are just a simple piece of information, as we can see in the example below:
So heading back to our original scenario, the first step to being secure is now complete by using public and private keys to encrypt our data. We can be confident that no one, for example the cafe hacker, is able to decrypt and read our data, even if they view the packets. However the second step to being secure is still not complete. If we were accessing a site with this public private key encryption, we could still receive an error:
This leads us to our second part of being secure – who are you sending your data to.
Is the person receiving my data who you think they are?
Encryption is meaningless if the bad guys have the key!
There’s no use having a clever coded message with cryptographically generated public and private keys if the person with the key to the code is malicious. In this scenario we can see that the user’s password is well encrypted during transit, keeping it safe from malicious users like our cafe wifi criminal all the way to its destination. However the destination is not Facebook as we expected but rather a malicious entity pretending to be Facebook who can now decrypt the message.
Just like unencrypted data, browsers are good at warning you that the recipient or website that you might send data to is not who you might think. We can see that the data is encrypted (https rather than http in the url) but yet we still have loud red warnings.
We can read this warning as “Sure, your message is encrypted, but the person with the key to decrypt it is not who you think it is”. If you see this message you are still in danger. You are sending well encrypted data, but you may be encrypting everything with the public key of a hacker, not the website you expected, like Facebook. And since the hacker may have the key to decrypt your data, you are almost as vulnerable as you were when you were using http, and sending your data in plain text. The webpage will usually contain something that looks like this to make you jump through hoops if you are still adamant to use the website.
The aspect of SSL/TLS that deals with identity is called Certificates.
Certificates: proof of whose public key you are using
Certificates are just a public key with identity information.
The last step in the security process is how we verify who a public key belongs to. This is done with a certificate.
A certificate is really just a public key (from our key pair discussed above), but with the added important piece of information of who it belongs to. Here’s a rough example. You can see that the public key on the left, is contained inside the certificate on the right.
A Certificate adds some extra information to the public key such as the domain (e.g. facebook.com) that issued the key, an expiry date and information on who issued the certificate, known as the Certificate Authority. A good certificate can not just be created with a terminal command, you need to request it from a real-world entity, a business called a Certificate Authority (CA). Our browser trusts the certificate is telling the truth about who the public key belongs to if it trusts the Certificate Authority (CA).
A certificate authority is a real life entity, for example DigiCert. When a website like Facebook requests the creation of a certificate, they send DigiCert their public key. DigiCert will then do some background checks to confirm the domain belongs to the person who made the request, and that the person who made the request holds the corresponding private key. They might even check the phone numbers and physical addresses of Facebook are legitimate. Once they are satisfied, they will sign the certificate using their private key. What signing really means is that they take a ‘hash’ of the full certificate, then encrypt it with the private key. A breakdown on the technical side of how this is done with Hashing algorithms, such as the common SHA-256 can be found here.
The reason this Certificate Authority method can be trusted can be thought of in the same way that we trust an ID card. If a police officer asks you for your name, they don’t really have a good reason to trust you when you give it to them. But if you show them an Identification card that links your name to your face, then they will believe it – if the ID is issued by an authority they trust like your government.
In the same way that a police officer implicitly trusts a passport and a licence issued by a government authority, your browser implicitly trusts certificates that are signed by a handful of specific Certificate Authorities that have been proven to be legitimate.
Your browser ships with the public keys of all the trusted Certificate Authorities. As long as the certificate of the site you are viewing can be traced back to one of these trusted authorities, then the certificate will be deemed valid.
Any security system will have a weakness. In the same way that a licence might be forged, there will be occasions when a certificate is issued that is not trustworthy. Maybe the private key was stolen and no longer secure or the Certificate Authority business was found to be corrupt. In these cases the certificate will be revoked, and added to a Certificate Revocation List, which details all certificates that should no longer be trusted.
Putting it together to form HTTPS
By using keys to encrypt the data we have answered our question:
Can someone else view my data in transit?
And because Facebook sends us their certificate and our browser can confirm that the certificate authority that signed the certificate is trusted, we have also answered our question:
Is the person receiving my data who I think they are?
When both of these aspects are in place you will see something like this with a successful padlock. We are now safe!
Making you prove who you are too.
In all these scenarios it’s only been the server, Facebook, who needed to prove their identity. There was never a reason for you as a consumer to prove who you are (until you reach a login screen for example). Mutual TLS just means that both sides communicating must prove their identity with a certificate. The person making a request now has to send a Client Certificate.
You may see Mutual TLS used when the server you are accessing is something that contains very private data such as an API for medical data. This sort of server may not wish to be accessed by everyone on the internet and instead remain inaccessible by default, granting access to only a small limited list of trusted consumers by issuing them with a certificate.
So if you ever need to connect to a server via Mutual TLS you should now know this means that both parties are providing a certificate – their public keys that have been signed by a trusted authority who has given their word that the public key belongs to you.
So what exactly is SSL/TLS?
SSL/TLS brings encryption and certificates together to ensure that your data being sent is sent to the right person, and is not readable by any malicious parties along the way. SSL(Secure Socket Layer) and TLS (Transport Layer Security) are the specific protocols used to achieve everything we have been talking about – encryption and certificates. SSL is merely the name given to the old version of the protocol, and TLS is the name of the new and most used version. Confusingly, when TLS came out, people still defaulted to calling it SSL, so you will often see it referred to as SSL/TLS. The protocols define specifics around how the keys are used to prove to both sides that they can trust each other. For further information on this it’s worth learning about the specifics of this process called a handshake.
So we’ve come to the end of the line in our journey to ensure that our data is safe.
We’ve answered the question: can someone else view my data in transit? And we can now be satisfied that they can’t – if we encrypt our data properly, turning HTTP into HTTPS. We’ve also answered the question: Is the person receiving my data who I think they are? We know that we can trust who we are sending data to if they have a valid certificate that was issued by a trusted certificate Authority.
If there’s one final thought to take away it is to trust our browsers when they warn us something is wrong – even if you’ve forgotten everything you knew about SSL and TLS.