漏洞修复：RocketMQ TLS Client-initiated 重协商攻击(CVE-2011-1473)
RocketMQ TLS Client-initiated 重协商攻击(CVE-2011-1473）
RocketMQ TLS Client-initiated 重协商攻击(CVE-2011-1473)
环境信息
-
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}"]
使用 docker-compose.yml，在配置中添加
environment:
JAVA_OPT_EXT: '-Djdk.tls.rejectClientInitiatedRenegotiation=true'
当同时使用到了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会话重用功能
}
}
绿盟扫描建议
使用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配置。
