The TLS Transition: Versions 1.0, 1.1, and 1.2

TL;DR

TLS 1.0 (RFC 2246, 1999) is SSL 3.0 renamed and standardized under the IETF, with SSL's ad hoc MAC replaced by HMAC — the protocol otherwise inherited SSL 3.0's implicit, predictable CBC IV chaining, which BEAST (2011) exploited via a chosen-plaintext, byte-at-a-time decryption attack. CRIME (2012) attacked a different layer entirely: TLS-level compression leaks plaintext structure through ciphertext length, independent of cipher strength. TLS 1.1 (RFC 4346, 2006) closed BEAST by making the IV explicit and random per record. TLS 1.2 (RFC 5246, 2008) added AEAD cipher suites (AES-GCM), removing the separate MAC-then-encrypt CBC construction that both BEAST and POODLE descend from, for any deployment that actually negotiates them. TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in 2021 over their fixed MD5/SHA-1 PRF and lack of AEAD. TLS 1.2 remains widely deployed but is only as secure as its negotiated cipher suite — CBC suites without constant-time countermeasures, RC4, and static RSA key transport all remain technically negotiable unless explicitly disabled.

From SSL to TLS

Netscape's IETF submission of SSL 3.0 became TLS 1.0 under the Transport Layer Security working group in 1999. The rename reflected a change in stewardship, not a change in cryptographic design: TLS 1.0 is structurally SSL 3.0 with two substantive fixes. First, the MAC construction was replaced with HMAC (RFC 2104):

where $k'$ is the key padded to the hash function's block size, and opad/ipad are fixed constant blocks. This is a formally analyzed construction, unlike SSL 3.0's bespoke MAC. Second, TLS 1.0 introduced a version negotiation and extension framework that later versions build on. What TLS 1.0 did not change was CBC-mode IV handling — and that gap defined its dominant vulnerability for the next decade.

BEAST: Predictable IVs Under Chosen Plaintext

In TLS 1.0, CBC mode chains IVs across records within a connection: the IV for record $i$ is the last ciphertext block of record $i-1$, which has already been transmitted and is visible to any network observer.

Because $E_k$ is deterministic, an attacker who knows $\text{IV}_i$ in advance and can inject chosen plaintext into the same connection turns decryption into a guess-and-compare oracle. BEAST (Browser Exploit Against SSL/TLS, 2011) combines this with a same-origin network position — attacker-controlled JavaScript running alongside the target session, typically via an intercepted or adjacent connection — to align an unknown secret byte (a session cookie) to the last position of a block, then requests encryption of a guess block $G_g$ under the known, already-published IV. Since $E_k$ is a bijection for fixed $k$, a guess $g$ is confirmed correct the moment the resulting ciphertext block matches the previously observed target block:

This reduces recovering one secret byte from $2^8$ blind guesses to at most 256 confirmable trial encryptions, walkable across the whole secret one byte at a time by controlling request alignment. TLS 1.1 closes this by making the IV explicit and randomly chosen per record rather than derived from the previous ciphertext block, eliminating the attacker's foreknowledge of $\text{IV}_i$ before it is used.

CRIME: Compression as a Side Channel

CRIME (Compression Ratio Info-leak Made Easy, 2012) does not attack the cipher at all — it attacks optional TLS-level compression, present as a negotiable feature since TLS 1.0. DEFLATE-family compressors replace repeated substrings with back-references to earlier occurrences within the same window, so compressed length depends on how much attacker-controlled input overlaps with adjacent secret data.

An attacker who can inject a chosen prefix into the same compression context as a secret (a session token, say) submits candidate guesses and observes the resulting ciphertext length — visible on the wire regardless of encryption, since encryption does not hide length:

A guess that matches more of the secret compresses shorter, because the compressor emits a back-reference instead of literal bytes. Testing each possible next byte and keeping whichever produces the shortest output recovers the secret one byte at a time, entirely from ciphertext length — the record's confidentiality guarantee is never broken, because length was never confidential. The fix is disabling compression at the TLS record layer; no protocol version bump was required, and TLS 1.2 deployments universally negotiate null compression today. Compression-based leakage recurs at the HTTP layer as BREACH, a distinct attack against HTTP response compression rather than the TLS record layer.

TLS 1.2 and AEAD

TLS 1.2 introduced negotiable AEAD (Authenticated Encryption with Associated Data) cipher suites, chiefly AES-GCM, which compute confidentiality and integrity as a single operation rather than the separate MAC-then-encrypt-CBC construction SSL 3.0 through TLS 1.1 relied on. AEAD suites have no padding-oracle surface: there is no padding to validate, and no timing or error-based side channel of the kind BEAST and POODLE both exploited. TLS 1.2 also replaced the fixed MD5+SHA-1 PRF with a negotiable, cipher-suite-specified hash — typically SHA-256 — for key derivation.

None of this is enforced by the protocol version alone. TLS 1.2 still permits negotiating CBC-mode suites, RC4, and static RSA key exchange (no forward secrecy) for backward compatibility. A TLS 1.2 endpoint configured to accept its full legacy cipher list remains exposed to CBC timing attacks (Lucky13) and to RC4's known keystream biases — RFC 7465 prohibits RC4 in TLS outright. This is why TLS 1.2 deployments today are only as strong as their explicit configuration: AEAD-only cipher suites, ECDHE for forward secrecy, RC4 and CBC-without-AEAD disabled.

Why 1.0 and 1.1 Are Formally Deprecated

RFC 8996 (2021) deprecates TLS 1.0 and 1.1 outright, not merely discourages them. Both versions hard-code MD5 and SHA-1 into their PRF and handshake integrity, both lack any AEAD cipher suite, and both remain reachable by the BEAST attack class in any implementation that has not back-ported TLS 1.1's explicit-IV behavior. PCI DSS required removing TLS 1.0 from cardholder-data environments by June 2018, and major browsers removed TLS 1.0/1.1 support entirely in early 2020, ahead of the IETF's formal deprecation. Unlike TLS 1.2's exposure, which is a configuration problem, TLS 1.0 and 1.1's weaknesses are structural — there is no cipher suite selection that removes the fixed weak PRF.