SSL 3.0 was 18 years old when POODLE killed it in 2014. During those 18 years, browser vendors and server operators had continued shipping it as a fallback for compatibility, long after TLS 1.0, 1.1, and 1.2 had superseded it. The POODLE attack - Padding Oracle On Downgraded Legacy Encryption - showed that an attacker who could force a TLS connection to downgrade to SSL 3.0 (possible through a man-in-the-middle who made TLS connections appear to fail) could decrypt HTTP cookies from that session in about 256 requests. The attack killed SSL 3.0 in browsers within months. But SSL 3.0's death was just the most visible point in a decade-long process of breaking and replacing the cryptographic foundations of HTTPS.
The history of SSL/TLS vulnerabilities is the history of how academic cryptography, practical implementation flaws, and protocol design mistakes interact in deployed systems at global scale. The attacks - BEAST, CRIME, BREACH, POODLE, FREAK, Logjam, DROWN, ROBOT - each targeted different layers: CBC mode padding, compression, RC4 keystream bias, RSA PKCS#1 timing oracles. The response to each attack shaped the TLS 1.3 specification, which addressed most of these attack classes by design. Understanding the vulnerabilities is understanding why TLS 1.3 is designed the way it is.
SSL: Netscape's Protocol
SSL was designed by Netscape in 1994 to secure credit card transactions on the early web. SSL 1.0 was never published; SSL 2.0 (1995) had fundamental security flaws including the ability to downgrade cipher suites to weak versions, no protection against message truncation, and MAC key reuse. SSL 3.0 (1996) addressed most of SSL 2.0's problems. The IETF standardized SSL 3.0 with minor changes as TLS 1.0 in 1999. TLS 1.1 followed in 2006, TLS 1.2 in 2008.
Throughout this evolution, older versions remained enabled for compatibility. Browser vendors maintained SSL 3.0 support so that old servers would still work. Server operators maintained old TLS versions so old browsers would connect. This backward compatibility, maintained for legitimate reasons, created the downgrade attack surface that most of the subsequent decade's attacks exploited.
BEAST (2011): The CBC Attack
The Browser Exploit Against SSL/TLS (BEAST) attack, demonstrated by Thai Duong and Juliano Rizzo at ekoparty 2011, exploited a weakness in the way TLS 1.0 implemented CBC (Cipher Block Chaining) mode encryption. In CBC mode, each plaintext block is XORed with the previous ciphertext block before encryption. TLS 1.0 used the last block of the previous record as the IV (initialization vector) for the next record - which was predictable, because the attacker could observe the ciphertext.
The attack allowed an attacker who could inject JavaScript into the victim's browser (via a man-in-the-middle or cross-origin content injection) to iteratively decrypt HTTP cookies by crafting chosen plaintexts and observing which ones matched specific ciphertext blocks. The attack required the attacker to be in a man-in-the-middle position on the network, limiting its practical scope. BEAST was mitigated by switching to RC4 (not vulnerable to CBC mode attacks) or by implementing the "1/n-1 record splitting" fix that was already known but not universally deployed. TLS 1.1 and 1.2 fixed the IV generation.
CRIME and BREACH (2012-2013): Compression Oracles
CRIME (Compression Ratio Info-leak Made Easy) exploited TLS-level compression. TLS optionally supports compressing data before encrypting it; CRIME showed that an attacker who could observe the length of compressed, encrypted traffic and inject chosen text into the request could iteratively recover plaintext by observing compression ratio changes. When the attacker's injected guess matches actual secret content, compression produces a shorter output. The attack required the attacker to be in a man-in-the-middle position and able to make the victim's browser send many requests. TLS compression was disabled in browsers and servers.
BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) adapted the same oracle technique to HTTP-level compression (which CRIME mitigations did not affect). BREACH exploited gzip compression in HTTP responses - a ubiquitous performance optimization. The attack required the target page to reflect user input in the response alongside a secret (like a CSRF token), and for HTTP compression to be enabled. Both conditions were common. BREACH required more requests than CRIME but was not dependent on TLS-level compression. Mitigations included disabling HTTP compression (expensive performance trade-off), adding CSRF token randomization, and rate limiting.
POODLE (2014): SSL 3.0's Death
The POODLE attack, published by Bodo Moller, Thai Duong, and Krzysztof Kotowicz at Google in October 2014, exploited the CBC padding behavior of SSL 3.0. Unlike TLS, which validates PKCS#7 padding precisely, SSL 3.0 only checks the last byte of padding. An attacker who could manipulate the last block of a CBC-encrypted request and observe whether the server accepted or rejected the result could use this as a byte-by-byte oracle to decrypt specific bytes of the plaintext.
The practical attack scenario required a network-level man-in-the-middle who could force TLS connections to fall back to SSL 3.0 (by making TLS handshakes appear to fail), then inject JavaScript into the victim's browser to generate repeated requests (achievable through a malicious ad, cross-site script, or network injection), and observe the server's padding-check responses. The attack could recover an HTTP cookie in approximately 256 requests - feasible in seconds.
Google, Mozilla, and Microsoft disabled SSL 3.0 in their browsers within weeks of the POODLE disclosure. A subsequent variant (POODLE-TLS) showed that some TLS implementations had the same lax padding check, affecting a subset of TLS deployments even without fallback to SSL 3.0.
FREAK and Logjam (2015): Export Cryptography Returns
FREAK (Factoring RSA Export Keys) and Logjam both exploited a different kind of technical debt: US export regulations from the 1990s that had prohibited exporting strong cryptography. To comply, browsers and servers had implemented "export suites" - cipher suites with deliberately weakened key sizes (512-bit RSA, 40-bit RC2). When the export regulations were lifted in 2000, the code was left in place for compatibility.
FREAK showed that a man-in-the-middle could force a TLS connection to use an export-grade 512-bit RSA key, then factor the 512-bit key (computationally feasible with modern hardware in hours) to perform a man-in-the-middle decryption of the session. Logjam was the Diffie-Hellman equivalent: it targeted 512-bit Diffie-Hellman "export" groups and additionally found that many servers shared the same few 1024-bit DH groups, making state-level precomputation of discrete logarithm tables feasible. The NSA's ability to passively decrypt certain VPN traffic, revealed by Snowden documents, was consistent with a large-scale 1024-bit DH precomputation.
DROWN (2016): SSL 2.0's Ghost
DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) showed that SSL 2.0, thought to be dead, remained a threat wherever servers shared RSA keys across protocols. If a server's RSA private key was used for both TLS and SSL 2.0 connections, an attacker could use SSL 2.0's weaker protocol as an oracle to decrypt TLS connections using the same key. This was possible even if the attacker was targeting TLS sessions - they would interact with the server via SSL 2.0 to perform computations that leaked information about TLS ciphertexts.
The scope was alarming: at the time of disclosure, DROWN affected 33% of all HTTPS servers. This was because many servers still supported SSL 2.0 (or had keys shared with servers that did), often without their operators' knowledge. The practical attack required significant computation but was feasible within a day using cloud computing resources. The mitigation was disabling SSL 2.0 globally and not sharing RSA private keys between servers that could have different security configurations.
ROBOT (2017): An 19-Year-Old Flaw Returns
ROBOT (Return Of Bleichenbacher's Oracle Threat) demonstrated that a timing oracle attack published by Daniel Bleichenbacher in 1998 - against RSA PKCS#1 v1.5 padding in TLS - was still exploitable in implementations deployed in 2017. Bleichenbacher's 1998 paper had led to TLS protocol defenses (the PKCS#1 padding check was made constant-time to prevent timing oracles), but the ROBOT researchers found that many implementations - including those from Facebook, PayPal, Citrix, F5, and others - had subtle timing differences in error handling that still leaked oracle information.
An attacker with sufficient network access and computation could use the oracle to perform RSA decryption operations with the server's private key, enabling decryption of recorded TLS sessions that used RSA key exchange (non-forward-secret sessions) and authentication forgery. The finding demonstrated that eliminating a 19-year-old vulnerability class required not just the original fix but careful attention to implementation details in every subsequent implementation - and that the right fix was eliminating RSA key exchange entirely in favor of forward-secret ECDHE.
TLS 1.3: Designing Away the Attack Surface
TLS 1.3, finalized in RFC 8446 in August 2018, was designed with explicit awareness of the previous decade's attacks. It removed CBC mode cipher suites (BEAST, POODLE). It removed RSA key exchange entirely, requiring forward-secret ephemeral Diffie-Hellman or ECDHE for all connections (eliminating ROBOT and the DROWN-style key reuse problem). It removed export-grade cipher suites (eliminating FREAK and Logjam). It removed weak hash algorithms (MD5, SHA-1). It changed the handshake structure to reduce round trips and eliminate several attack surfaces.
TLS 1.3 reduced the number of cipher suites from the dozens available in TLS 1.2 to five, all using AEAD (Authenticated Encryption with Associated Data) modes that prevent the padding oracle attacks that affected CBC mode. The simplified cipher suite list and mandatory forward secrecy represent the accumulated lesson of two decades of attacks: fewer options means fewer misconfigurations, and forward secrecy means that compromise of the server's long-term key does not retroactively decrypt recorded sessions.
TLS 1.2 support persists in deployed infrastructure for compatibility, but TLS 1.3 adoption has been rapid. As of 2024, the majority of HTTPS traffic uses TLS 1.3. The migration from protocol versions that were vulnerable to the attacks documented here was driven by a combination of browser vendor mandates, server software defaults, and the accumulated weight of breach disclosures that made the risk of outdated TLS configurations impossible to ignore.