HTTPS Explained: Protocols, Handshakes, and Certificates in Secure Web Communication
Aliaksei Kankou
HTTPS (Hypertext Transfer Protocol Secure) is HTTP protected by TLS (or legacy SSL) over TCP. Before any application data flows, the client and server establish a transport connection, verify identity with certificates, agree on a session key, and then encrypt every request and response.
Introduction to HTTPS
HTTPS is a specialized version of HTTP designed to ensure secure communication over the internet. It accomplishes this by utilizing advanced security protocols such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL), which safeguard data exchange between web servers and clients, including web browsers. To facilitate the transfer of data, HTTPS employs TCP as the transport layer, which ensures reliable and efficient delivery of information.
Compared to plain HTTP, HTTPS adds a TLS layer between HTTP and TCP for encryption and authentication.
TLS Version
In this walkthrough we use TLS 1.2. TLS 1.3 is generally regarded as an improvement upon TLS 1.2 rather than a fundamental departure from it, so TLS 1.2 remains a solid reference for understanding the classic handshake flow.
TCP Handshake
TCP prioritizes establishing a reliable connection between two devices before transmitting any data. It achieves this through a three-stage process, commonly known as a 3-way handshake:
- The client sends a synchronization request (SYN) accompanied by a connection request.
- The server responds with an acknowledgement (SYN-ACK) of the connection request, along with its own synchronization request.
- The client confirms the connection (ACK), and both devices are ready to exchange data.
Certificate Validation
- ›The client sends a Client Hello message to the server to initiate the TLS connection.
- ›The server responds by sending its digital certificate to the client.
- ›The client validates the certificate before proceeding with the connection.
When establishing a secure connection, the client must validate the server's digital certificate. This process confirms that the client is interacting with the intended server and protects against man-in-the-middle attacks. The client checks that the certificate was issued by a trusted certification authority (CA), that it has not expired, and that the subject name or subject alternative name matches the domain name of the server.
Once the certificate is deemed valid, the client can proceed with the connection, confident that it is communicating securely with the intended server.
Session Key Exchange
The client sends an encrypted session key
During secure connection setup, the client extracts the public key from the server's digital certificate and uses asymmetric encryption to securely share a symmetric session key. The client generates this session key, which encrypts and decrypts all data transmitted during the session. The session key is encrypted with the server's public key — only the server's private key can decrypt it.
Public key encryption is secure but computationally expensive for large payloads, so after the session key is exchanged, symmetric encryption handles the bulk of data transmission. Once encrypted, the client sends the session key to the server.
The server acknowledges the session key
The server decrypts the session key using its private key. Both parties now share the same key for encrypting and decrypting transmitted data. From this point forward, all exchanged data uses this session key.
Data Exchange
Sending Request
To initiate data exchange, the client encrypts its HTTP request and sends it to the server. The server receives the encrypted message and decrypts it using the session key.
Receiving Response
Upon receiving the request, the server processes it and sends back an encrypted response. The client decrypts the response using the same session key.
The Full Interaction Diagram of HTTPS
The diagram below combines every phase — TCP handshake, TLS handshake, certificate validation, session key exchange, and encrypted application data — into a single end-to-end view of a secure HTTPS connection.
Aliaksei Kankou
Lead Full-Stack Engineer and Cloud Architect with a Bachelor's degree in Software Engineering and 15+ years of experience.