Why the names exist

Until about 2011 an attack on TLS (Transport Layer Security), the protocol underneath HTTPS (Hypertext Transfer Protocol Secure), was a paper with a number. After 2011 it was a logo, a website and a name that fit on a conference slide, and the practice has been mocked for it. The mockery misses the point. A name is how an operator who is not a cryptographer can ask whether a load balancer is exposed to a thing, and the tools on this site that check cipher suites and certificates report their findings under exactly these names. This article is what stands behind each of them: what was broken, who found it, and what the protocol removed in response. Read together, they are the reason TLS 1.3 looks the way it does. Every feature it dropped is on this list.

2011-2014: the block-cipher years

, September 2011. Juliano Rizzo and Thai Duong demonstrated at the conference in Buenos Aires - the same Latin American circuit the conference article describes - that a weakness in (cipher block chaining) mode, known in theory for years and considered impractical, could be used from a browser. In SSL (Secure Sockets Layer) 3.0 and TLS 1.0 the (initialisation vector) for each record was the last ciphertext block of the previous one, so an attacker who could inject chosen plaintext into a session could guess a byte at a time. The fix already existed: TLS 1.1 had used explicit IVs since 2006, and nobody had deployed it. Browsers worked around the flaw by splitting records, and for a while the recommended mitigation was to prefer RC4 - which is the origin of the next problem.

, September 2012, by the same two researchers at the same conference: if TLS compresses the data before encrypting it, the length of the ciphertext leaks whether a guess matched the secret in the request, and a session cookie can be recovered a character at a time. TLS compression was switched off everywhere within months. , in 2013, made the same observation about HTTP compression of the response body, which could not simply be switched off, and it remains a design constraint for any page that reflects user input next to a secret.

, February 2013. Nadhem AlFardan and Kenny Paterson at Royal Holloway showed that TLS's order of operations - authenticate the plaintext, pad it, then encrypt - let a server's timing reveal whether the padding was valid, and that a padding oracle can decrypt. The fix in the implementations was constant-time code that is notoriously hard to write; the fix in the protocol was to stop using CBC at all. The same year, new attacks on RC4 showed the fallback from BEAST was worse than the disease, and RC4 began the two-year process of being removed.

, April 2014, is the odd one out: not a design flaw but a bug, -2014-0160 in OpenSSL's implementation of the heartbeat extension, which let anyone read up to 64 kilobytes of a server's memory per request, with no limit on repetition and no trace in the logs. Keys, passwords and session cookies were in that memory. It is the reason the practice of rotating certificates after an incident exists, and it is in this list because a report that says "Heartbleed" means a server that was never patched, which is a finding about the operator rather than the protocol.

, October 2014. Bodo Möller, Thai Duong and Krzysztof Kotowicz at Google combined a padding flaw specific to SSL 3.0 with a downgrade: an attacker in the middle breaks the TLS handshake until the client falls back to SSL 3.0, then recovers cookies through the padding oracle. SSL 3.0 was eighteen years old and had persisted only for compatibility. POODLE ended it - the Internet Engineering Task Force formally deprecated it in 7568 the next year - and produced the TLS_FALLBACK_SCSV signal (RFC 7507) so that a client falling back could tell the server it was doing so.

2015-2016: the export-grade years

The next group has a single cause, and the EFF article explains it: in the 1990s the United States limited exported cryptography to keys that could be broken, and the protocol kept "export" cipher suites to them. Twenty years later they were still there.

, March 2015 (CVE-2015-0204): an attacker in the middle could make a server that still supported export-grade (Rivest-Shamir-Adleman) key exchange use a 512-bit key, and 512-bit RSA had been factorable for years. , May 2015 (CVE-2015-4000): the same trick with (DH) key exchange, downgrading to 512-bit groups - with the additional finding that because most servers used the same few standard groups, a well-funded adversary who precomputed against one 1024-bit group could read a large fraction of the internet's DH traffic. That finding is generally read as the explanation for how a state agency could do what the Snowden documents described.

, March 2016 (CVE-2016-0800): a server that still answered SSL 2.0 - a protocol from 1995 that nobody used - could be used as an oracle to decrypt TLS sessions to any other server sharing the same certificate, including modern ones. The lesson is the one the whole list keeps teaching: an old protocol left enabled on one port is a hole in the new protocol on another.

, August 2016 (CVE-2016-2183): ciphers with a 64-bit block, Triple DES and Blowfish among them, leak after enough data because of the birthday bound - about 32 gigabytes on one connection was enough to recover something. Triple DES had survived on the strength of its name; it is the cipher the 's DES cracker had made necessary in 1998, and by 2016 it was itself a finding. , the same year, from Karthikeyan Bhargavan and Gaëtan Leurent at INRIA: TLS 1.2 still allowed for handshake signatures, and a collision attack on the handshake transcript could break authentication. MD5 had been considered broken since 2004; the protocol had kept it for twelve more years.

