The Rise and Fall of SSL: From 1.0 to 3.0

TL;DR

Netscape built SSL in 1994 to secure e-commerce over HTTP. SSL 1.0 never shipped — internal review found key exposure and integrity flaws severe enough to scrap it. SSL 2.0 (1995) shipped anyway and was broken by design: an unauthenticated handshake let attackers force weak export ciphers (cipher-suite rollback), and it reused one key for both MAC and encryption. SSL 3.0 (1996) fixed the handshake but still used a CBC padding format that checked only the padding length byte, not its content. That gap sat unexploited for 18 years until POODLE (2014) turned it into a byte-by-byte plaintext recovery attack: an attacker who can force a downgrade to SSL 3.0 and replay modified ciphertext blocks can distinguish valid from invalid padding from the connection's response and, with a 1-in-16 success rate on AES's 16-byte blocks, recover one plaintext byte per ~16 requests. SSL 3.0 was formally deprecated by RFC 7568 in 2015.

Origins at Netscape

Netscape Communications designed SSL to secure HTTP traffic for Netscape Navigator, driven by the emerging need for online payment security. The protocol had to run over an unauthenticated network, negotiate a cipher suite, authenticate the server via certificate, and derive a symmetric session key — the same structural problem TLS solves today, but specified for the first time.

SSL 1.0: Never Released

SSL 1.0 did not ship outside Netscape. Internal and external review identified flaws in the protocol's handling of message integrity and session keys severe enough that shipping it would have left every connection trivially interceptable — no public specification of SSL 1.0 exists, and no server or browser implements it. Netscape moved directly to a public release with SSL 2.0.

SSL 2.0: Broken by Design

SSL 2.0 (1995) shipped with multiple flaws rooted in a single mistake: none of the cipher-suite negotiation messages were authenticated.

• Cipher-suite rollback. The client sends a list of supported ciphers in the clear during the handshake. Because this message carries no integrity protection, a man-in-the-middle can rewrite it to advertise only the weakest available option — commonly a 40-bit export-grade RC4 cipher, mandated weak by then-current U.S. export controls — before the handshake's key material is derived. Both endpoints negotiate the downgraded cipher without detecting the tampering.
• Shared MAC/encryption key. SSL 2.0 derives a single key used for both the message authentication code and the bulk cipher, rather than deriving independent keys per function. This couples the security of integrity and confidentiality, weakening both relative to independent derivation.
• No handshake integrity check. Because no transcript hash or Finished message binds the negotiated parameters to the derived keys, an active attacker's tampering with the negotiation is never verified against what the endpoints actually agreed to.
• Truncation attacks. SSL 2.0 closes the connection using the underlying transport's own close (no signed closure alert), so an attacker who injects a TCP FIN can truncate a response and have it accepted as complete.

SSL 2.0 was formally prohibited in TLS implementations by RFC 6176 in 2011.

SSL 3.0: A Rewrite, With One Gap Left

SSL 3.0 (1996), largely designed by Paul Kocher with Netscape, was a near-total rewrite. It added a Finished message — a MAC over the entire handshake transcript, sent after cipher negotiation — so that any tampering with the negotiated cipher suite is detected before application data flows, closing the rollback attack. It derived independent keys per direction and per function instead of reusing one key for MAC and encryption.

What it did not fix was how CBC-mode block ciphers pad their final block. For a block size $n$, CBC-mode decryption of block $C_i$ is:

The final plaintext block must be padded to a multiple of $n$ before encryption. SSL 3.0's padding specification requires only that the padding length be correct — the padding bytes' content is unspecified and unchecked by the receiver, which strips them and proceeds directly to the MAC check. TLS's later padding scheme fixed this by requiring every padding byte to equal the padding length; SSL 3.0 never received the equivalent patch, because CBC padding oracles as a class weren't published until Vaudenay's 2002 work — six years after SSL 3.0 shipped.

POODLE: The Padding Oracle That Ended SSL 3.0

Padding Oracle On Downgraded Legacy Encryption (2014) exploits that gap directly, but first requires getting a connection onto SSL 3.0 at all.

Step 1 — Force the downgrade. Most clients at the time retried a failed TLS handshake with an older protocol version rather than aborting. An attacker in the network path can simply drop or corrupt TLS handshake attempts, forcing the client to fall back to SSL 3.0 even when both endpoints support a newer protocol.

Step 2 — Exploit the padding oracle. With the connection on SSL 3.0 CBC, the attacker needs a way to inject repeated, attacker-influenced requests containing a secret (a session cookie is the standard target) — typically via JavaScript run in the victim's browser, which repeats the request while the attacker manipulates ciphertext on the wire each time.

Take the ciphertext block immediately preceding the secret's block, $C_{i-1}$, and replace it with an attacker-chosen block $C'$, leaving the target block $C_i$ untouched. The server computes:

and reads $P'_i$'s last byte as the padding length $L$. Because SSL 3.0 checks only that $L$ falls in the valid range $[0, n-1]$ and never verifies the other padding bytes' content, roughly 1 in 16 random choices of $C'$ (for AES's 16-byte block) produce an $L$ the server accepts as valid padding. An accepted request and a rejected one are distinguishable — different error behavior or connection state — giving the attacker a binary oracle.

On the request where padding is accepted, the attacker learns:

Since $C'$ is attacker-chosen and $L$ is now known, $D_k(C_i)[n-1]$ is recovered directly. The original plaintext byte follows from the real preceding block $C_{i-1}$, which the attacker already observed on the wire:

By repeating the request with the secret shifted one byte at a time into the block's last position (controlled via request padding, e.g. the URL path length), the attacker recovers the secret one byte at a time, at an average cost of 16 requests per byte. A session cookie of a few dozen bytes is recoverable in well under a minute of automated requests.

Aftermath

POODLE did not reveal a new class of attack — Vaudenay's padding oracle theory predated it by twelve years — it showed that SSL 3.0's specific padding format made the attack practical against real browsers via a forced downgrade. The immediate mitigation was TLS_FALLBACK_SCSV, a signal letting a client tell the server "this is a fallback attempt," so the server can reject silently-downgraded handshakes. The definitive fix was elimination: SSL 3.0 support was pulled from major browsers within months, and RFC 7568 prohibits SSL 3.0 negotiation entirely. TLS 1.3 removes CBC-mode ciphers from its suite list altogether, closing this attack class at the protocol level rather than patching the padding check again.