Preferably we want to navigate the internet in the most secure way possible. These days luckily most site implement SSL/TLS protocol (also known as HTTPS) which is an encryption-based protocol which makes it hard to decypher data sent over the internet. SSL/TLS takes care of:

• protecting data through encryption;
• initiation of authentication to verify identity of the parties through a handshake;
• verify data integrity stays intact and no intermediate (data) tampering has occured.

Certificate

TLS works with a certificate. This certificate is issued by a certificate authority (CA) and contains information like domain name, expiration date, CA's digital signature and a public key. The public key is paired with a private key and used for the encryption and decryption of the data. The private key is kept secret and is stored on the origin server. The private key can decrypt data that is encrypted with the public key.

Handshakes

So how do we establish a secure connection? Behind the scenes there are two steps:

1. TCP handshake - a connection is made to the IP address of the server;
2. TLS handshake - encryption is setup with the webserver to protect the data that is sent.

TCP handshake

Transmission Control Protocol (TCP) handshake is also known as the three-way handshake due to the 3 steps to open the connection:

1. The client sends a SYN packet to the server in order to initiate the connection.
2. The server responds to that initial packet with a SYN/ACK packet, in order to acknowledge the communication.
3. Finally, the client returns an ACK packet to acknowledge the receipt of the packet from the server. After completing this sequence of packet sending and receiving, the TCP connection is open and able to send and receive data.

TCP manages the sending and receiving of all your data as packets. TCP guarantees delivery or it will not acknowledge

TLS handshake

A TLS handshake takes place when communication over HTTPS takes place. This can be a user that navigates to a website, API calls or DNS queries. A TLS handshakes occur after the TCP handshake.

During the course of a TLS handshake, the client and server together will do the following:

• The client and the server negotiate TLS versions and the type of cipher suite (set of encryption algorithms) to be used in the communication;
• Authenticate the identity of the server via the server’s public key and the authority’s digital signature (information from the TLS certificate);
• Generate session keys that are used for symmetric encryption after the handshake is completed (a key is exchanged to be used in future encrypted communications).

TLS 1.2 handshake example shows the 2 roundtrips made to fulfill all the checks to setup a secure connection.

client-server roundtrip 1

• client hello: the client wants to initiate communication and sends information to the server like a list of SSL/TLS versions, supported encryptions algorithms (cipher suite), compression methods and a random string (client random).

server-client roundtrip 1

• server hello: server returns the agreed SSL/TLS version and encryption algorithm, the compression method and a random string (server random);
• certificate: it also sends the certificate and public key so the client can verify the server identity;
• server hello done: the server sends the client confirmation tat the "server hello" is done.

client-server roundtrip 2

• client key exchange: client checks the validity of the received server certificate with CA and generates a premaster key which is encrypted with the public key the server sent earlier. This is sent to the server to verify it's capability to decrypt the premaster key (assymetric encryption);
• change cipher spec: based on the random values exchanged earlier (client random, server random and premaster key) the client is able to generate session keys, so it letting the server know it has switched to a secure connection state;
• finished: the client sends it's first encrypted message of the secure connection (which is also the last message of the handshake process) letting the server know the handshake is finished.

server-client roundtrip 2

• change cipher spec: all internal steps have been completed on the server, like the server has checked it can decrypt the premaster key with the private key and session keys have been generated from the random values exchanged earlier (client random, server random and premaster key). It will let the client know that all future communication will be done using the symmetric shared key;
• finished: the server sends the last message of the handshake process letting the client know the handshake is finished.