Why do some people call it SSL (Secure Socket Layer) and others TLS (Transport Layer Security) Nowadays we use those names interchangeably but the truth is SSL is just an older term
TLS is a protocol that ensures:
– only the sender and receiver can read messages,
– sender and receiver can identify each other,
– messages cannot be changed while being transferred.
This article will present a short story of Bob and Alice . This will help us understand why we need TLS and the basics of how it works.
Here are Bob and Alice:
They already know that sending plain text messages over the internet can be dangerous because they can be intercepted by other people. Therefore, they want to find the best way to encrypt their messages.
Now, they have a choice as there are two types of encryption they could use – symmetric and asymmetric.
Symmetric encryption is based on a special word which is used to encrypt and decrypt messages. In other words, there is a secret phrase used to encrypt and decrypt data and this phrase is called a KEY – we will use this term from now on.
When referring to symmetric encryption one most likely means a variant of AES (Advanced Encryption Standard) The newest LTS1.3 supports only 3 encrypting algorithms – 2 variants of AES (e.g AES128, AES256 where number indicates symmetric key size) and ChaCha20 (do not worry, I have never heard of ChaCha either…)
Back to our story… Bob decided to try the symmetric approach first. He made up a key and used it to encrypt his messages making them secure and unreadable to anyone who doesn’t know that key.
As a result, he achieved an acceptable level of security but Alice cannot understand any of it, because she’d also need to to know the key that Bob used to encrypt his messages with.
When Bob realized she couldn’t understand anything, he decided to share the key with Alice as his initial and unencrypted message.
That’s when a new character appeared… Mallory, who managed to capture that message, obtain the key and decrypt all their private messages.
Bob had to find a safer way to exchange the symmetric key. That’s when he decided to try the other approach – asymmetric encryption.
In case of the asymmetric approach, Bob and Alice both have their own pair of keys: public and private. The public key is meant to be shared with anyone, while the private key should remain known only to its owner.
The power of this type of encryption is that messages encrypted with the public key can only be decrypted using the matching private key, while messages encrypted with the private key can only be decrypted with matching public key.
It’s as if you would use one key to open your house’s door, a different one to close it, and the other way around.
Even though it looks like you can use public and private keys interchangeably there is a significant difference between the two. Private key is mathematically a private key and cannot be replaced by a public key. You can recover a public key using a private key but not the other way around.
Bob created his own key pair, kept the private key for himself, and sent the public key to Alice as a plain text message since it’s safe for anyone to see it.
Then, Alice created her own key pair, and shared the public key with Bob.
Bob encrypted message containing the key used in symmetric encryption using Alice’s public key and only Alice can decrypt it because only she has the corresponding private key – we call it a „key exchange”. After that both Alice and Bob knew the secret key and could continue their conversation using symmetric encryption
Why not always use asymmetric encryption?
Asymmetric encryption is slower and requires larger key size to achieve the same level of security.
This method does not include encrypting entire messages or files like movie.mp4. Instead, data is divided into multiple chunks which are encrypted and decrypted individually and later stitched back together. Symmetric encryption is much simpler in this matter.
This approach to key exchange is called “RSA key exchange” because it is using RSA cryptography. Nowadays, TLS 1.3 does not support RSA key exchange anymore. I’m using RSA throughout the article for simplicity as RSA can do everything: encrypt, decrypt, sign, validate signatures, and key exchange.
The current implementation of TLS requires using DH (Diffie Hellman) key exchange. In fact, it is not really an „exchange” – in this algorithm both sides of communication generate some public and private values, exchange public parts and calculate a key on their own side ending up with the same key for symmetric encryption, better called as „key agreement”.
There are other variants of this algorithm using Elliptic Curves as a mathematical method to end up with the same key on both sides. It is called ECDH (Elliptic curve Diffie Hellman).
As we can see in rfc8446 section-2, there is no support for DH or ECDH but a variant of them with letter E at the end – DHE and ECDHE where E stands for „ephemeral”. DHE and ECDHE variants both require to generate new keys for every new connection, e.g. in case of the RSA key exchange a new key pair is generated whenever there’s need to exchange a symmetric key. Why is it important?
Imagine that Mallory records every encrypted data sent between Bob and Alice. He doesn’t understand any of it now but after 5 years could steal Alice’s private key, and then be able to decrypt all of those key exchanges. This way, he could obtain the symmetric keys that were used and decrypt every single message that was sent in those last 5 years. However, in case of the ephemeral approach none of the private keys used for key exchange are stored, so there is nothing to steal. This guarantees what is called in cryptography „perfect forward secrecy”.
Now, it looks like Bob and Alice achieved their goal of secure communication…
… but then Mallory strikes again by intercepting their key exchange communication:
Bob sends his public key to Alice but Mallory captures this message and pretends to be Alice so he sends his own public key back to Bob. They exchanged keys and started their communication. Then, Mallory did the same with Alice. As a result, Bob and Alice both exchanged their keys with Mallory.
Neither Bob nor Alice were aware of Mallory’s interception and started their conversation:
Bob wanted to send a message to Alice saying: „Hey, I have some secrets to tell you”, but it went to Mallory instead, Mallory had the right keys and could decrypt all messages. After that, Malory could do two things:
- Read secret messages using keys exchanged with Bob, then encrypt this message using the key exchanged with Alice and forward it to her. In that case, Bob and Alice can talk for hours while being unaware of the fact that someone is reading their messages.
- Drop Bob’s message and send his own message to Alice while pretending to be Bob.
These types of attacks are called „Man in the middle attack”. In order to prevent that from happening we need a way to identify the person sending a message, like we identify people using ID cards. An ID card contains personal information and a photo, so someone can compare the photo to an actual person and confirm that this ID belongs to him. We trust that the government institution which issued this ID has done their work well.
In the IT world, those ID cards are called Certificates and include (among other things): owner information, a public key, and a signature – which is really important as it guarantees that the information in this certificate is trustworthy and wasn’t changed.
Before going any further, we need to understand two things:
What is hashing – hashing means calculating a fixed-sized value from other values. For example, we can take a whole 500 pages long book and generate 64 characters long hash value out of the whole text. This hash value looks to us humans like garbage but it’s not. Those 64 characters are unique for those 500 pages of text, changing just one letter will generate a completely different hash value. Hashing algorithms in cryptography are assumed to be one-way which means there is no practical way to recover the original data from the hash value.
In TLS 1.3, the hashing algorithm used is most likely SHA-2 (SHA256, SHA384, or SHA512).
For example, a hash value from text
„Hey, my name is Muniek” = „064d19817d983f5afc7406914e61426c5de79a40a4d6e1ce0f06d87b1d1670eb”
and after changing just one letter to an uppercase:
„Hey, my name is MunieK” = „2ec314aba71492045babd66b57e312b616031ac77b38e5d0cb3f516006bdf9d5”
How basic signing (creating a signature) works – Bob wants to send a message to Alice in a way that makes it possible for Alice to confirm it was really sent by Bob. Be aware that signing does not mean encryption. Signing is for verifying the authenticity and integrity of a message.
Bob can send his message using plain text and attach another version of that same message but encrypted with his private key. Once Alice receives the message, she can use Bob’s public key (assuming that Alice is sure this public key belongs to Bob) to decrypt the encrypted message and compare it with the plain text version. If they’re the same, it means the message was not changed and it must have been sent by Bob because only Bob had the right private key to encrypt it. Encrypting the whole message and attaching it to the original message seems impractical so instead we encrypt just the hash value of that message and some padding (pkcs v1.5 padding). This approach is called “digest”.
We need another character in this story, a character that is known and trusted by Bob and Alice and ideally by everyone else, let’s call him Ted.
Ted’s role is to create certificates for other people.
Bob wanted to have a valid and trusted certificate, so he sent a signed request with his identity information and public key to Ted and asked him to create a certificate, this request is called CSR (certificate signing request).
Ted validated that Bob is really Bob and all informations provided in CSR are correct, then used those informations to create a certificate, and then really important – Ted signed this certificate using his private key.
Alice after receiving certificate form Bob verified whether it was signed by Ted by calculating hash value of this certificate, and comparing to the signature decrypted with Ted’s public key, beacuse of that Alice is sure that she can trust informations in this certificate including Bob’s public key and safely send messages decrypted by this key because only true Bob can decrypt those messages – only Bob has the corresponding private key.
The word „trust” is important here – whole TLS security after all depends on the simple trust that Ted (CA – Certificate Authority) has done his job right.
Let’s imagine that Mallory creates a CSR claiming he owns google.com and globally trusted CA (trusted by all modern operating systems) somehow signed it, now Mallory can do man in the middle attack every time Bob or Alice tries to open gmail.com, google.com, youtube.com, etc.
And… those things happen from time to time in real life and this is one of the few reasons why the internet is not completely secure.
Bob and Alice finally achieved a ‚good enough’ level of security. Now they want more people to use this method to communicate with each other, everyone in the city creates their own key pairs and certificates signed by Ted. Tens of thousands of people communicate securely using TLS
but then Mallory breaked into Ted’s house and stole his private key, created thousand of valid and trusted certificates, pretending to be whoever he wants.
People know that every single certificate issued by Ted must not be trusted. They need a new CA but right now they do it in the right way.
Ted created a new key pair and certificate and signed it using his own private key (that certificate is called self-signed – there are no other CAs, he is the source of truth, there is no certificate above this certificate and that’s why is it also called a root certificate).
Then he created a few other certificates and key pairs and signed those with his first, root certificate, those certificates are called intermediate certificates. Private key from the root certificate is kept in a safe and used e.g. only once every 5 years to generate new intermediate certificates.
Intermediate certificates will be used to sign other people’s certificates, called client certificates. Instead of one private key to sign all of the client’s certificates, Ted uses many private keys from intermediate certificates, and in case one of them will be compromised, only part of certificates from Ted will become unsafe, only those signed by this single certificate.
This pattern of client certificate signed by an intermediate certificate signed by root certificate is called „certificate chain” or „chain of trust” (can be more than one intermediate certificate in between)
Now when Bob sends his certificate to Alice she is unable to verify if this is a valid certificate, because Bob’s certificate was signed by one of the intermediate certificates which Alice doesn’t know. Bob needs to send his certificate and every intermediate in between and only then Alice can see that Bob’s certificate was trusted/signed by intermediate certificate and this certificate was trusted/signed by the root certificate which Alice trusts herself, and that’s it!
This whole process is a simplification of how a TLS handshake looks like, from now you will be able to understand more complex articles 🙂