TLS and Certificate Handling — Explained in a simpler way

The focus of this writing is to understand what is TLS/PKI and how/why certificates are used.

A certificate is used to guarantee trust between two parties during a transaction.

A certificate ensures encrypted communication between a client and server and also confirms the server is the correct one (i.e. not a fake server or hacked server).

Symmetric Encryption

In the below example, a client is using a Plain-text to sends its User-ID and Password to connect to the server.

However, the Hacker can easily sniff the plain-text message and can now mis-use the user-id and password.

This way of communication is NOT SAFE.

The client needs to encrypt the data before it sends to the server.

Client uses a KEY to encrypt the data and generates random encrypted values.

The Hacker can sniff the encrypted data however it can’t decrypt(i.e. read) the data.

But the issue here is — even the server CAN NOT decrypt the received/encrypted data.

Client has to send the KEY(Step-5) to the server so that the server can use the same KEY to decrypt the data.

Now the Server can use the KEY to decrypt the message. This is called Symmetric Encryption, where both client and server use the SAME key.

However the issue here is Hacker can also sniff the key(Step-6) and can use it to decrypt the messages. This type of encryption is risky and NOT SAFE.

Asymmetric Encryption

Instead of using the same key to encrypt and decrypt the data, Asymmetric encryption uses a pair of keys i.e. Private key and Public key.

A Public key can be shared however a Private key is personal and stored secretly with the owner of the key e.g. a Server generates 2 types of keys, it shares the same Public key to all its clients however it keeps the Private key with it.

The trick here is — one key (whether its Public or Private) can be used to encrypt and the other key is used to decrypt the message. It is not possible to use the same key to both encrypt and decrypt the message.

It is not recommended to encrypt a key by using Private key because all the others having Public key can decrypt the message. Best practice is to use Public key to encrypt and Private key to decrypt.

The main job of Asymmetric Encryption is to securely transmit the Symmetric key of the client to the server and once it is done, client and server can now communicate using Symmetric key/encryption method.

Does Asymmetric Encryption solve Authorization Issues ? If so, why is then Certificate-Agents Used ?

Simply Asymmetric Encryption is NOT sufficient to ensure a full proof Authorization.

The Hacker may try to mimic the server and generate Public and Private key and forward the Public Key to the client.

Client misinterprets this to be a real Server and shares the Symmetric Key and now the Hacker can Hack/decode all the messages coming from client.

This must be prohibited…and this is why the concept of Certificates and Certificate-Issuers i.e. Certificate-Authority(CA) comes into foray.

Is there a way by which a client can verify if the key comes from an Authorized/Authenticated Server ? — Yes, this can be addressed by the use of certificates.

Whenever a Server sends a key to the client, the key normally comes (i.e. Packed) inside a Certificate.

Every certificate has information such as: who the certificate is issued to, who has issued the certificate, validity of the certificate, the list of registered-names of the server etc.

However the issue is, anyone (e.g. a Hacker) can generate a fake certificate and claiming him/her to be Ericsson/Google/Alipay/Microsoft.

The most important part of a certificate is to check the digital signature and check — who signed and issued the certificate.

If you generate a certificate, that’s called self-signed certificate however this is NOT safe and not recommended practice.

How do we then get the certificates signed by an authorized/reliable/legitimate entity and this is where Certificate Authority(CA) comes into picture.

Certificate Authority

Some organizations like Symantec, GlobalSign, DigiCert are authorized to sign digital certificates.

Below are the steps how a certificate is signed by the CAs.

1st — The client/server (who wants its certificate to be signed by CA) creates CSR(i.e. Certificate Signing Request) and sends it to CA.

openssl req -new -key deb.key -out deb.csr -subj “/C=CN/ST=SH/O=debashish, Com/CN=deb.com”

deb.key deb.csr

2nd — The CA verifies the certificate and validates the information.

If a Hacker sends a Fake certificate, the validation shall be failed at CA.

3rd — If validation is successful, then CA signs the certificate and sends it back to the requester.

However the question here is — how does a client/server ensures that a CA is authorized or a fake one. To address this, even the CAs have two types of keys: Public and Private key.

CAs use their Private key to sign the certificates and the Public keys of all the available/registered/authorized CAs are generally in-built with browsers like Chrome/IE/Firefox etc.

Public Key Infrastructure (PKI)

The complete authorization process/infrastructure involving Client, Server and CA is called PKI.

The Client, Server and CA have their own Public and Private keys. CA shares its Public key with Client and Server.

Server sends CSR(Certificate Signing Request) to the CA with its Public Key. The CA uses its Private Key and signs the certificate.

The Server sends a message to the Client with the digital certificate(signed by using CA’s Private Key) and also includes server’s Public Key (Step-5)

Client uses CA’s public key to validate the certificate and then gets the Public Key of the Server.

The server can also request a certificate from the client. Client can therefore send CSR along with its Public Key(Step-7) to get its certificate signed.

CA signs the certificate with its own Private key and sends the signed certificate to the client (Step-8).

Now, the client can send its (symmetric) Public Key and encrypt the packet using the Public Key of the Server and send the packet to the Server (Step-9). It also includes the signed certificate it received from CA.

Server can validate the certificate using the Public Key of CA, then decrypts the packet using its own Private Key and then recovers the Symmetric/Public Key of the Client.

From here on, both client and server can use the same Symmetric Key for encrypted communication of messages.

The whole step is actually called — Public Key Infrastructure.

Thank you :) Feel free to comment out.