Cipher suite · 0x00,0xFF
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00,0xFF) is a signaling cipher suite value (SCSV), not a real cipher suite: clients put it in the ClientHello to signal a capability, and it never gets negotiated.
Details
- IANA name
TLS_EMPTY_RENEGOTIATION_INFO_SCSV- Hex code
0x00,0xFF(255)- OpenSSL
- Not available in OpenSSL 3.5
- GnuTLS
- Not implemented in GnuTLS
- Key exchange
- -
- Authentication
- -
- Encryption
- -
- MAC
- -
- TLS versions
- –
- IANA "Recommended"
- N — not evaluated or not recommended · DTLS-OK: Y
- References
- RFC 5746
What each component means
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00,0xFF) is a signal, not a cipher suite. A client puts it in its cipher list to say it supports secure renegotiation (RFC 5746) without sending the renegotiation_info extension, which helped with servers that choked on unknown extensions. RFC 5746 fixed the 2009 renegotiation attack (CVE-2009-3555), in which a man-in-the-middle could splice its own request in front of a victim's TLS session. TLS 1.3 removed renegotiation, so the signal only matters for TLS 1.2 and earlier.
Why this rating
ssl.sh rating: Signal only. The reasons:
- Signaling value only; it carries no algorithms and is never negotiated.
History and standards status
TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00,0xFF) is registered in the IANA TLS Cipher Suites registry with RFC 5746, “Transport Layer Security (TLS) Renegotiation Indication Extension” (February 2010, Standards Track) as its specification.
How to test whether a server accepts it
Check secure renegotiation support on TLS 1.2; s_client prints “Secure Renegotiation IS supported” when the server understands it:
openssl s_client -connect example.com:443 -tls1_2 </dev/null | grep -i renegotiationTo decode a name or hex code, use the cipher suite lookup; the SSL checker shows which protocol versions a live server accepts and the cipher suite it negotiates.
FAQ
Is TLS_EMPTY_RENEGOTIATION_INFO_SCSV a real cipher suite?
No. It is a signaling cipher suite value: it carries no algorithms, is never selected by the server, and only tells the server something about the client. ssl.sh therefore does not rate it.
Do I need to configure TLS_EMPTY_RENEGOTIATION_INFO_SCSV in Nginx or Apache?
No. Clients add it automatically and OpenSSL-based servers such as Nginx and Apache httpd recognise it without any directive; it doesn't appear in ssl_ciphers or SSLCipherSuite lists.
Does TLS_EMPTY_RENEGOTIATION_INFO_SCSV matter with TLS 1.3?
Not for TLS 1.3 connections, which have no renegotiation at all. It still matters when TLS 1.2 is negotiated, where it protects against the CVE-2009-3555 renegotiation attack.