What property of TLS 1.0's CBC initialization vectors did BEAST (CVE-2011-3389) exploit?

## What TLS 1.0 does with the initialization vector CBC mode combines each plaintext block with the previous ciphertext block before encrypting, and the first block of a message needs a starting value — the initialization vector. TLS 1.0 handles records by simply continuing the chain: the initialization vector for a record is the last ciphertext block of the record before it. That value is on the wire. Anyone watching the connection already has it. So before the next record is even constructed, an observer knows what will be combined with its first plaintext block. ## Why predictability is the whole defect CBC's security argument assumes the value combined with each plaintext block is not known to the attacker before that block is chosen. Break that assumption and the mode becomes a device for testing guesses, because the attacker can pre-compensate: 1. The attacker has observed an earlier ciphertext block `C[i]` whose plaintext `P[i]` they want, along with the block that preceded it, `C[i-1]`. 2. They form a guess `G` at `P[i]`. 3. They arrange for a block of their own content to be sent next, knowing the initialization vector for it will be the last ciphertext block currently on the wire, `C[last]`. 4. They set that block's content to `C[i-1] XOR G XOR C[last]`. The encryption combines it with `C[last]`, which cancels, so the cipher is applied to `C[i-1] XOR G`. 5. If `G` equals `P[i]`, the cipher is applied to exactly the same input that produced `C[i]`, and the resulting ciphertext block equals `C[i]`. The attacker sees two identical ciphertext blocks and knows the guess was right. No key is recovered. The attacker learns plaintext by elimination, one block's worth at a time, and the search is made practical by shifting the target so that only one unknown byte sits in the block at a time. The attack therefore needs two capabilities together: the ability to observe the connection's ciphertext, and the ability to cause chosen content to be sent over that same connection alongside the secret. Either one alone is not enough. ## The repair, and the stopgap before it | | TLS 1.0 | TLS 1.1 and later | |---|---|---| | initialization vector for a record | the previous record's last ciphertext block | a fresh value, unpredictable, carried explicitly | | known to an observer before the record is built | yes | no | | exploitable by a chosen-content attacker | yes | no, the pre-compensation step fails | Before deployments could move, implementations mitigated the attack inside TLS 1.0 by splitting each outgoing record so that the first fragment carried a single byte. That fragment's encryption consumes the predictable chaining value, leaving the rest of the data to start from a chaining value the attacker cannot know in advance. It is a genuine mitigation, but a workaround at the sending side rather than a protocol repair — the receiving peer's rules were unchanged and a peer that did not split remained exposed. ## Where this sits among the named breaks BEAST (`CVE-2011-3389`) is a **design flaw**: the chaining rule is what TLS 1.0 specifies, so every conforming implementation had the property, and no build could change the rule without breaking interoperability. That is the same class as POODLE (`CVE-2014-3566`) against SSL 3.0's padding rule, and the opposite class from an implementation break such as Heartbleed, where one program's missing length check was the whole defect. The historical arc is worth having straight for an interview: - TLS 1.0 chained initialization vectors across records — exploited by BEAST. - TLS 1.1 introduced the explicit per-record initialization vector, which removes the predictability the attack needs. - `RFC 8996` deprecates TLS 1.0 and TLS 1.1 as versions, for the accumulated weight of this and other issues rather than for this one alone. ## What an operator should take from it The useful generalisation is not "CBC is bad". It is that any value an attacker can predict before choosing their own input is a lever, and that a protocol which reuses a visible value as a secret-adjacent input has handed one over. The repair was not a stronger cipher; it was making a single value unpredictable. For a bus that has carried the same counterparties for a decade, the second lesson is about mitigations. The record-splitting stopgap kept deployments alive for years, which is exactly why it is worth distinguishing from the repair: a sending-side workaround protects the side that implements it and says nothing about the peer.