Transport Layer Security (TLS) Zero to Hero .. Part-1

9 min readApr 15, 2024

In an era marked by escalating cyber threats and data breaches, ensuring the security and integrity of digital communications is paramount. TLS emerges as a formidable solution, offering robust authentication and encryption capabilities to protect sensitive data in transit. I’ll try to explain all aspects from the very basic so that the concept is understandable without prior knowledge. We’ll see why we need this and how it is done today. We’ll see some packet captures as well for the same.

Why do We need this ?

What happens when you open a browser or an application in laptop or mobile device ? Your browser or application sends a DNS requests to the DNS server asking the IP address corresponding to domain (e.g. www.google.com) and DNS server provides the IP address of google.com.

Now client (your browser, application) sends requests to the server and server responds with answer. But the data is transferred via internet which is public network and people can capture the packets that is sent by server to your device or vice versa. If the packets are NOT encrypted, all privacy is gone, other people will know everything that you are doing in the internet. Also when you try to reach out google.com, how are you sure that you are reaching to google.com , Some computer in the internet can claim to be google.com and responds to your requests. How do you identify that you are really talking to google.com, NOT a malicious computer? So here comes two fundamental requirements-

There must have some way for the client to verify that it is talking to the intended server(e.g. google.com), NOT some other malicious server claiming to be intended server (e.g. some server in the internet claiming that it is google.com). Optionally, server also may verify if server is talking to intended client.
Data transfer between server and client should be encrypted, so that no one else can make out the meaning of the data. Only client and Server should be able to decrypt the data.

Let’s tackle the first problem first. How do we verify the identity of a server?

How do we solve similar problem for human? We have social security card or some form of standard identity card e.g. passport, driving license etc. to verify that the the person is really the person who he or she is claiming to be. Also note that we trust identity card only if identity cards are issue by some trusted authority. Exactly the same analogy applies in the digital world. World Wide there are few organisations (e.g. digicert, global sign) that are approved to be certificate Authority (CA). Those are analogous to the trusted authority that issues human identity cards. A cryptographic certificate can be obtained for a digital entity like Server or Client from those CA, after providing the ownership evidence. Hold on to your curiosity on the cryptographic certificate, I’ll explain shortly. Now that CA has provided a certificate (like human identity), during client server communication, each other can share their certificate to identify themselves. Note that usually client verifies server certificate, but server may or may not verify clients certificate. But how client (my computer, mobile, laptop etc.) would know the certificate of that server? May be organisation maintaining the server can publish the server’s certificate and client can store that certificate. But there can be millions of servers all over the world and does that means client has to store millions of certificate ? Doesn’t feel practical.

Introducing Chain of Trust

To overcome the problem of storing millions of certificates, chain of trust methodology is used. In the diagram you can see Trust is anchored in the root certificate and there can be multiple layers of Intermediate Certificate Authority (ICA) where root certificate signs the ICA, one ICA signs next layer of ICA and finally a certificate for a device or server will be signed by the previous layer of ICA. Can you see the chain ? The root certificates are self signed certificates of authorised CA (e.g. digicert, globalsign etc.). Client need to store only the authorised CA’s root certificate. If there are 100 approved CA in the world, then client need to store 100 root certificate only. Server, while presenting the identity will share entire chain of certificates and client will verify the chain of certificates i.e one is signed by the next in the chain and finally reaches to the root which is self signed by the CA. Now if the root of the chain matches with any of the client’s trusted root certificates, client can be sure that server’s identity is correct. In some cases server also verifies clients certificate (e.g. zero trust network access), but majority of the use cases are client verifies server’s certificate chain.

Have you noticed that I have introduced a new term “signed by” ? This is where the digital signature comes in to picture. Earlier I used another term cryptographic certificate, now it’s time to unravel those.

Introducing Digital Signature

You can draw the analogy with the human here too. A document, paycheque etc. are signed by the human and we validate the signature to identify the authenticity of the document or paycheque. Similarly in digital world too a document or some data can be digitally signed and validated. This involves two party, sender signs some data and sends data along with the signature and the receiver, after receiving the data , verifies the signature. Data is valid only if signature matches. Just like human, when you go to a bank with a cheque, bank already have your stored signature to validate the signature on the cheque. Similarly for digital signature also one party have something stored related to other party to validate the signature. And that something is the cryptographic Key. Digital signature involves asymmetric key pair, called private and public key. It’s called asymmetric, because one key can decrypt the data encrypted by other key. That is, if some data is encrypted using public key, that data can be decrypted only by the corresponding private key and vice versa.

