本帖最后由 zhaorong 于 2019-4-9 18:05 编辑

0×00 前言

前几天同事找到我，话说他们的系统，被扫描到仍在使用低版本TLSv1.0，要求禁用掉，本来以为很简
单的事情，结果他们折腾好几个月了，都没能搞掉它，每月月报上单位黑榜，急得够呛，最后病急乱投
医，找到我问问有没有什么办法。

望闻问切，掌握基本信息后，互联网基本思路，解决问题基本靠搜，搜不到再研究，于是百度必应
谷歌一通搜搜半天啥也没有。于是潜下心来，慢慢琢磨，最终得出两个切实可行的解决之道，总结
于此，送给有需要的朋友。

0×01 环境说明



0×02 如何测试是否配置成功？

执行openssl，指定协议版本TLSv1.0进行连接如果连接成功则说明配置失败；反之则配置成功命令如下：
Openssls_client -connect ip:port -tls1

0×03 失败尝试

SSL/TLS是种协议，不同厂家实现方式不同，其配置方式自然也不同，通常不外乎以下几种：


RocketMQ采用Java编写，可能使用了JDK SSL Provider，那么应该可以通过JVM的启动参
数来设定TLS版本算法。RocketMQ bin目录结构和启动命令如下，两条命令，对应两个bas
h文件（runserver.sh&runbroker.sh）都需要修改启动参数。



RocketMQ启动命令：


启动参数设置





执行如下测试命令，发现仍然可以使用TLSv1.0建立连接：





0×04 失败分析

有两个渠道可以控制JDK使用的TLS协议版本：
1)如上述失败尝试，在启动命令参数中设定禁用的协议算法
-Djdk.tls.disabledAlgorithms=SSLv3,RC4,MD5withRSA,TLSv1
2)还可以通过JAVA_HOME/jre/lib/security/java.security配置文件，配置项目名称与启动参数中完全一致
jdk.tls.disabledAlgorithms=SSLv3,RC4, DES, MD5withRSA, DH keySize < 1024, \EC keySize <224, 3DES_EDE_CBC
配置项目名称完全相同，那么两处配置会不会存在覆盖关系或是互补 ？
因为在上述失败尝试中，我使用了java.security的默认配置，即没有禁用TLSv1.0，所以可得出结论，不是互补关系。
按此推论，我们在JAVA_HOME/jre/lib/security/java.security修改配置，再次使用TLSv1.0协议连接，看看能否成功？



如图所示，TLSv1.0协议连接失败，成功禁用TLSv1.0。



0×05 进一步探索

虽然解决了问题，但始终觉得RocketMQ应该提供一个更为直观的配置方式，怀着疑问和好奇简单地走读了
一下RocketMQ的源代码（RocketMQ为开源软件，其核心组件为jboss netty开源组件），发现在netty中
硬编码写死了支持TLSv1.0,TLSv1.1,TLSv1.2，所以接下来的解决方案应该不用我说了。该方案也测试通过
可成功禁用。

部分代码列举如下：



RocketMQ其实支持两种TLS实现：
1)Openssl provider，如系统安装配置了openssl，则优先使用
2)JDK SSL provider



RocketMQ引用第三方组件netty实现SSL/TLS



\netty-4.1\handler\src\main\java\io\netty\handler\ssl\OpenSsl.java
支持SSL_V2,SSL_V3,TLS_V1,TLS_V_1,TLS_V1_2



\netty-4.1\handler\src\main\java\io\netty\handler\ssl\JdkSslContext.java



0×06 总结

两个可行方法：


建议关键词：RocketMQ 禁用 disable TLSv1.0