# TLS_EMPTY_RENEGOTIATION_INFO_SCSV 密码套件

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

Source: https://ssl.sh/zh/ciphers/tls-empty-renegotiation-info-scsv/
Last updated: 2026-11-10

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

| 字段 | 值 |
|---|---|
| IANA | TLS_EMPTY_RENEGOTIATION_INFO_SCSV |
| 十六进制码 | 0x00,0xFF |
| OpenSSL | OpenSSL 3.5 不支持 |
| GnuTLS | - |
| 密钥交换 | - |
| 身份认证 | - |
| 加密算法 | - |
| 消息认证（MAC） | - |
| TLS 版本 | - |
| 评级 | 仅信令 |
| IANA“Recommended” | N |
| 规范 | RFC 5746 |

## 各组成部分说明

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

## 评级理由

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

## 历史与标准状态

TLS_EMPTY_RENEGOTIATION_INFO_SCSV（0x00,0xFF）在 IANA TLS 密码套件注册表中登记，规范文档为 [RFC 5746](https://www.rfc-editor.org/rfc/rfc5746)《Transport Layer Security (TLS) Renegotiation Indication Extension》（2010 年 2 月，标准轨道）。

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

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

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

想解析套件名称或十六进制编号，可以用[密码套件查询](https://ssl.sh/zh/tools/cipher-suite-lookup/)；[SSL 检测](https://ssl.sh/zh/tools/ssl-checker/)会显示线上服务器接受哪些协议版本以及实际协商出的密码套件。

## 常见问题

### 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 重协商攻击。