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.
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
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
* 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
hellomessage to the server, along with a list of encryption algorithms and other preferences.
Serverresponds with a
hellomessage of its own, and sends its own list of encryption algorithms and preferences.
Serverpresents its certificate to the client, which contains the server's public key.
Clientvalidates the authenticity of the certificate by checking its digital signature and verifying that it was issued by a trusted Certificate Authority (CA).
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.
session keyusing the server's public key (which is contained in the server's digital certificate) and sends it to the server.
Serverreceives this encrypted
session keyand can use it's own private key to decrypt it, and only the server has access to its private key (read about heartbleed).
servernow 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.
- 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.
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.