最近在研究漏洞安全处理在此也做一个记录分享漏洞信息描述来自于nvd官网可供参考NVD - CVE-2011-1473原文漏洞信息描述OpenSSL before 0.9.8l, and 0.9.8m through 1.x, does not properly restrict client-initiated renegotiation within the SSL and TLS protocols, which might make it easier for remote attackers to cause a denial of service (CPU consumption) by performing many renegotiations within a single connection, a different vulnerability than CVE-2011-5094. NOTE: it can also be argued that it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment机翻在 0.9.8l 之前版本的 OpenSSL以及 0.9.8m 到 1.x 版本中没有正确限制客户端发起的重新协商行为。这可能会导致远程攻击者在单个连接中频繁进行重新协商从而引发服务拒绝攻击导致 CPU 消耗过高。这一漏洞与 CVE-2011-5094 属于不同的漏洞。需要注意的是防止或限制在特定环境下不必要的重新协商行为应该是服务器部署方的责任而非安全库的责任。综上所述CVE-2011-1473 是一个拒绝服务DoS漏洞攻击者利用的是服务器不限制单条连接内客户端发起的重协商次数通过在同一连接中反复快速发起重协商迫使服务器反复执行非对称加密握手计算CPU 密集从而耗尽 CPU 资源导致服务不可用。一、漏洞原理要看懂这个漏洞需要搞清楚重协商请求这个概念重协商请求在已经建立好的TLS连接上其中一端主动发起的“在当前通道内部再做一次握手”的请求举个例子普通TLS握手 俩个人第一次见面交换证件、握手、建立信任重协商请求 俩个人已经聊了 1 个小时突然其中一个人说“等一下我重新给你看一下我的证件我刚刚更新了”也就是说重协商请求的特点就是通道不关闭新握手在加密通道内部进行TLS设计这个功能原本是为了诸如“密钥刷新”“服务端二次认证”这样的合法用途比如长对话下定期更换密钥防止被破解又或者是登录后访问敏感内容需要二次认证的情况。那这个漏洞为什么能被攻击者利用呢攻击者与服务器建立一条 TLS 连接然后在该连接内连续发送数百上千次重协商请求。每次重协商服务器都要重新进行 RSA/ECDHE 等密钥交换运算消耗大量 CPU。若攻击者开启多个此类连接即可使服务器 CPU 飙升至 100%造成拒绝服务。t1 攻击者建立 TLS 连接握手完成服务端分配会话资源 t2 攻击者发送第 1 次重协商请求 → 服务端执行 RSA/ECDHE 非对称解密CPU 10% t3 攻击者发送第 2 次重协商请求 → 服务端再次执行非对称运算CPU 20% t4 攻击者在同一连接内连续重放几百上千次 R 指令重协商 [服务端陷入密集计算CPU 飙升至 100%] 正常用户的请求因服务端 CPU 满载而超时/被丢弃造成拒绝服务DoS二、如何规避漏洞风险最简单的办法使用安全版本的OpenSSL即依靠官方的修复来规避这个问题或者配置JVM的参数使得服务从根本上拒绝重协商请求配置了以下参数为true后便会拒绝重协商请求当这样的请求被拒绝那么攻击者也就无法发出这样的攻击CUSTOM_OPS-Djdk.tls.rejectClientInitiatedRenegotiationtrue“该参数仅适用于基于 Java 标准 JSSE 实现的 SSL 上下文如 Tomcat 的 NIO 连接器。若使用 OpenSSL 原生库如 netty-tcnative需升级 OpenSSL 版本或通过库自身 API 禁用重协商。”三、验证方法如何验证自己的修复是有效的呢采用以下命令的方式来验证服务是否支持重协商请求如果服务拒绝重协商请求即可规避该漏洞使用openssl s_client测试重协商是否被允许echo R | openssl s_client -connect 域名:端口 -tls1_2 21 | tail -10命令解读echo R输出字符 R 和一个换行符。这里的 R 是 openssl s_client 交互模式下的内建命令——它指示 s_client 向服务器发送一个 TLS 重新协商请求。第一个 |管道将左侧命令的标准输出echo R 的输出连接到右侧命令的标准输入。让openssl s_client启动后无需等待键盘输入直接自动接收R指令并执行。openssl s_client这是OpenSSL 的 TLS/SSL 客户端工具用于建立加密连接并显示握手详情。-connect 域名:端口指定要连接的 TLS 服务器地址和端口。-tls1_2强制使用 TLS 1.2 协议进行握手。限制协议版本可增加测试的确定性排除 TLS 1.3 等版本的影响。TLS 1.2 允许传统的客户端重新协商而 TLS 1.3 已从根本上移除了重协商机制用 post-handshake auth 替代。要测试重协商漏洞须使用 TLS 1.2。备注若服务器不支持 TLS 1.2可省略该参数但注意 TLS 1.3 本身已废弃重协商测试结果不具可比性。后面的21、第二个 |管道、tail -10都是为了方便观察因为s_client 输出通常很长包括证书链、密码套件等。我们只关心最后的重新协商结果成功还是被拒绝。因此排除多余信息干扰我们判断。判断标准若服务器拒绝客户端发起的重协商返回 handshake_failure则本漏洞被彻底规避若允许具体表现返回结果中出现证书链 DONE无 error则表明服务器没有采取防护措施或配置不当存在被利用的风险。举例加上参数后期望TLS 1.2 测试结果应为handshake_failureRENEGOTIATING error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
漏洞修复：TLS重协商攻击（CVE-2011-1473）
发布时间：2026/7/31 7:36:30
最近在研究漏洞安全处理在此也做一个记录分享漏洞信息描述来自于nvd官网可供参考NVD - CVE-2011-1473原文漏洞信息描述OpenSSL before 0.9.8l, and 0.9.8m through 1.x, does not properly restrict client-initiated renegotiation within the SSL and TLS protocols, which might make it easier for remote attackers to cause a denial of service (CPU consumption) by performing many renegotiations within a single connection, a different vulnerability than CVE-2011-5094. NOTE: it can also be argued that it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment机翻在 0.9.8l 之前版本的 OpenSSL以及 0.9.8m 到 1.x 版本中没有正确限制客户端发起的重新协商行为。这可能会导致远程攻击者在单个连接中频繁进行重新协商从而引发服务拒绝攻击导致 CPU 消耗过高。这一漏洞与 CVE-2011-5094 属于不同的漏洞。需要注意的是防止或限制在特定环境下不必要的重新协商行为应该是服务器部署方的责任而非安全库的责任。综上所述CVE-2011-1473 是一个拒绝服务DoS漏洞攻击者利用的是服务器不限制单条连接内客户端发起的重协商次数通过在同一连接中反复快速发起重协商迫使服务器反复执行非对称加密握手计算CPU 密集从而耗尽 CPU 资源导致服务不可用。一、漏洞原理要看懂这个漏洞需要搞清楚重协商请求这个概念重协商请求在已经建立好的TLS连接上其中一端主动发起的“在当前通道内部再做一次握手”的请求举个例子普通TLS握手 俩个人第一次见面交换证件、握手、建立信任重协商请求 俩个人已经聊了 1 个小时突然其中一个人说“等一下我重新给你看一下我的证件我刚刚更新了”也就是说重协商请求的特点就是通道不关闭新握手在加密通道内部进行TLS设计这个功能原本是为了诸如“密钥刷新”“服务端二次认证”这样的合法用途比如长对话下定期更换密钥防止被破解又或者是登录后访问敏感内容需要二次认证的情况。那这个漏洞为什么能被攻击者利用呢攻击者与服务器建立一条 TLS 连接然后在该连接内连续发送数百上千次重协商请求。每次重协商服务器都要重新进行 RSA/ECDHE 等密钥交换运算消耗大量 CPU。若攻击者开启多个此类连接即可使服务器 CPU 飙升至 100%造成拒绝服务。t1 攻击者建立 TLS 连接握手完成服务端分配会话资源 t2 攻击者发送第 1 次重协商请求 → 服务端执行 RSA/ECDHE 非对称解密CPU 10% t3 攻击者发送第 2 次重协商请求 → 服务端再次执行非对称运算CPU 20% t4 攻击者在同一连接内连续重放几百上千次 R 指令重协商 [服务端陷入密集计算CPU 飙升至 100%] 正常用户的请求因服务端 CPU 满载而超时/被丢弃造成拒绝服务DoS二、如何规避漏洞风险最简单的办法使用安全版本的OpenSSL即依靠官方的修复来规避这个问题或者配置JVM的参数使得服务从根本上拒绝重协商请求配置了以下参数为true后便会拒绝重协商请求当这样的请求被拒绝那么攻击者也就无法发出这样的攻击CUSTOM_OPS-Djdk.tls.rejectClientInitiatedRenegotiationtrue“该参数仅适用于基于 Java 标准 JSSE 实现的 SSL 上下文如 Tomcat 的 NIO 连接器。若使用 OpenSSL 原生库如 netty-tcnative需升级 OpenSSL 版本或通过库自身 API 禁用重协商。”三、验证方法如何验证自己的修复是有效的呢采用以下命令的方式来验证服务是否支持重协商请求如果服务拒绝重协商请求即可规避该漏洞使用openssl s_client测试重协商是否被允许echo R | openssl s_client -connect 域名:端口 -tls1_2 21 | tail -10命令解读echo R输出字符 R 和一个换行符。这里的 R 是 openssl s_client 交互模式下的内建命令——它指示 s_client 向服务器发送一个 TLS 重新协商请求。第一个 |管道将左侧命令的标准输出echo R 的输出连接到右侧命令的标准输入。让openssl s_client启动后无需等待键盘输入直接自动接收R指令并执行。openssl s_client这是OpenSSL 的 TLS/SSL 客户端工具用于建立加密连接并显示握手详情。-connect 域名:端口指定要连接的 TLS 服务器地址和端口。-tls1_2强制使用 TLS 1.2 协议进行握手。限制协议版本可增加测试的确定性排除 TLS 1.3 等版本的影响。TLS 1.2 允许传统的客户端重新协商而 TLS 1.3 已从根本上移除了重协商机制用 post-handshake auth 替代。要测试重协商漏洞须使用 TLS 1.2。备注若服务器不支持 TLS 1.2可省略该参数但注意 TLS 1.3 本身已废弃重协商测试结果不具可比性。后面的21、第二个 |管道、tail -10都是为了方便观察因为s_client 输出通常很长包括证书链、密码套件等。我们只关心最后的重新协商结果成功还是被拒绝。因此排除多余信息干扰我们判断。判断标准若服务器拒绝客户端发起的重协商返回 handshake_failure则本漏洞被彻底规避若允许具体表现返回结果中出现证书链 DONE无 error则表明服务器没有采取防护措施或配置不当存在被利用的风险。举例加上参数后期望TLS 1.2 测试结果应为handshake_failureRENEGOTIATING error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
