How HTTPS Secures Your Web Traffic: A Simple Story of Encryption and Authentication

In-depth Introduction to HTTPS Working Principle

Because HTTP transmits data in clear text, it suffers from three major security risks: eavesdropping, tampering, and impersonation. HTTPS was created to eliminate these risks by adding encryption, authentication, and integrity verification.

Risk 1: Eavesdropping – third parties can intercept and read the content.

Risk 2: Tampering – third parties can modify the intercepted content.

Risk 3: Impersonation – third parties can masquerade as a legitimate communication party.

HTTPS involves many concepts such as SSL/TLS, digital certificates, digital signatures, encryption, authentication, public and private keys. To illustrate these ideas, we use a simple story about Bob and his three friends Pat, Doug, and Susan.

Bob's Story

Bob generates a pair of keys: a public key and a private key. He keeps the private key secret and distributes copies of the public key to Pat, Doug, and Susan.

When Susan wants to send a message to Bob, she encrypts the plaintext with Bob's public key, ensuring that only Bob can decrypt it with his private key.

To protect the message from tampering and impersonation, Susan also creates a hash of the plaintext, encrypts the hash with her private key to produce a digital signature, and sends both the ciphertext and the signature to Bob.

Bob verifies the signature by decrypting it with Susan's public key to obtain the hash, then compares it with a hash he computes from the received plaintext. If the hashes match, the message is authentic and unaltered.

This exchange demonstrates the concepts of encryption (confidentiality) and digital signatures (authentication and integrity).

Later, an attacker named Jerry intercepts Bob's public key intended for Doug and attempts to impersonate Bob. Because the public key was transmitted in clear text, it can be spoofed.

To solve this, Bob obtains a digital certificate from a trusted Certificate Authority (CA). The CA signs Bob's public key with its own private key, creating a certificate that Bob can safely distribute. Recipients use the CA's public key (pre‑installed in browsers) to verify the certificate and obtain Bob's authentic public key.

HTTPS Communication Process

The HTTPS protocol combines HTTP with SSL/TLS. The TLS handshake establishes a secure channel using the following steps:

The browser connects to the server on port 443, sending a list of supported encryption and hash algorithms.

The server selects compatible algorithms and returns its digital certificate (self‑signed or issued by a CA).

The browser validates the certificate: it checks the issuing CA, verifies the signature, ensures the domain matches, and confirms the certificate is not expired.

The browser generates a random value R, encrypts it with the server’s public key, and sends the encrypted R to the server.

The server decrypts R with its private key.

Both parties now share R, which is used as the symmetric key to encrypt and decrypt the actual HTTP payload.

Only the initial handshake uses asymmetric encryption (public‑key cryptography) because it is computationally expensive. All subsequent data transfer uses fast symmetric encryption.

Note 1: The first five steps constitute the TLS handshake, primarily authenticating the server’s certificate. After the handshake, symmetric encryption handles the bulk of the communication.

Note 2: SSL/TLS is the core security module of HTTPS. TLS evolved from SSL (TLS 1.0 = SSL 3.1, TLS 1.1 = SSL 3.2, TLS 1.2 = SSL 3.3). It operates on top of TCP and includes the TLS Record Protocol (for data integrity and confidentiality) and the TLS Handshake Protocol (for authentication).