Why did POODLE force SSL 3.0 out of service entirely while Heartbleed was fixed without changing any protocol version?
answer
- specification versus code
- who has to install what
- every conforming implementation had it
- unspecified padding contents in SSL 3.0
- a length field trusted, not compared
basics
~20 sPOODLE exploits how SSL 3.0 itself defines CBC padding, so every conforming implementation had it and only withdrawing the version repaired it. Heartbleed was a missing length check in one TLS library, repaired by a new build.
solid answer
~50 sThe two breaks sit in different places. POODLE (`CVE-2014-3566`) targets a rule in the SSL 3.0 specification: the contents of CBC padding are left unspecified, so a receiver that follows the specification exactly has nothing to verify. Every correct implementation is therefore affected, there is no patched build that helps, and the repair is to stop negotiating the version at all — which is what `RFC 7568` requires, including a prohibition on falling back to it. Heartbleed is the opposite case: a widely deployed TLS library trusted a length field in a request instead of comparing it with the bytes actually received, and echoed back adjacent memory. Nothing in any protocol version asked for that, implementations that bounded the length were never affected, and the fix was a new build plus key rotation — no version retired, no peer reconfigured.
code
pseudocode · 7 lineson echo-style extension request received:
claimed_length = length field carried inside the request
# the missing guard:
# if claimed_length > bytes actually received: reject the message
reply with claimed_length bytes copied from the receive buffer
# the buffer holds fewer bytes than claimed, so the reply
# continues into whatever sits next to it in memorygo deeper
Recall that one of these two failures lived in the written protocol and the other in one program's code, and that only the second could be closed by installing an update.
Explain the mechanism on each side: SSL 3.0 leaves CBC padding contents undefined so nothing can be checked, while the other defect trusted a request's own length field instead of the bytes received.
Show the operational consequence. A design flaw becomes a peer migration with a cut-off date; an implementation break becomes a patch window plus rotation of whatever the disclosure may have exposed.
Frame the estate question: which counterparties can move versions on your timetable, what the cost of a forced cut-off is, and how you avoid carrying a protocol whose only repair is withdrawal.
## Two breaks that need different repairs The named failures of SSL and early TLS split into two classes, and the class decides what the repair costs and who has to cooperate in it. - A **design flaw** lives in the specification. Every implementation that follows the specification correctly has the flaw, so there is no patched build to install anywhere. The only repair is to change or withdraw the specification — and for a protocol version already deployed across an estate, that means retiring the version and coordinating with every peer. - An **implementation break** lives in one piece of code. The specification is sound; one program got it wrong. The repair is a new build of that program, and peers that never ran it were never exposed. An auditor asking about a settlement bus that ran for a decade is really asking which class each entry in the history belongs to, because that is what explains why one incident triggered an estate-wide migration and another was closed by a maintenance window. ## POODLE is a design flaw POODLE (`CVE-2014-3566`) attacks CBC padding as **SSL 3.0** (`RFC 6101`) defines it. SSL 3.0 defines only the final padding byte, which carries the padding length; the bytes before it may hold anything at all. The record MAC is computed over the message, not over the padding. So a receiver strips the padding using the length byte and has nothing to compare the rest against — any padding content is legal, which means any padding content must be accepted. That cannot be tightened by an implementation. Rejecting padding that a conforming peer is allowed to send breaks interoperability without a specification change behind it. The remaining move inside SSL 3.0 would be to stop offering CBC suites — but of SSL 3.0's stream ciphers only RC4 remained in use, and RC4 is itself prohibited by `RFC 7465`. There was no safe configuration left, which is exactly why `RFC 7568` prohibits SSL 3.0 outright and prohibits falling back to it from any version of TLS. ## Heartbleed is an implementation break Heartbleed is the standard example of the other class. A widely deployed TLS library implemented an extension message that echoes a caller-supplied payload back to the sender, and it used the length field carried in the request without comparing it against the number of bytes actually received. The response therefore copied out a run of memory beginning at the payload and continuing past it. No protocol version required that behaviour. Implementations that bounded the length against the received message were never vulnerable, and there was no interoperability consequence to fixing it: a new build behaves identically on the wire. The operational tail was real — anything that had been resident in that memory, including the long-term private key behind the server's certificate, had to be treated as exposed and replaced — but the protocol itself was never in question. ## The comparison an auditor wants | | POODLE | Heartbleed | |---|---|---| | where the defect lives | the SSL 3.0 specification | one library's code | | who is affected | every conforming implementation | only deployments running that build | | the repair | stop negotiating SSL 3.0 at all | install a fixed build | | who must cooperate | both peers, and every peer in the estate | the affected operator alone | | effect on the wire afterwards | the version disappears from negotiation | nothing visible changes | | residual work | none once the version is gone | rotate whatever the disclosure may have exposed | ## Classifying a break you have not seen before 1. Ask whether an implementation that follows the specification exactly still has the problem. If yes, it is a design flaw and no patch closes it. 2. Ask what the repair changes. If the repair is a new value, a new extension, a new rule about what a peer may send — a protocol change — the defect was in the protocol. 3. Ask who has to act. A design flaw in a negotiated protocol needs both peers to move, which is why retirement of a version is a migration project rather than a patch cycle. Other entries in the history sort the same way. The renegotiation attack (`CVE-2009-3555`) was a protocol-level break — a renegotiated handshake was not cryptographically bound to the one before it — and the repair was a protocol change, not a patched build. The triple-handshake attack (`CVE-2014-1295`) was also protocol-level, repaired by the extended master secret of `RFC 7627`, which binds the session's master secret to the handshake that produced it. BEAST (`CVE-2011-3389`) was a design flaw in TLS 1.0's chained initialization vectors, repaired in the next version. The practical lesson is that a vulnerability identifier tells you nothing about the class. Two entries in the same catalogue, filed the same way, can mean "install this build by Friday" and "plan a year of peer migrations".
- Which of the two classes can a single operator close without coordinating with any peer?An implementation break. Installing a fixed build changes nothing on the wire, so peers neither notice nor need to act. Retiring a protocol version is the opposite: the peer must be able to negotiate something higher, or the connection simply stops working, which is why removing a version is a migration rather than a patch.
- Where do the renegotiation attack (CVE-2009-3555) and the triple-handshake attack (CVE-2014-1295) sit in this classification?Both are protocol-level. In the first, a renegotiated handshake was not bound to the handshake before it, so an attacker could prepend traffic to a victim's session; the repair was a protocol change that binds them. In the second, the repair was the extended master secret of `RFC 7627`, which ties the master secret to the handshake that created it.
- Why did removing CBC cipher suites not rescue SSL 3.0?It leaves only RC4 among the stream ciphers still in use with that version, and RC4 is prohibited by `RFC 7465`. With one option broken by design and the other prohibited, no safe configuration of SSL 3.0 remained, so `RFC 7568` prohibits the version itself.
A crack in the published bridge design closes every bridge built to it; badly mixed concrete in one bridge needs one repair crew and nobody else's cooperation.
saying these in an interview costs you the question
- Says both breaks were fixed by upgrading the TLS library
- Calls Heartbleed a weakness in the encryption algorithm
- Describes POODLE as a bug in one implementation's code
- Assumes disabling CBC suites made SSL 3.0 safe again
- Treats a vulnerability identifier as proof of a protocol flaw