How HTTPS & TLS 1.3 Actually Work Under the Hood: A Story of Cryptography

1. The Plaintext Internet: Why HTTP Was an Open Postcard

Imagine sending your passwords, credit card numbers, and private emails across the globe written on open postcards. Anyone handling the postcard—your local Wi-Fi router, your Internet Service Provider (ISP), coffee shop hackers, or state transit backbones—could read and tamper with the contents.

That was unencrypted HTTP. In the early web, every packet traveled in plain ASCII text.

HTTPS (HTTP Secure) solves this by wrapping standard HTTP inside TLS (Transport Layer Security)—formerly known as SSL. It guarantees three non-negotiable security pillars: Encryption (confidentiality), Authentication (identity verification), and Integrity (anti-tampering).

"Without TLS encryption, every public Wi-Fi network would be an open broadcast of your session cookies and private keys."

2. The Cryptographic Lockbox: Symmetric vs. Asymmetric Keys

To encrypt gigabytes of data streaming over the network, computers use Symmetric Encryption (like AES-256-GCM or ChaCha20). Symmetric ciphers are blazingly fast because both client and server use the exact same secret key to encrypt and decrypt bytes.

But this creates a classic dilemma: How do a browser in Tokyo and a web server in London agree on a secret key across an unencrypted public internet without an eavesdropper stealing the key?

The answer lies in Asymmetric Cryptography (Public/Private key pairs like RSA or Elliptic Curve Cryptography ECDSA) combined with the mathematical genius of the Elliptic-Curve Diffie-Hellman (ECDHE) key exchange algorithm.

By exchanging public parameters, both sides calculate the exact same shared secret key independently over the wire—without ever transmitting the key itself!

3. Certificate Authorities (CAs) and the Chain of Trust

Even if Diffie-Hellman secures encryption, how do you know bank.com is really your bank, and not a malicious hacker server intercepting your connection?

This is where Digital X.509 Certificates and Certificate Authorities (CAs) step in:

1. Web servers purchase or request a cryptographically signed certificate from a trusted CA (like Let's Encrypt, DigiCert, or Cloudflare).
2. Your operating system and browser ship pre-installed with trusted Root CA public certificates inside their local Trust Store.
3. During the connection, the server presents its certificate chain. Your browser verifies the CA's digital signature using public key math.

4. The TLS 1.3 Handshake Sequence: Shaving 1 RTT of Latency

Legacy TLS 1.2 required 2 full Round Trip Times (2-RTT) of back-and-forth network packet exchanges before a single byte of encrypted HTTP request data could be sent.

In 2018, TLS 1.3 streamlined the handshake down to 1-RTT by combining key exchange and cipher agreement into the very first packet exchange:

• Step 1 (Client Hello): Browser sends supported TLS version, supported ciphers, and its Diffie-Hellman public key share.
• Step 2 (Server Hello + Encrypted Extensions + Cert): Server picks cipher, calculates symmetric master key, sends its public key share, presents its certificate, and finishes authentication.
• Step 3 (Encrypted HTTP Application Data): Symmetric encryption is live! Client sends HTTP GET/POST immediately.

# Terminal Lab: Inspecting TLS 1.3 Handshake live with OpenSSL
openssl s_client -connect infohub.simplyfyy.com:443 -tls1_3 -brief

# Output highlights:
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_256_GCM_SHA384
# Peer certificate: CN = infohub.simplyfyy.com
# Verification: OK