Https Tls Security: TLS, Certificates, and Encryption Explained for Developers

# TLS 1.3 Handshake (1 round trip — 2x faster than TLS 1.2)

# Step 1: Client Hello
# Client sends:
# - TLS version: 1.3
# - Supported cipher suites: [TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256]
# - Key share: client's Diffie-Hellman public key (anticipating server choice)
# - Random: 32 bytes of randomness

# Step 2: Server Hello + Certificate + Finished
# Server sends (all in one flight):
# - Selected cipher: TLS_AES_256_GCM_SHA384
# - Key share: server's DH public key
# - Certificate: server's public key + domain name + CA signature
# - Certificate Verify: proves server owns the private key
# - Finished: MAC over entire handshake
# Server can NOW derive the session key and start encrypting

# Key exchange (ECDHE — Elliptic Curve Diffie-Hellman Ephemeral):
# client_private * server_public = server_private * client_public = shared_secret
# This math is the magic — both compute SAME secret without transmitting it
# Shared secret → session key → all subsequent data encrypted with AES

# Step 3: Client Finished
# Client: derives same session key, verifies server's MAC, sends Finished
# Connection established. All data: AES-GCM encrypted with session key

# Asymmetric (RSA, ECDSA): different keys to encrypt and decrypt
# Public key: encrypt OR verify signatures (share freely)
# Private key: decrypt OR create signatures (NEVER share)
# Problem: slow — 1000x slower than symmetric
# Use for: key exchange, digital signatures, certificates

# Symmetric (AES-256-GCM): same key to encrypt and decrypt
# Problem: how do two parties agree on the key securely?
# Answer: use asymmetric to establish the symmetric key (DH key exchange)
# Use for: bulk data encryption (fast)

# Why TLS uses both:
# ECDHE: asymmetric key exchange → establishes shared AES key
# AES-GCM: symmetric encryption of all HTTP data
# Best of both: secure key exchange + fast bulk encryption

# Forward secrecy (ECDHE):
# Each session uses fresh ephemeral keys
# Even if server's private key is compromised LATER
# Past sessions CANNOT be decrypted (no long-term private key used)
# Compare: RSA key exchange (no FS) — past sessions decryptable if key stolen

# Certificate chain: leaf → intermediate → root CA

# Your server certificate (leaf):
# Subject: cheatcoders.net
# Public key: [your server's public key]
# Signed by: Let's Encrypt R3 (intermediate)
# Valid: 2026-04-01 to 2026-07-01 (90 days)

# Intermediate CA certificate:
# Subject: Let's Encrypt R3
# Signed by: ISRG Root X1 (root)

# Root CA certificate:
# Subject: ISRG Root X1
# Signed by: itself (self-signed)
# Trusted by: OS/browser certificate store (pre-installed)

# Verification chain:
# Browser has ISRG Root X1 in trust store
# ISRG Root X1 vouches for Let's Encrypt R3
# Let's Encrypt R3 vouches for cheatcoders.net
# ∴ Browser trusts cheatcoders.net

# HSTS (HTTP Strict Transport Security):
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
# Browser: for 1 year, ALWAYS use HTTPS for this domain
# Even if user types http:// — browser upgrades to https:// locally
# Prevents SSL stripping attacks