1

I setup my jdk provider by Security.addProvider(new BouncyCastleFipsProvider()).

Set it in the Grpc client by:

SslContextBuilder sslContextBuilder = SslContextBuilder.forClient()
                    .sslProvider(SslProvider.JDK)
                    .applicationProtocolConfig(new ApplicationProtocolConfig(
                            ApplicationProtocolConfig.Protocol.ALPN, 
                            ApplicationProtocolConfig.SelectorFailureBehavior.NO_ADVERTISE,
                            ApplicationProtocolConfig.SelectedListenerFailureBehavior.ACCEPT,
                            Collections.singletonList("h2")));

When trying to establish the connection, After successful ssl handshake I get:

UNAVAILABLE: Failed ALPN negotiation: Unable to find compatible protocol Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]

I'm using grpc 1.44 version + bc-fips.jar 1.0.2 version.

Running my app by java 11.0.15 compiled by jdk1.8.0_291.jdk. It looks like BouncyCastleFipsProvider, by its SSLParamertesUtil class, somehow remove the "h2" from the suggested application protocols list. increasing grpc version to 1.46 didn't help.

Any suggestions please? Thanks.

yatir dagan
  • 11
  • 2
  • Do you actually have the BCJSSE provider installed from bctls-fips jar? What version? – Peter Dettman Jun 06 '22 at 12:27
  • Yes, Installed. provider version is 1.0011. Btw, it works when running with jdk1.8.0_291.jdk. looks like the implementation for jdk 11+ in the multi-release bctls-fips jar is related to this issue. When debugging i noticed the setApplicationProtocols method is called by grpc lib and override the necessary "h2" suggested protocol. The setApplicationProtocols method is not available in bctls-fips mr jar for jdk 8 which, probably, makes it works for jdk 8. Any suggestion to make it works with jdk 11+? Thanks for your quick response. – yatir dagan Jun 07 '22 at 18:12
  • You would need at minimum bctls-fips-1.0.12.jar (though I recommend the latest 1.0.13). ALPN was backported to Java 8 in update 251 and it took us some time to realise they had done that. – Peter Dettman Jun 08 '22 at 16:03
  • I don't know why it wouldn't work on Java 11 unless you aren't in fact loading it as multi-release. e.g. jars in the bootclasspath are never treated as multi-release jars as I recall. The socket/engine implementations should have names ending in _9 if they have loaded correctly on Java 11 (e.g. ProvSSLSocketDirect_9). – Peter Dettman Jun 08 '22 at 16:17

0 Answers0