Summary

  • TLS 1.2 could run a new handshake inside an existing connection, yet the new handshake did not prove which earlier handshake and application stream it continued.
  • RFC 5746 bound renegotiation to saved Finished-message values, while a compatibility signal let older extension-intolerant deployments announce support safely; TLS 1.3 later removed renegotiation altogether.

Two sound handshakes, one false conversation

The attack began with a legitimate connection—just not the victim's. An attacker established TLS with a server and sent chosen application bytes. The attacker then allowed a victim client's handshake to travel through that already protected channel. From the client's point of view, this looked like an initial handshake with the server. From the server's point of view, it looked like a renegotiation of the attacker's connection.

Afterward the attacker could not read the victim's protected traffic. That limitation did not undo the prefix already delivered. The server could see the attacker's bytes followed by the victim's authenticated bytes and treat both as one application interaction. In HTTPS, for example, an application that did not distinguish the pre- and post-authentication phases could associate attacker-chosen input with credentials or cookies supplied later by the client.

This was not a story about a broken cipher or a forged certificate. TLS 1.2 permitted a client to send another ClientHello on an existing connection, and it used the current connection state to protect the renegotiation messages. Each handshake could complete with valid Finished messages. The missing fact was continuity: neither endpoint proved that the new handshake was the successor of the same cryptographic history the other endpoint had just observed.

That distinction explains why application-layer resets could limit some attacks without repairing TLS itself. A protocol with a strict transition between unauthenticated and authenticated commands might discard prior state. Another protocol might process the connection as one byte stream. RFC 5746 treated the ambiguity as a transport-security defect rather than assuming every application would reconstruct the right boundary.

Making the previous Finished messages into state

RFC 5746 added three pieces of connection-specific state. A secure_renegotiation flag recorded whether the repair was active. The client and server also saved the verify_data from the Finished messages of the immediately previous handshake. Those values belonged to the live connection, not merely to a TLS session-cache entry that might be resumed elsewhere.

The new renegotiation_info extension, type 0xff01, carried that history into the next negotiation. During an initial handshake, its renegotiated_connection field was empty. That empty value did not bind a predecessor; it announced that both peers understood the secure-renegotiation rules.

During a renegotiation, the client placed its saved client_verify_data in the extension. The server checked it against the value stored for this connection. The server then returned the concatenation of the saved client and server values, which the client checked against its own history. A missing required extension or a mismatch ended the handshake with a fatal failure.

The asymmetry was deliberate. A renegotiating ClientHello could prove the client's view of the preceding handshake. The ServerHello could then prove the server's view of both Finished messages. Once the new handshake completed, both sides replaced the saved values with the new pair. The next transition would therefore name its immediate predecessor, not some vague session ancestry.

In editorial terms, the protocol learned to remember. More precisely, RFC 5746 made temporal continuity an authenticated input. A correctly finished handshake was no longer sufficient for secure renegotiation; it had to be the correct next handshake for this exact connection.

A cipher-suite code that was not a cipher suite

The repair had to cross a deployed compatibility boundary. Some SSLv3, TLS 1.0 and TLS 1.1 implementations incorrectly failed when a ClientHello contained extensions they did not understand, even though the specifications required tolerant behavior. Sending only the new extension could therefore break connections to old servers before either side could negotiate anything.

RFC 5746 supplied a second initial-handshake signal: TLS_EMPTY_RENEGOTIATION_INFO_SCSV, assigned 0x00,0xFF. It occupied the cipher-suite list because old implementations were expected to ignore unknown cipher suites reliably. It was not an algorithm choice and could never be selected as the negotiated suite. Its meaning was equivalent to offering an empty renegotiation_info extension.

This compatibility device did not replace the binding on later handshakes. Secure renegotiation itself used the extension and its saved Finished values. The SCSV let a client announce capability during the initial encounter without relying on an extension parser that might be defective.

The transition still imposed a policy choice. If a server did not acknowledge secure renegotiation, a client could not learn through TLS alone whether the server was vulnerable or simply refused renegotiation entirely. Refusing the connection maximized protection but could lose interoperability with harmless unupgraded endpoints. Continuing preserved reachability but could not guarantee the splice attack was impossible. RFC 5746 documented that trade-off rather than pretending one signal could reveal an old server's private policy.

From repair to removal

TLS 1.3 took a different architectural boundary: it forbids renegotiation. A server that has negotiated TLS 1.3 and receives a ClientHello at another time must terminate the connection with an unexpected_message alert. An older TLS connection that receives a TLS 1.3 ClientHello during renegotiation must retain its earlier protocol version: renegotiation cannot upgrade that connection into TLS 1.3.

That removal should not be confused with the disappearance of every post-handshake operation. TLS 1.3 has separate key-update and post-handshake authentication mechanisms, and current operational guidance treats their application consequences independently. For TLS 1.2, RFC 9325 requires both clients and servers to implement renegotiation_info, and requires clients to terminate when a server does not acknowledge it. Nor does RFC 5746 answer every attack involving multiple TLS handshakes; RFC 9325 separately requires the extended-master-secret repair for the related triple-handshake class in TLS 1.2.

The narrower historical conclusion is stronger. RFC 5746 exposed a property that protocol designers could no longer leave implicit: when security state changes inside a continuing connection, the transition itself needs authenticated meaning. TLS 1.2 retained renegotiation and attached its new handshake to the last one. TLS 1.3 removed the general transition and replaced particular needs with narrower mechanisms. In both cases, the connection stopped asking applications to assume that adjacent authenticated fragments necessarily belonged to one authenticated story.

Sources