The history of SSL/TLS is a history of cryptographic arms races. Each version emerged in response to discovered vulnerabilities, evolving cryptographic best practices, and changing performance requirements. Understanding this evolution is not merely academic—it directly informs which versions to deploy, which to disable, and why.

From 1995 to 2018, the protocol underwent seven major versions, each building upon lessons learned from security incidents, cryptographic research, and implementation experience. Today, only TLS 1.2 and TLS 1.3 are considered secure for production use.

Before diving into each version's details, let's establish a comprehensive timeline that frames the protocol's 25+ year evolution:

The Pattern of Evolution:

Each version transition followed a similar pattern:

1. Discovery: Researchers identify cryptographic weaknesses or implementation vulnerabilities
2. Publication: Attacks are demonstrated and documented (e.g., POODLE, BEAST, CRIME)
3. Mitigation: Short-term workarounds deployed (configuration changes, cipher restrictions)
4. Deprecation: New version released that addresses the fundamental weakness
5. Transition: Industry gradually migrates, browsers phase out support
6. Prohibition: Old version formally deprecated in RFC documents

This pattern has repeated multiple times, and understanding it helps predict how future security issues will be handled.

Release: 1995 (Netscape Navigator 1.1)

SSL 2.0 was the first publicly deployed version of the protocol, shipped with Netscape Navigator in 1995. Despite its pioneering status, it contained fundamental cryptographic flaws that were apparent within months of deployment.

The Cipher Suite Downgrade Attack:

SSL 2.0's most devastating vulnerability was the lack of integrity protection for cipher suite negotiation. An attacker positioned as a man-in-the-middle could:

1. Intercept the client's list of supported cipher suites
2. Modify it to include only weak (40-bit export) ciphers
3. Forward this modified list to the server
4. Server selects the weak cipher, believing it's the client's preference
5. Attacker brute-forces the 40-bit key and decrypts all traffic

This attack was trivial to execute and impossible to detect, fundamentally undermining any security SSL 2.0 claimed to provide.

Release: 1996 (Netscape Navigator 3.0)

Recognizing SSL 2.0's fundamental flaws, Netscape commissioned a complete protocol redesign. SSL 3.0 was substantially different from its predecessor, addressing the known vulnerabilities while establishing patterns that would persist through TLS 1.2.

The POODLE Attack - SSL 3.0's Downfall (2014):

SSL 3.0 remained in wide use for nearly two decades until the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack demonstrated a fundamental flaw in its CBC mode implementation.

How POODLE Worked:

1. SSL 3.0's CBC mode uses block padding that is not covered by the MAC
2. The final padding byte indicates padding length, but other padding bytes are not validated
3. An attacker can manipulate encrypted blocks and observe server behavior
4. By analyzing error patterns, the attacker decrypts data one byte at a time
5. Typically requires ~256 requests per byte to decrypt

Attack Requirements:

• Attacker must inject content (e.g., via JavaScript on a compromised page)
• Victim must be using SSL 3.0 (often through downgrade attacks)
• Attacker must observe encrypted responses

The attack could decrypt session cookies in minutes, enabling session hijacking against major services.

Release: January 1999 (RFC 2246)

TLS 1.0 was the first IETF-standardized version, representing the transition from Netscape's proprietary protocol to an open standard. Despite the version number reset (TLS 1.0 = SSL 3.1), the protocol was almost identical to SSL 3.0 with minor security improvements.

The BEAST Attack - Breaking CBC in TLS 1.0 (2011):

For over a decade, TLS 1.0 was considered secure until the BEAST (Browser Exploit Against SSL/TLS) attack demonstrated a practical exploit against its CBC mode encryption.

The IV Chaining Vulnerability:

In TLS 1.0, CBC mode uses the last ciphertext block of the previous record as the IV for the next record. This predictable IV enables a chosen-plaintext attack:

