TLS renegotiation is a mechanism that lets a client and server change an already-established connection's parameters — switching to a stronger cipher suite, or having the server request a client certificate partway through a session — without tearing down and fully restarting the connection. It existed in SSL and TLS from early on, and turned out to have a serious, exploitable flaw discovered in 2009.
What renegotiation was originally used for
A common legitimate use was a server initially accepting a connection anonymously, then renegotiating partway through to request a client certificate once it determined the specific resource being requested actually required client authentication — letting a server avoid demanding a client certificate upfront for every visitor, only when a specific request needed it.
The 2009 vulnerability
Security researchers found that the renegotiation handshake, as originally specified, didn't cryptographically bind the renegotiated session to the original one. This let an attacker inject data at the start of a connection, then trigger a renegotiation that spliced the victim's legitimate request onto the attacker's already-established connection — a real, practical man-in-the-middle vector, not just a theoretical weakness.
How it was fixed, and why TLS 1.3 went further
RFC 5746 patched this by cryptographically binding a renegotiation to the connection it extends, closing the specific injection vector. TLS 1.3, standardized in 2018, went a step further and removed renegotiation from the protocol entirely, replacing the narrower cases it was used for (like requesting a client certificate mid-session) with a different mechanism — post-handshake authentication — that achieves the same practical goal without reopening the same class of design risk.
What this means for a server you manage today
If your server still supports TLS 1.2 alongside 1.3 — a common, reasonable compatibility choice — confirming your TLS library and configuration are current enough to include the RFC 5746 fix matters, since a actually ancient, unpatched implementation could still carry the original vulnerability. Any TLS library that's received updates within the last several years handles this correctly by default; this is exactly a concern only for unusually old, unmaintained software.
Why this history is a useful example of TLS's design evolution more broadly
Renegotiation's story — a legitimate feature, a serious flaw discovered years after standardization, an initial patch, then eventual removal in the next major protocol version — is a pattern that recurs across TLS's history more than once. It's part of why TLS 1.3's design philosophy leaned toward removing optional, rarely-needed complexity rather than accumulating patches on top of it indefinitely: fewer optional mechanisms means fewer places for this specific kind of flaw to hide.
See RFC 5746, the fix for the original renegotiation vulnerability.