密码套件 · 0x00,0xFF

TLS_EMPTY_RENEGOTIATION_INFO_SCSV

TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00,0xFF)是信令值(SCSV),不是真正的密码套件:客户端把它放进 ClientHello 用来表明某种能力,它永远不会被协商选中。

仅信令数据更新于

详细信息

IANA 名称
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
十六进制码
0x00,0xFF (255)
OpenSSL
OpenSSL 3.5 不支持
GnuTLS
GnuTLS 未实现
密钥交换
-
身份认证
-
加密算法
-
消息认证(MAC)
-
TLS 版本
–
IANA“Recommended”
N:未评估或不推荐 · DTLS-OK: Y
规范
RFC 5746

各组成部分说明

TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00,0xFF)是一个信号,而不是真正的密码套件。客户端把它放进套件列表,表示自己支持安全重协商(RFC 5746),而不必发送 renegotiation_info 扩展,这样可以兼容遇到陌生扩展就出错的老服务器。RFC 5746 修复的是 2009 年的重协商攻击(CVE-2009-3555):中间人可以把自己的请求拼接到受害者的 TLS 会话前面。TLS 1.3 取消了重协商,所以这个信号只对 TLS 1.2 及更早版本有意义。

评级理由

ssl.sh 评级:仅信令。理由:

  • 只是信令值,不包含任何算法,也不会被协商选中。

ssl.sh 如何给密码套件评级

历史与标准状态

TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00,0xFF)在 IANA TLS 密码套件注册表中登记,规范文档为 RFC 5746《Transport Layer Security (TLS) Renegotiation Indication Extension》(2010 年 2 月,标准轨道)。

如何测试服务器是否接受它

在 TLS 1.2 下检查安全重协商支持;服务器支持时 s_client 会输出“Secure Renegotiation IS supported”:

openssl s_client -connect example.com:443 -tls1_2 </dev/null | grep -i renegotiation

想解析套件名称或十六进制编号,可以用密码套件查询;SSL 检测会显示线上服务器接受哪些协议版本以及实际协商出的密码套件。

常见问题

TLS_EMPTY_RENEGOTIATION_INFO_SCSV 是真正的密码套件吗?

不是。它是信令套件值(SCSV):不包含任何算法,服务器永远不会选中它,它只是让客户端向服务器传递一个信息。所以 ssl.sh 不给它评级。

需要在 Nginx 或 Apache 里配置 TLS_EMPTY_RENEGOTIATION_INFO_SCSV 吗?

不需要。客户端会自动加上它,基于 OpenSSL 的服务器(如 Nginx、Apache httpd)无需任何指令就能识别;它也不会出现在 ssl_ciphers 或 SSLCipherSuite 列表里。

TLS 1.3 下 TLS_EMPTY_RENEGOTIATION_INFO_SCSV 还有用吗?

对 TLS 1.3 连接没有意义,因为 TLS 1.3 根本没有重协商。协商到 TLS 1.2 时它仍然有用,能防御 CVE-2009-3555 重协商攻击。

更好的替代

资料来源

  1. IANA — TLS Cipher Suites registry
  2. OpenSSL 3.5 — openssl-ciphers(1)
  3. GnuTLS — lib/algorithms/ciphersuites.c
  4. RFC Editor — RFC index