RocketMQ TLS Client-initiated 重协商攻击(CVE-2011-1473)

RocketMQ TLS Client-initiated 重协商攻击(CVE-2011-1473)-CSDN博客

-Djdk.tls.rejectClientInitiatedRenegotiation=true

环境信息
rocketmq:4.8.0
docker镜像 foxiswho/rocketmq:4.8.0

安全漏洞
服务器支持 TLS Client-initiated 重协商攻击(CVE-2011-1473)
SSL 重协商攻击（SSL renegotiation attack）是一种安全漏洞攻击，它利用了 SSL/TLS 协议的重协商功能，通过与服务器重新协商密钥，来发起攻击。

SSL 重协商攻击的危害主要体现在以下两个方面：
密码重置：攻击者可以利用 SSL 重协商攻击来重置 SSL/TLS 会话密钥，从而能够窃取会话中的敏感信息，如用户名、密码等。
DoS 攻击：攻击者可以通过 SSL 重协商攻击来占用服务器的计算资源，从而导致服务器性能下降，甚至崩溃。
因此，SSL 重协商攻击是一种非常危险的攻击方式，需要及时采取措施来防范。

漏洞验证
访问装了mq的服务器，涉及到了3个端口，默认端口9876、9709、9711
openssl s_client -connect 192.168.68.200:9876
输入R触发重协商,可重协商10次以上且连接未断开,重协商成功,漏洞存在。

漏洞修复
方式一 修改启动脚本
2种方式修改启动脚本，启动脚本中添加 -Djdk.tls.rejectClientInitiatedRenegotiation=true
mqnamesrv 对应修改启动脚本 runserver.sh
mqbroker 对应修改启动脚本 runbroker.sh

执行脚本替换。

基于以上修改原理，所以针对docker容器中修改方式
1、直接在mq容器启动时，替换启动脚本
2、可以发现执行脚本都使用到了JAVA_OPT_EXT，可以启动容器时，设置JAVA_OPT_EXT达到目的。
这里采用成本较小的设置JAVA_OPT_EXT达到目的

设置 JAVA_OPT_EXT
使用dockerfile方式
ENV JAVA_OPT_EXT="-Djdk.tls.rejectClientInitiatedRenegotiation=true"

CMD [ "sh", "mqnamesrv", "-c", "/home/rocketmq/rocketmq-4.8.0/conf/namesrv.properties ?${JAVA_OPT_EXT}"]
1
2
3
使用 docker-compose.yml，在配置中添加
? ? environment:
? ? ? JAVA_OPT_EXT: '-Djdk.tls.rejectClientInitiatedRenegotiation=true'
1
2
当同时使用到了dockerfile和docker-compose.yml时，要注意不要同时设置JAVA_OPT_EXT，会存在覆盖情况。
如果在 Docker Compose 文件中设置了环境变量，并且在 Dockerfile 中也设置了同名的环境变量，那么最终以 Docker Compose 文件中设置的环境变量为准。这是因为 Docker Compose 文件中设置的环境变量会覆盖 Dockerfile 中设置的环境变量。

验证修改后的结果
在容器内打印 JAVA_OPT_EXT，确保配置生效。进入容器内部后， echo $JAVA_OPT_EXT, 查看打印结果
重新发起连接 openssl s_client -connect 192.168.68.200:9876
禁用后，服务器直接拒绝重协商请求。重协商攻击失败
方式二 基于nginx进行请求转发
在nginx上要采用stream的配置方式，前提要安装tcp的ssl组件（ngx_stream_ssl_module ）
配置证书
通过nginx代理层对“TLS Client-initiated 重协商攻击”漏洞进行修复。该方法本人未实际验证，理论上可行，懂得都懂。以下配置内容来源网上，大家自行评估修改使用。

stream {
? ? server {
? ? ? ? listen ? ? ? ? ? ? ?9876 ssl; ? ? ? ? ? ? ? ? ??
? ? ? ? access_log logs/ldap_access.log tcp;

? ? ? ? ssl_protocols ? ? ? ?TLSv1.2; ? ??
? ? ? ? ssl_ciphers ? ? ? ? ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
? ? ? ? ? ? # 设置服务端使用的密码套件
? ? ? ? ssl_certificate ? ? ssl/www_nginxbar_org.pem; ?
? ? ? ? ssl_certificate_key ssl/www_nginxbar_org.key; ?
? ? ? ? ssl_session_timeout 10m; ? ? ? ? ? ? # SSL TCP会话缓存超时时间为10分钟
? ? ? ? ssl_prefer_server_ciphers on;
? ? ? ? proxy_pass rocketmq-namesrv:9876;
? ? ? ??
? ? ? ? proxy_ssl ? on; ? ? ? ? ? ? ? ? ? ? ?# 启用SSL/TLS协议，与被代理服务器建立连接
? ? ? ? proxy_ssl_session_reuse on; ? ? ? ? ?# 与被代理服务器SSL TCP连接的SSL会话重用功能 ? ? ? ?
? ? }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
绿盟扫描建议
使用SSL开启重协商的服务都会受该漏洞影响

Apache解决办法：
升级到Apache 2.2.15以后版本

IIS解决办法：
IIS 5.0启用SSL服务时，也会受影响。可以升级IIS 6.0到更高的版本。

Lighttpd解决办法：
建议升级到lighttpd 1.4.30或者更高,并设置ssl.disable-client-renegotiation = “enable”。
http://download.lighttpd.net/lighttpd/releases-1.4.x/

Nginx解决办法：
0.7.x升级到nginx 0.7.64
0.8.x升级到 0.8.23 以及更高版本。
http://nginx.org/en/download.html

Tomcat解决办法：
1、使用NIO connector代替BIO connector，因为NIO不支持重协商，参考如下配置：

（可能会影响Tomcat性能）；
2、配置Nginx反向代理，在Nginx中修复OpenSSL相关问题。
参考链接:
https://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html
https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
http://tomcat.apache.org/security-7.html#Not_a_vulnerability_in_Tomcat
https://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Connector_Comparison

Squid解决办法:
升级到3.5.24以及以后版本
http://www.squid-cache.org/Versions/
缓解或者修复建议：
1、建议关闭重协商，举例：ssl renegotiation disable
2、无法禁用重新协商策略的建议：
a)则仅允许安全重新协商并限制SSL握手的次数，或者通过添加SSL加速器之类的产品来升级服务器资源。不支持不安全的重新协商
b)请限制SSL握手的次数，或者通过添加SSL加速器之类的产品来升级服务器资源。
c)增加防火墙规则，限制端口访问等策略
d)使用iptable规则，限制每个ip地址的请求数

如果扫描器跟目标机之间存在WAF，请优先检查WAF配置。
————————————————
版权声明：本文为CSDN博主「清枫975」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xieqj_0511/article/details/131243923