IBM MQ Cipher Suite更新

最新推荐文章于 2024-12-31 17:34:13 发布

我爱读历史

最新推荐文章于 2024-12-31 17:34:13 发布

阅读量380

点赞数

CC 4.0 BY-SA版权

文章标签： java log4j jvm

本文链接：https://blog.csdn.net/weixin_43280180/article/details/128627132

文章讲述了在系统升级过程中遇到的IBMWebsphereMQ与JAVACipherSuite的兼容性挑战。从SSLv3到TLS1.2，每次更新都涉及到IBM和Sun的安全提供方。在最新的更新中，由于IBM与Sun对CipherSuite的前缀不同导致问题，通过反编译和调整JVM系统变量解决。作者批评了IBM的技术文档难以理解和其JAVA的不兼容性设计。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

最早我们使用IBM Websphere MQ, 用JAVA 6，CipherSuite用的是SSLv3上面的。

更新CipherSuite必然牵扯到安全的使用方IBM和安全的供应方Sun，因为security provider一般是用Sun的类库。

之后系统安全性要求更新到TLS1.0，CipherSuite要求TLS_RSA_WITH_3DES_EDE_CBC_SHA。之前由于对JAVA不熟悉，即使升级了JAVA的版本，依然无法用新的CipherSuite，还是学艺不精啊。

2018年系统技术更新，JAVA更新到8，并且必须解决TLS1.0的问题。通过反编译IBM和Sun的代码，发现修改JAVA的设置就能解决TLS1.0的问题，之后高枕无忧了一段日子，想着这个麻烦的事情不会再来了。

2022年由于log4j的安全漏洞，系统整体的技术更新再一次提上日程，好在ciphersuite不需要修改，JAVA更新到17，通讯依然没有问题，再一次很侥幸地躲过了ciphersuite的麻烦。

最近MQ服务器端更新，ciphersuite更新到TLS1.2，要求是TLS_RSA_WITH_AES_256_GCM_SHA384。通常IBM会把CipherSuite的TLS写成SSL，之前这样写，IBM和Sun都是支持的，现在这样写就不能了。

写成SSL_RSA_WITH_AES_256_GCM_SHA384的时候，IBM没问题，Sun表示不支持，错误代码2393。

写成TLS_RSA_WITH_AES_256_GCM_SHA384的时候，IBM表示不支持，错误代码2400。

还是得进行反编译，发现代码出错的原因，根据传统的方法在JAVA17里面找Sun的代码，根本找不到，最后发现是一个Zip文件，好不容易解压打开了，还是没找到相关的类库。后来在jmod文件里面比对才找到真正的类库，发现二者是真的不兼容，用Sun就必须用TLS开头的。从IBM的代码看来，它用的CipherSuite就是SSL开头的，那怎么办？后来突然发现还有一个CipherSuite集合，与sun吻合，但是由一个布尔变量控制，叫做useIBMCipherMappings，也有人说JVM系统变量如下可以解决这个问题-Dcom.ibm.mq.cfg.useIBMCipherMappings=false。试着在JAVA命令行加入这个变量，似乎不管用。最终在代码中加入，问题顺利解决了。

通过这个问题，充分体会到反编译的重要性，否则任何问题的解决都是很盲目的，可能会多走很多弯路，甚至无路可走。

早期我们遇到SSLv3的问题时，也曾经找过IBM，但是似乎不得其法，感觉IBM的文档真的不是写给人看的，一大堆文章，又臭又长，根本不得要领，这是我对IBM的第一个槽点，这样的技术氛围，怎么发展？

另外一个槽点就是，IBM为什么要搞自己的JAVA，还把CipherSuite的写法搞得不兼容？JAVA的推出不就是为了形成一个兼容性很强的生态，比如使用相同的接口，使用方可以切换不同的供应方嘛。当初微软也推了一个自己的跟人家不兼容的JAVA，因为不太有人使用，自行消亡了。IBM是真的很固执啊，就是不愿意向Oracle靠拢，问题是除了IBM的产品，还有谁在用IBM的JAVA。