Transport Layer Security (TLS) Renegotiation Indication Extension
updates
Extracted elements (23)
The data carried in `renegotiation_info` is similar to but intentionally distinct from the `tls-unique` and `tls-unique-for-telnet` channel binding values. This extension is explicitly not a general-purpose RFC 5056 channel binding facility and should not be treated as one.
The SCSV mechanism was added because some deployed SSLv3/TLS 1.0 servers incorrectly reject handshakes containing unknown extensions, even though the specifications require them to be ignored. Using a fake cipher suite value avoids triggering this bug since unknown cipher suites are reliably ignored by all implementations.
Clients that receive no `renegotiation_info` in the ServerHello cannot determine via TLS mechanisms alone whether the server is vulnerable or simply does not support renegotiation. Terminating the connection ensures security but causes interoperability failures with un-upgraded servers; there is no single client behavior that guarantees both security and maximum interoperability during the transition period.
Some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake when encountering unknown extensions, even though the specs require them to be ignored. The SCSV is provided as a fallback signaling mechanism that can be safely included in any ClientHello, including SSLv2 backward-compatible CLIENT-HELLO messages.
SSLv3 uses 36-byte `verify_data` values instead of TLS's 12 bytes, so `renegotiated_connection` is 72 bytes in SSLv3 renegotiating ServerHellos. Clients supporting SSLv3 and secure renegotiation MUST accept `renegotiation_info` from servers advertising version {0x03, 0x00}.
During secure renegotiation (secure_renegotiation=TRUE), the client MUST include `renegotiation_info` with the saved `client_verify_data` in the ClientHello, MUST NOT include the SCSV, and MUST verify that the ServerHello's `renegotiated_connection` field equals the concatenation of `client_verify_data` and `server_verify_data`. Failure on any check MUST cause handshake abort.
During secure renegotiation, the server MUST verify that the ClientHello does not contain the SCSV (abort if present), MUST verify that `renegotiation_info` is present (abort if absent), and MUST verify that `renegotiated_connection` equals the saved `client_verify_data`. The ServerHello MUST include `renegotiation_info` with both `client_verify_data` and `server_verify_data`.
Even servers that do not support renegotiation MUST implement the minimal version of the `renegotiation_info` extension for initial handshakes, so that clients can probe whether the server has been upgraded and detect its support status.
For legacy (insecure) renegotiation on the server side, it is RECOMMENDED that servers not permit it. If they do, servers MUST verify that neither SCSV nor `renegotiation_info` is present in the renegotiating ClientHello, and abort if either is found.
For legacy (insecure) renegotiation where `secure_renegotiation` is FALSE, it is RECOMMENDED that clients refuse renegotiation requests and respond with a `no_renegotiation` alert. Clients that do renegotiate MUST still provide the SCSV or `renegotiation_info` in the ClientHello.
On an initial handshake, the client MUST include either an empty `renegotiation_info` extension or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV in the ClientHello. Including both is NOT RECOMMENDED.
On receiving a ClientHello, the server MUST check for TLS_EMPTY_RENEGOTIATION_INFO_SCSV or the `renegotiation_info` extension and set `secure_renegotiation` accordingly. If the extension is present with a non-zero-length `renegotiated_connection` on an initial handshake, the server MUST abort. If `secure_renegotiation` is TRUE, the server MUST include an empty `renegotiation_info` in the ServerHello.
Servers SHOULD NOT allow clients to renegotiate without using the `renegotiation_info` extension. TLS implementations SHOULD provide a mechanism to disable and enable renegotiation.
When a client receives a ServerHello with the `renegotiation_info` extension on an initial handshake, the client MUST verify that the `renegotiated_connection` field has zero length; if it does not, the client MUST abort the handshake with a fatal handshake_failure alert.
A new TLS extension `renegotiation_info` (extension type 0xff01) is defined, containing a `RenegotiationInfo` structure. On an initial handshake, the `renegotiated_connection` field is zero-length in both ClientHello and ServerHello; on renegotiation it carries the prior verify_data values to cryptographically bind the renegotiation to the enclosing connection.
A Signaling Cipher Suite Value (SCSV) `TLS_EMPTY_RENEGOTIATION_INFO_SCSV` with code point {0x00, 0xFF} is defined as an alternative signaling mechanism. It is not a true cipher suite and cannot be negotiated; it has the same semantics as an empty `renegotiation_info` extension and can be safely sent to any server, including SSLv3 servers.
Three additional per-connection state values are required: a `secure_renegotiation` boolean flag, `client_verify_data` (the verify_data from the client's most recent Finished message, 12 bytes for TLS, 36 bytes for SSLv3), and `server_verify_data` (the verify_data from the server's most recent Finished message).
IANA added extension code point 65281 (0xff01) for the `renegotiation_info` extension to the TLS ExtensionType values registry.
IANA added TLS cipher suite number {0x00, 0xFF} with name `TLS_EMPTY_RENEGOTIATION_INFO_SCSV` to the TLS Cipher Suite registry.
Applications that depend on renegotiation should be aware that many TLS APIs represent application data as a simple octet stream, making it impossible to determine exactly which octets were received before, during, or after renegotiation. When the peer presents a different certificate during renegotiation, particular care is required in specifying how application data spanning the boundary should be handled.
Even with this extension in use, renegotiation allows the peer to present a different certificate than was used earlier in the same connection. Application developers may be surprised if APIs like `getPeerCertificates()` return different values across a renegotiation, and applications that do not account for this may handle the transition insecurely.
TLS renegotiation is vulnerable to an attack where an attacker forms a TLS connection to the server, injects arbitrary traffic, and then splices in the client's TLS handshake so the server treats it as renegotiation. The server then believes the attacker's initial traffic came from the authenticated client, enabling request forgery and credential theft.
The `RenegotiationInfo` extension has the structure `opaque renegotiated_connection<0..255>`. For an initial handshake, the full extension encoding is `ff 01 00 01 00` (type, length, zero-length field). For a renegotiating ServerHello, the field contains the concatenation of `client_verify_data` and `server_verify_data` (24 bytes for TLS, 72 bytes for SSLv3).