SSL/TLS: How Internet Encryption Works
SSL/TLS (Secure Sockets Layer / Transport Layer Security) is the encryption technology that protects data traveling between your browser and a web server. Every time you see a padlock icon in your browser's address bar, TLS is actively encrypting your connection — preventing eavesdroppers from reading your passwords, credit card numbers, or personal data. The evolution of SSL/TLS from Netscape's first implementation in 1995 to today's TLS 1.3 is a story of cryptographic arms races and the relentless pursuit of both security and performance. CDNs play a critical role in TLS deployment, handling TLS configuration at edge servers worldwide.
What Is the History of SSL and TLS?
The journey from unencrypted web traffic to today's TLS 1.3 spans three decades of cryptographic innovation:
- SSL 1.0 (1994, never released): Designed by Taher Elgamal at Netscape Communications, SSL 1.0 was never publicly released due to serious security flaws discovered during internal review. Elgamal is often called the "father of SSL."
- SSL 2.0 (February 1995): The first publicly released version, shipped with Netscape Navigator 1.1. It introduced the concept of encrypted web sessions but had several vulnerabilities, including susceptibility to man-in-the-middle attacks and weak MAC (Message Authentication Code) construction.
- SSL 3.0 (November 1996): A complete redesign by Paul Kocher (who later co-designed the DES cracker). SSL 3.0 was substantially more secure and became the foundation for TLS. It served the web well for nearly 18 years until the POODLE attack (2014) forced its deprecation.
- TLS 1.0 (January 1999, RFC 2246): The IETF standardized TLS as the successor to SSL 3.0. Despite the name change, TLS 1.0 was essentially "SSL 3.1" with minor security improvements. The rebranding from "SSL" to "TLS" reflected the protocol's transition from Netscape's proprietary standard to an open industry standard.
- TLS 1.1 (April 2006, RFC 4346): Added protection against CBC (Cipher Block Chaining) attacks and explicit initialization vectors. Relatively minor update, often skipped by implementations.
- TLS 1.2 (August 2008, RFC 5246): Major upgrade introducing AEAD (Authenticated Encryption with Associated Data) cipher suites, SHA-256 hash functions, and more flexible signature algorithms. TLS 1.2 remains widely deployed and considered secure when properly configured.
- TLS 1.3 (August 2018, RFC 8446): The most significant TLS revision, developed over 4 years with 28 drafts. TLS 1.3 removed all insecure algorithms, reduced the handshake to 1 RTT (from 2 RTT in TLS 1.2), and added 0-RTT resumption for repeat connections. It was championed by Eric Rescorla and represents the current state of the art.
How Does the TLS Handshake Work?
The TLS handshake is the cryptographic negotiation that establishes a secure connection. In TLS 1.3, the simplified process works as follows:
| Metric | Edge Processing | Origin Processing | Improvement |
|---|---|---|---|
| Latency (p50) | 8–15 ms | 120–300 ms | 15–20x faster |
| Cache Hit Ratio | 85–95% | N/A | Reduces origin load |
| TLS Handshake | 1–5 ms (nearby PoP) | 50–150 ms | 10–30x faster |
| Bandwidth Cost | $0.01–0.04/GB | $0.05–0.12/GB | 3–5x cheaper |
| Availability | 99.99% (multi-PoP) | 99.9% (single DC) | 10x fewer outages |
- Client Hello: The client sends supported TLS versions, cipher suites, and a key share (its half of the key exchange). Unlike TLS 1.2, the client proactively sends key material in the first message, saving a round trip.
- Server Hello: The server selects a cipher suite, sends its certificate (proving its identity), its own key share, and immediately sends its Finished message — all in one flight.
- Client Finished: The client verifies the server's certificate, computes the shared secret, and sends its Finished message. Application data can be sent alongside this message.
The shared secret derived from both key shares is used to generate symmetric encryption keys (typically AES-256-GCM or ChaCha20-Poly1305) for the remainder of the connection. This "hybrid" approach — asymmetric cryptography for key exchange, symmetric for data encryption — balances security with performance.
What Types of TLS Certificates Exist?
| Type | Validation Level | Issuance Time | Cost | Best For |
|---|---|---|---|---|
| DV (Domain Validation) | Proves domain ownership | Minutes | Free-$50/yr | Blogs, small sites |
| OV (Organization Validation) | Verifies organization identity | 1-3 days | $100-300/yr | Business websites |
| EV (Extended Validation) | Rigorous identity verification | 1-2 weeks | $200-1000/yr | Banks, e-commerce |
| Wildcard | Covers all subdomains (*.domain.com) | Varies | $50-500/yr | Multiple subdomains |
| SAN (Multi-Domain) | Multiple domains on one cert | Varies | $100-400/yr | Managing several domains |
How Did Let's Encrypt Change Everything?
Before 2015, obtaining a TLS certificate required paying a Certificate Authority (CA) $50-300+ per year and navigating a complex manual process. This cost barrier meant that only 30% of web pages used HTTPS by the end of 2015.
Let's Encrypt, launched in April 2016 by the Internet Security Research Group (ISRG), changed everything by offering free, automated certificates via the ACME (Automatic Certificate Management Environment) protocol. The impact was transformative:
- By 2020, Let's Encrypt had issued over 1 billion certificates
- HTTPS adoption jumped from 40% (2016) to 95%+ (2025) of web page loads in Chrome
- Google began using HTTPS as a ranking signal in 2014, further incentivizing adoption
- Browsers started marking HTTP sites as "Not Secure" (Chrome 68, July 2018)
CDN providers leveraged Let's Encrypt (and their own CAs) to offer automatic TLS for all customers. Cloudflare's "Universal SSL" (2014) provided free HTTPS to all plans, and most CDN providers now handle certificate issuance, renewal, and deployment automatically at the edge.
How Do CDNs Handle TLS at the Edge?
CDN TLS architecture involves several components that work together:
- Edge TLS Termination: The CDN terminates TLS at the edge server closest to the user. This means the TLS handshake latency is minimized (5-20ms instead of 100-200ms to a distant origin). The edge server decrypts the request, serves cached content or forwards to origin.
- Origin TLS (Full/Strict): The CDN re-encrypts the connection between edge and origin server, ensuring end-to-end encryption. "Full (Strict)" mode validates the origin certificate, while "Flexible" mode allows unencrypted origin connections (not recommended). For advanced configurations, see CDN Mutual TLS.
- OCSP Stapling: Instead of clients checking certificate revocation status with the CA (adding 100ms+ latency), the CDN edge server "staples" a recent OCSP response to the TLS handshake, eliminating the extra round trip.
- Session Resumption: CDNs use session tickets and TLS 1.3 PSK (Pre-Shared Key) to enable 0-RTT connections for returning users. This is especially impactful for mobile users with high-latency connections.
- Security Headers: CDN providers inject HSTS (HTTP Strict Transport Security) headers, ensuring browsers always use HTTPS for future connections. HSTS preloading (submitting domains to browser preload lists) eliminates even the first insecure request.