Is Infinispan improperly configuring SslHandler?

[tbmoomau]

My organization has an Sonatype finding (sonatype-2020-0026) on netty-handler, which is a transitive dependency on infinispan-client-hotrod-jakarta. Netty claims the finding to be a "configuration issue". Code using SslHandler should call SSLParameters.setEndpointIdentificationAlgorithm(String):

SSLEngine sslEngine = sslHandler.engine(); SSLParameters sslParameters = sslEngine.getSSLParameters(); // only available since Java 7 sslParameters.setEndpointIdentificationAlgorithm("HTTPS"); sslEngine.setSSLParameters(sslParameters);

Otherwise hostname verification will not be enabled, which could lead to MITM attacks.

I checked the infinispan source code and it is not calling setEndpointIdentificationAlgorithm where SsLHandler is used. I looked in the following files in the client:

• client\hotrod\src\main\java\org\infinispan\hotrod\impl\transport\netty\ChannelInitializer.java
• client\hotrod-client\src\main\java\org\infinispan\client\hotrod\impl\transport\netty\ChannelInitializer.java

Could I be missing something or is infinspan vulnerable?

Last thing, our project uses infinispan-client-hotrod-jakarta (via debezium-connector-oracle). I assume the source code for infinispan-client-hotrod is the same, but just with javax instead of jakarta packages?

Links:
netty/netty#9930 (comment)
https://netty.io/4.1/api/io/netty/handler/ssl/SslContext.html#newHandler-io.netty.buffer.ByteBufAllocator-java.util.concurrent.Executor-

[tristantarrant]

I'll have a look

[tristantarrant]

The fix for this is currently included in #11148

[tbmoomau]

Thanks you!
One other thing, can you confirm for me that when this pull request is released in infinispan-client-hotrod it will also be included in the same version of infinispan-client-hotrod-jakarta?

[tristantarrant]

The jakarta variant is generated automatically using eclipse transformer, so yes

[tristantarrant]

This has been assigned CVE-2023-4586