2017-2020: the return of old attacks

, December 2017. In 1998 Daniel Bleichenbacher had shown that a server's differing error messages for badly padded RSA ciphertexts formed an oracle that let an attacker decrypt with the server's private key, and countermeasures had been specified for nineteen years. Hanno Böck, Juraj Somorovsky and Craig Young ran the first large-scale scan for the oracle and found it still present in nearly a third of the top hundred domains, and in products from nine vendors - among them F5, Citrix, Radware, Palo Alto Networks, Cisco and IBM. They signed a message with the private key of Facebook's certificate to prove the point. For readers of this site the relevant record is F5's own: K21905460, CVE-2017-6168, affecting BIG-IP 11.6.0 to 11.6.2, 12.0.0 to 12.1.2 HF1 and 13.0.0 to 13.0.0 HF2, a virtual server with a Client SSL profile exposed to plaintext recovery. The fix was a hotfix; the lesson was that RSA key exchange - as opposed to RSA signatures - could not be made safe, and TLS 1.3 removed it.

, October 2017 (CVE-2017-15361), is not a TLS attack but belongs with the others because it is what a report cannot see. Matúš Nemec, Marek Sýs and colleagues at Masaryk University found that Infineon's RSA key-generation library produced primes with a structure that made 1024- and 2048-bit keys factorable from the public key alone - no access to the device required. The library sat in smart cards, security tokens and TPMs (trusted platform modules) certified to 140-2 and Common Criteria EAL5+ since 2012; Estonia had to suspend 750,000 national identity cards weeks before an election that used them to vote. Daniel Bernstein's assessment at the time was that the keys had been visibly non-random since a 2016 paper and that serious attackers had probably found the flaw years earlier. A certificate can be perfectly configured and rest on a key that was broken at birth.

, September 2020 (CVE-2020-1968), from Robert Merget, Marcus Brinkmann and colleagues: TLS 1.2 and earlier strip the leading zero bytes from a Diffie-Hellman shared secret before deriving keys, which makes the key-derivation step take a measurably different time, which leaks the most significant bits of the secret, which can be assembled into the whole secret when a server reuses its DH share. The researchers traced the zero-stripping to an old bug report: implementers had misread the SSL 3 specification, and when TLS 1.0 was written the mistake was kept deliberately, to avoid confusion. A twenty-year-old misreading, exploitable only against servers using static DH or reusing ephemeral keys, which is why it is rated hard to exploit and why the fix was to stop reusing keys.

2021-2023: the edges of the protocol

, June 2021 (CVE-2021-3618), from the Bochum, Münster and Paderborn groups: TLS authenticates a server's name, not the application protocol behind it. Where a wildcard or multi-domain certificate serves HTTPS on one host and or on another, an attacker in the middle can redirect a browser's TLS connection to the mail or file server, which presents a valid certificate and then obeys, in its own protocol, the attacker's text embedded in the request - leaking cookies or reflecting script. The first version of the trick was described two decades earlier; ALPACA made it general. The remedy is the application-layer protocol negotiation extension and the discipline, relevant to anyone who runs the certificate tools on this site, of not sharing one certificate across services that speak different protocols.

, December 2023 (CVE-2023-48795), is the one that is not TLS at all. Fabian Bäumer, Marcus Brinkmann and Jörg Schwenk showed that 's (Secure Shell) binary packet protocol had stopped being a secure channel as new encryption modes were added: with ChaCha20-Poly1305, or any encrypt-then-MAC mode, an attacker in the middle could manipulate sequence numbers to delete messages from the start of the channel without either side noticing, and use that to strip the extension negotiation that protects against downgrade - turning off, for instance, the keystroke-timing countermeasure OpenSSH had just introduced. A scan in October 2023 found the majority of the internet's SSH servers vulnerable and some eleven million still exposed in January. The fix, "strict key exchange", only works when both ends have it, which the researchers expected would take years.

What the protocol removed

Put the list beside TLS 1.3, published in 2018, and the correspondence is exact. CBC mode is gone: BEAST, Lucky Thirteen, POODLE. Compression is gone: CRIME. RC4 is gone. RSA key exchange is gone: ROBOT, and FREAK with it. Static Diffie-Hellman is gone and the export groups with it: Logjam, Raccoon. MD5 and -1 signatures are gone: SLOTH. Renegotiation is gone. SSL 2.0 and 3.0 are not merely deprecated but impossible to negotiate: DROWN, POODLE. The only remaining cipher suites are five authenticated-encryption constructions with forward secrecy, and there is no downgrade path because the handshake is signed end to end.

That is the practical reading of a cipher-suite report. A finding named after one of these attacks is not an abstract weakness. It is a specific, dated failure that the protocol's designers removed the ability to configure, and a server that still reports it has been configured, by someone, to keep an option that ten years of published research argued should not exist. The tools on this site name the attack so that the person reading the report can find the story - and the story, every time, ends with the same sentence: the protocol took it away.

Sources