SSL/TLS

We had a production issue couple of days back, we had updated our SSL certificate and one of our consumers were not able to call the API due to some extra checks at there end. The certificate authenticity was failing at there end. This made to read more about how TLS works.

Now you might be hearing terms TLS and SSL, both are the same thing. SSL was created by Netscape in 1990's and rebranded to TLS later on.

How does it start?

When setting up a web server to use HTTPS (HTTP over TLS), the server needs to have a digital certificate which contains a public key. This certificate is obtained from a trusted Certificate Authority (CA) like Verisign or Let's Encrypt.

How does it work?

The TLS protocol is composed of two layers: The Handshake Protocol and The Record Protocol.

The Handshake Protocol: ensures that both parties agree on the parameters of the session before any data is transmitted.
* It negotiates what TLS version to use with client
* In selecting the cryptographic algorithms to use such has DHE Diffie Hellman or EC-DHE Elliptic-curve Diffie Hellman, RSA etc
* In handshake protocol we use the Asymmetric cryptography
* It confirms a secret key for symmetric encryption

The Record Protocol: ensures that the data is protected from eavesdropping and tampering while in transit.
* We use the symmetric encryptionin this step
* It encrypts the messages using the secret key established in the earlier step(handshake)
* It decrypts the messages using the same secret key
* It also keep check on the incoming message it has not been tampered

TLS Handshake

1. Client sends a hello message to the server, along with a list of encryption algorithms and other preferences.
2. Server responds with a hello message of its own, and sends its own list of encryption algorithms and preferences.
3. Server presents its certificate to the client, which contains the server's public key.
4. Client validates the authenticity of the certificate by checking its digital signature and verifying that it was issued by a trusted Certificate Authority (CA).
5. Client generates a session key, this session key will be used to encrypt and decrypt the future communication between client and server. Remember this session key currently is on the client side.
6. Client encrypts the session key using the server's public key (which is contained in the server's digital certificate) and sends it to the server.
7. Server receives this encrypted session key and can use it's own private key to  decrypt it, and only the server has access to its private key (read about heartbleed).
8. Client and server now both have the shared session key, the session is now established, they can now exchange data using the agreed-upon encryption algorithm and the session key.
9. That's it, all data exchanged between the client and server during the session is encrypted and decrypted using the shared session key, which is used for symmetric encryption and decryption.

TLDR;

When a client connects to the server over HTTPS, the server presents its digital certificate to the client, and the client verifies that the certificate is valid and issued by a trusted CA. The client then uses the public key from the certificate to establish a secure TLS session with the server, and any data exchanged between the client and server is encrypted using the session key that is negotiated during the TLS handshake.