Curious TechieDev Toolbox
← All Guides/CRYPTOGRAPHY & SECURITY•9 min read

What is SSL/TLS & How Does HTTPS Work?

An in-depth guide to modern Transport Layer Security: asymmetric handshakes, certificate authority trust chains, and Certificate Transparency.

ⓘKey Takeaways
  • TLS (Transport Layer Security) is the modern cryptographic successor to legacy SSL (Secure Sockets Layer), securing HTTP web traffic under HTTPS.
  • TLS provides three core cryptographic guarantees: Privacy (symmetric encryption), Integrity (message authentication codes), and Authenticity (X.509 digital certificates).
  • TLS 1.3 (RFC 8446) reduces handshake latency to a single round-trip (1-RTT) and eliminates obsolete, insecure cipher suites (RC4, 3DES, CBC mode).
  • Public Key Infrastructure (PKI) relies on hierarchical trust chains anchored by pre-installed Root Certificate Authorities (CAs).
  • Certificate Transparency (CT, RFC 6962) mandates public append-only cryptographic Merkle trees where all publicly trusted certificates must be logged.

1. What is SSL vs TLS?

While the term SSL (Secure Sockets Layer) is still widely used in marketing, SSL 2.0 and 3.0 were deprecated decades ago due to cryptographic vulnerabilities (such as POODLE and BEAST).

Modern encrypted web communications use TLS (Transport Layer Security), currently standardized at version TLS 1.3 (RFC 8446). TLS operates directly above TCP (or UDP in HTTP/3 via QUIC), encrypting all application-layer payloads (HTTP headers, cookies, query parameters, HTML/JSON).

2. The TLS 1.3 Handshake (1-RTT)

TLS 1.3 simplifies the cryptographic handshake from two round-trips down to a single round-trip (1-RTT) using Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange:

1. Client Hello: Client sends supported cipher suites + ECDHE key share.
2. Server Hello: Server picks cipher suite + sends server key share + X.509 Certificate + Signature.
3. Shared Secret Derived: Both parties calculate symmetric session key (K_session).
4. Encrypted Data: Instant encrypted HTTP requests and responses begin.

3. X.509 Certificates & CA Chains

Web browsers verify server authenticity through hierarchical digital signature chains:

  • Root CA: Self-signed certificate pre-installed in operating system / browser trust stores (e.g. DigiCert Global Root G2, ISRG Root X1).
  • Intermediate CA: Delegated certificate authority signed by the Root CA used for daily certificate issuances to prevent exposing the Root private key.
  • Leaf / Server Certificate: End-entity certificate binding the domain name (via Subject Alternative Names) to the server's public key.

4. Certificate Transparency (CT) Logs

To prevent rogue Certificate Authorities or compromised credentials from issuing unmonitored certificates, RFC 6962 requires every public TLS certificate to be submitted to public, verifiable, append-only Merkle tree logs.

Browsers will reject any HTTPS connection if the presented certificate lacks valid Signed Certificate Timestamps (SCTs) proving it was publicly recorded.

5. Production TLS Hardening Checklist

1. Enforce TLS 1.3 / 1.2 Only: Completely disable TLS 1.0, TLS 1.1, and all SSL ciphers.
2. Enable HSTS with Preloading: Send Strict-Transport-Security: max-age=31536000; includeSubDomains; preload to defeat SSL stripping attacks.
3. Automate ACME Renewal: Use Let's Encrypt / ZeroSSL automated ACME client renewals every 60 days.