1. Attacker controls some data in the encrypted stream (e.g., HTTP request headers)
2. Attacker can predict the IV for the next block (it's the previous ciphertext)
3. By crafting specific plaintext, attacker can compare ciphertext with targets
4. After ~256 guesses per byte, attacker recovers secret data (e.g., cookies)

Practical Exploitation:

• Required JavaScript injection on victim's page
• Needed same-origin policy bypasses or websocket exploits
• Could decrypt HTTPS cookies in under 10 minutes

Mitigations:

• 1/n-1 record splitting: Send 1 byte first, then remaining data
• RC4 preference (later deprecated due to RC4 weaknesses)
• Upgrade to TLS 1.1+ which uses random IVs

Release: April 2006 (RFC 4346)

TLS 1.1 was a relatively minor update focused primarily on addressing the CBC IV vulnerability that would later be exploited by BEAST. While important for security, its late adoption meant many systems skipped directly from TLS 1.0 to TLS 1.2.

Why TLS 1.1 Was Short-Lived:

Despite fixing the CBC IV issue, TLS 1.1 had limited adoption for several reasons:

1. Timing: Released in 2006, but TLS 1.2 followed in 2008 with much more significant improvements
2. Minimal New Features: Offered little beyond security fixes; no compelling upgrade reasons
3. Compatibility: TLS 1.2 was backward-compatible, so upgrading past 1.1 made more sense
4. Implementation Lag: Many implementations went directly to TLS 1.2

The Padding Oracle Problem:

TLS 1.1's change to padding error handling was specifically designed to prevent padding oracle attacks. In TLS 1.0:

Padding Error → decryption_failed alert
MAC Error → bad_record_mac alert

An attacker could distinguish between padding and MAC errors, enabling byte-by-byte decryption. TLS 1.1 unified these to always return bad_record_mac, closing this oracle.

Release: August 2008 (RFC 5246)

TLS 1.2 represented a major modernization of the protocol, introducing support for contemporary cryptographic primitives and establishing the foundation for the next decade of internet security. It remains widely deployed and fully supported today.

AEAD: The Cryptographic Advancement:

The most significant improvement in TLS 1.2 was first-class support for AEAD (Authenticated Encryption with Associated Data) cipher suites, particularly AES-GCM:

Traditional Encrypt-then-MAC:

1. Encrypt plaintext → ciphertext
2. Compute MAC over ciphertext
3. Transmit: ciphertext + MAC
4. Recipient: Verify MAC, then decrypt

AEAD (GCM):

1. Single operation: Encrypt and authenticate together
2. Associated Data: Can authenticate headers without encrypting
3. Tag: 128-bit authentication tag
4. Atomic: Cannot be partially processed

AEAD modes eliminated entire classes of vulnerabilities:

• Padding oracle attacks (no padding in stream-mode encryption)
• MAC timing attacks (single atomic verification)
• Encrypt-then-MAC ordering issues (single operation)

Release: August 2018 (RFC 8446)

TLS 1.3 represents the most significant evolution of the protocol since SSL 3.0. After a rigorous 4-year development process involving extensive security analysis, TLS 1.3 emerged as a fundamentally redesigned protocol that is both more secure and more performant than its predecessors.

The Streamlined Cipher Suite Model:

TLS 1.3 radically simplified cipher suite negotiation. Instead of hundreds of combinations, there are only five defined cipher suites:

TLS_AES_256_GCM_SHA384        (0x1302)
TLS_CHACHA20_POLY1305_SHA256  (0x1303)
TLS_AES_128_GCM_SHA256        (0x1301)
TLS_AES_128_CCM_SHA256        (0x1304)
TLS_AES_128_CCM_8_SHA256      (0x1305)

Notably, the cipher suite no longer specifies key exchange or authentication—these are negotiated separately. All suites are AEAD-only; there is no non-AEAD option.

The following comparison provides a detailed feature matrix across all significant SSL/TLS versions, enabling direct comparison of security properties and capabilities:

Key Observations:

1. Mandatory Security: TLS 1.3 eliminates optional security features. Forward secrecy and AEAD are required, not negotiable.

2. Attack Surface Reduction: Each deprecated feature (CBC, RC4, compression) was removed because it had been exploited in attacks.

3. Performance Improvement: Despite stronger security, TLS 1.3 is faster due to the 1-RTT handshake.

4. Simplification: TLS 1.3 has fewer moving parts, reducing implementation complexity and potential for bugs.

The evolution from SSL 2.0 to TLS 1.3 represents 25 years of cryptographic advancement and security lessons learned. Let's consolidate the key insights:

What's Next:

Now that we understand the protocol versions and their evolution, we will examine the security services that TLS provides in detail. The next page explores confidentiality, integrity, and authentication services—how they are implemented cryptographically and what guarantees they provide to applications.