Why HTTPS Is Truly Secure: A Deep Dive into Encryption, Certificates, and TLS Handshake

HTTPS Overview

HTTP transmits data in clear text, exposing eavesdropping, tampering, and impersonation. HTTPS inserts SSL/TLS between TCP and HTTP, encrypts traffic, authenticates the server with a CA‑issued certificate, and uses port 443.

Hybrid Encryption

HTTPS uses a hybrid scheme: asymmetric encryption exchanges a session key, then symmetric encryption protects all application data.

Symmetric encryption: single secret key, fast, requires secure key exchange.

Asymmetric encryption: public/private key pair, solves key‑exchange problem, slower.

Hash + Digital Signature

Integrity is ensured by hashing the message to a fingerprint. The receiver hashes the received content and compares fingerprints; a mismatch indicates tampering.

Because a hash alone cannot prevent replacement of both content and hash, the sender encrypts the hash with its private key (digital signature). The receiver verifies the signature with the sender’s public key, confirming integrity and origin.

Public key – publicly shared.

Private key – kept secret.

Two uses of public‑key encryption:

Encrypt with the public key, decrypt with the private key → confidentiality (typically for the session key).

Encrypt the hash with the private key, decrypt with the public key → digital signature, proving sender identity.

Digital Certificate Verification

The server’s public key is placed in a certificate signed by a trusted CA. Validation steps:

Hash the certificate fields (public key, usage, issuer, validity) → H1.

Decrypt the CA’s signature on the certificate with the CA’s public key → H2.

Compare H1 and H2; equality means the certificate is trusted.

Certificates form a trust chain: leaf → intermediate CA → root CA pre‑installed in browsers/OS. The client follows the chain to verify trust.

TLS Handshake Overview

The TLS handshake establishes a shared session key through four message exchanges.

RSA‑Based Handshake

1. ClientHello – client sends TLS version, a random ClientRandom, and a list of cipher suites (including RSA).

2. ServerHello – server replies with TLS version, ServerRandom, chosen cipher suite, and its digital certificate.

3. Client validates the certificate, extracts the server’s public key, encrypts a pre‑master secret with it, and sends the encrypted value to the server.

4. Both sides derive the master secret from ClientRandom, ServerRandom, and the pre‑master secret, then switch to symmetric encryption.

RSA Shortcoming

RSA key exchange does not provide forward secrecy: if the server’s private key is compromised, all recorded sessions can be decrypted because the pre‑master secret was encrypted with the long‑term private key.

Diffie‑Hellman (DH) Example

Illustrative numbers:

Alice chooses prime p = 509, generator g = 5, private a = 123; computes A = g^a mod p = 215 and sends p, g, A to Bob.

Bob chooses private b = 456, computes B = g^b mod p = 181, and the shared secret S = A^b mod p = 121; sends B to Alice.

Alice computes S = B^a mod p = 121.

The secret S never travels over the network.

Static DH vs. DHE

Static DH reuses a long‑term private key (typically on the server) and lacks forward secrecy because compromise of that key reveals all past session keys.

DHE (Diffie‑Hellman Ephemeral) generates fresh private keys for each handshake, providing forward secrecy.

ECDHE Handshake

ECDHE extends DH to elliptic curves, achieving comparable security with smaller keys.

Both parties agree on an elliptic curve and base point G.

Each generates an ephemeral private key ( d1, d2) and computes the public key ( Q1 = d1G, Q2 = d2G).

They exchange public keys. Alice computes d1Q2, Bob computes d2Q1; both equal d1d2G. The x‑coordinate of this point is the shared secret.

Because the private keys are temporary and never transmitted, the shared secret cannot be derived by an eavesdropper.

ECDHE vs. RSA in Handshake

After ServerHello, the server sends ServerKeyExchange containing its elliptic‑curve parameters. The client sends its elliptic‑curve public key encrypted with the server’s RSA public key (from the certificate). Both sides compute the pre‑master secret from the exchanged EC points, derive the master secret, and exchange ChangeCipherSpec messages to start encrypted communication.

Certificate Trust Chain Example

When a client receives a leaf certificate for baidu.com signed by “GlobalSign Organization Validation CA – SHA256 – G2”, the client:

Requests the intermediate certificate from the issuer.

Verifies the intermediate certificate is signed by “GlobalSign Root CA”, which is pre‑installed as a trusted root.

Uses the intermediate’s public key to verify the leaf certificate.

Successful verification establishes trust in baidu.com because the root CA is trusted by the operating system or browser.