Summary

  • The original TLS renegotiation design encrypted a second handshake inside an existing channel but did not cryptographically bind the two handshakes together.
  • RFC 5746 repaired that gap by making each side present proof from the immediately previous Finished messages; TLS 1.3 later removed renegotiation altogether.

A channel with two authors

The attack begins with a detail that sounds reassuring. An attacker opens a valid TLS connection to a server. Everything sent on that connection is encrypted. The attacker then transmits an application prefix: perhaps the beginning of an HTTP request, perhaps a command whose meaning will be completed by later bytes. Next, instead of finishing the exchange alone, the attacker forwards a victim's fresh TLS handshake down the already protected server-side connection.

From the victim's perspective, this is an initial handshake with the real server. From the server's perspective, it is a renegotiation of the attacker's connection. Once the new handshake finishes, the attacker cannot read the victim's traffic. Confidentiality has not simply disappeared. The failure is attribution. The server can place the attacker's prefix and the victim's authenticated bytes in one application stream and treat them as the work of one peer.

RFC 5746's sequence diagram made the weakness legible: transport continuity, encryption continuity and application-transcript continuity were not the same property. A secure tunnel could carry a change of cryptographic identity without proving how the bytes before and after the change should be joined.

Why the first handshake had to survive in memory

The repair did not ask the second handshake merely to announce that it was a renegotiation. An attacker could copy such a declaration. It required both endpoints to retain connection-specific evidence from the immediately previous handshake: the client and server verify_data values in their Finished messages.

RFC 5746 defined the renegotiation_info extension, type 0xff01. On an initial handshake its binding field is empty, which lets the peers establish that they understand secure renegotiation without pretending that an earlier handshake exists. On a renegotiating ClientHello, the field carries the saved client verify_data. On the responding ServerHello, it carries the saved client and server values together. A missing or unequal value is not a warning to be logged after the fact; the handshake must be aborted.

That design turned the previous handshake into an authenticated input to the next one. The server could now distinguish a true continuation from a victim's initial handshake spliced into somebody else's connection. The second handshake had to remember its predecessor because the surrounding socket was not evidence enough.

The price of repairing a deployed protocol

The transition could not assume that every old implementation handled ClientHello extensions correctly. Some TLS 1.0-era software failed when it encountered an extension it did not understand, despite specifications requiring unknown extensions to be ignored. RFC 5746 therefore also created TLS_EMPTY_RENEGOTIATION_INFO_SCSV, a signaling cipher-suite value that is not a real cipher suite and cannot be negotiated. It carried the semantics of an empty initial binding in a form older servers were more likely to tolerate.

Compatibility did not erase ambiguity. A server that failed to acknowledge the extension might be vulnerable, or it might safely reject all renegotiation while lacking the new signal. TLS alone could not let the client distinguish those cases. The standards text consequently recorded an uncomfortable choice between maximum interoperability and a guarantee against the splice. The repair was cryptographic, but deploying it was an exercise in deciding when absence of evidence should end a connection.

Removal as a later form of safety

TLS 1.3 chose a narrower state machine. RFC 8446 forbids renegotiation: a ClientHello arriving at the wrong time terminates the connection. Functions that had been bundled into renegotiation were split. Key updates and post-handshake authentication exist as separate mechanisms with separate rules; they do not restore the old general-purpose ability to run another handshake in place.

The current guidance in RFC 9325 preserves the historical boundary. TLS 1.2 clients and servers must implement renegotiation_info, and a client must terminate if a TLS 1.2 server does not acknowledge it. For TLS 1.3, there is no renegotiation to secure. The lesson is not that every transition should be prohibited. It is that a transition which changes authentication or keys must define exactly which prior state it inherits and carry cryptographic evidence for that inheritance.

The RFCs do not establish how often the 2009 technique was exploited in the wild, nor do they count today's remaining renegotiation deployments. They do establish the protocol failure, the repair and the later removal. That is enough to identify the enduring design rule: encryption protects bytes in a channel; it does not by itself prove that every phase of the channel has the same author.

Sources