There are multiple algorithms available for asymmetric key. Few popular ones are RSA (Rivest-Shamir-Adleman), DSA (Digital Signature Algorithm), ECDSA (Elliptic Curve Digital Signature Algorithm), EdDSA (Edwards-curve Digital Signature Algorithm), DH (Diffie-Hellman) etc.

Here is a linux command to generate RSA and ECDSA key pair. There are advantages and disadvantages of each types of key pairs.

RSA Key: 
 openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:4096
 openssl rsa -pubout -in private_key.pem -out public_key.pem

ECDSA Key:
  openssl ecparam -name prime256v1 -genkey -noout -out private_key.pem
  openssl ec -in private_key.pem -pubout -out public_key.pem

From the key pair name itself you can understand that private key is never supposed to be shared and public key is the one that is supposed to be shared externally. That means if computer A & B wants to exchange encrypted data between them and they need to share public key with each other.

We talked about encryption keys, but haven’t talked about digital signature yet. Most important point you need to remember is that digital signature is NOT encryption and the purpose is NOT to encrypt the data, rather purpose is to make sure that the data sent from one party to another party is not corrupted or altered.

To create a digital signature of some data, first a hash is generated using hash algorithm like SHA256, SHA384, SHA512, BLAKE2 etc. Then the generated hash in encrypted using the private key of the sender. Usually RSA or DSA algorithm is used for the hash encryption. Once digitally signed data is received by the receiver, hash is generated again from the received document using same algorithm. Also signature is decrypted using sender’s public key . If decrypted hash and re-generated hash matches, data is intact and further processing can be done.

Very important point to be noted here is that to verify the signature, receiver must need to have sender’s public key. Now that we understand digital signature, it’s time to explain certificate.

Here Comes Digital Certificate

We have discussed, at the beginning, that the digital certificate is the identity of a digital entity. We also discussed some trusted authorities (CA) issues this certificate. We even discussed chain of trust where one certificate is signed by another and finally chain ends with a root certificate of a trusted CA. Now it’s time to revel what exactly the certificate is. It is nothing but the public key of a digital entity along with few other details, digitally signed by some ICA or CA. Let’s say we are planning to host a killer service www.mykillerservice.com . Now we can generate a cryptographic key pair of our choice and then get the public key signed by the some renowned CA e.g. digicert, globalsign etc., of course we have to prove them that we are the owner of www.mykillerservice.com and then only CA will sign our public key. This signed public key is our certificate. We’ll also get the certificate chain i.e. all signing certificates that lead to root certificate .

Whenever any client wants to connect to our server, server has to present the chain of certificates i.e. certificate of mykillerservice.com, ICA2 certificate, ICA1 certificate and root certificate. Client will validate that the certificate chain is correct. This is nothing but the digital signature validation of each certificate up to root certificate. And finally client will validate that root certificate if of one of the CA that client trusts and that completes the certificate validation by client. In some cases server also validates client’s certificate chain. For example let’s say some of your office service might allow only office laptop to be able to connect to those service. In that case, a certificate for your laptop along with the entire certificate chain will be installed in your laptop and laptop will present the certificate chain to the office server . Server will validate that client’s certificate chain and connection from the laptop will be accepted only if client can provide certificate chain that is trusted by server. When both client and server validates certificate chain, it is called Mutual Transport Layer Security (mTLS). You can get certificate chain of any server using the following openssl command.

 openssl s_client -showcerts -connect www.google.com:443 </dev/null

Replace google.com with any website of your choice. you'll get certificat
chain of that website.

Your computer, laptop mobile etc. has pre installed root certificates of all CA. When you browse any website, server sends certificate chain and your browser validates those chain and also check that the root certificate matches with one of the pre installed root certificate.

So, we have solved the first requirement. Based on the certificate chain, we can identify the correct server. But there is some issue. Certificates are public information. I can obtain all certificates of any server using the openssl command shown above. So can’t a hacker obtain certificate chain of say google.com and run one server that present those google’s certificate to fake google.com ? Not possible and the trick lies in the asymmetric key.

Also we haven’t yet discussed our second requirements yet. How to encrypt the data that is exchanged between server and client. I have captured those details in another article. Link is given below.

Transport Layer Security — part 1
Transport Layer Security — part 2
Transport Layer Security — part 3