renegotiation_info
renegotiation_info protects TLS 1.2 renegotiation from a known attack. Most clients send it, plain curl does not.
What it is
renegotiation_info (extension 65281, 0xFF01) is defined in RFC 5746. It binds a renegotiated TLS 1.2 handshake to the one before it, so an attacker cannot splice their own handshake in front of a victim's connection, the flaw disclosed in 2009 as the TLS renegotiation attack.
A client can signal the same support in two ways: by sending this extension, or by including the special TLS_EMPTY_RENEGOTIATION_INFO_SCSV value in its cipher suite list. Either tells the server that the client understands secure renegotiation.
TLS 1.3 has no renegotiation at all, so the extension only matters when TLS 1.2 is negotiated. Clients keep sending it because they still support TLS 1.2 servers.
Servers check for one of the two signals and can refuse renegotiation with clients that send neither. RFC 5746 recommends against sending both, which is why a client picks one way.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 10 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
Chrome, curl_cffi, curl-impersonate, Go net/http, Python requests, httpx, Node.js fetch and Guzzle send it. Python requests, httpx, Node.js fetch and Guzzle all put it first. curl on macOS and Debian does not send the extension; both put the TLS_EMPTY_RENEGOTIATION_INFO_SCSV value in their cipher list instead.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for renegotiation_info in the TLS details.
Run the TLS fingerprint test