BouncyCastle support for client TLS - exists, planned, can be worked around?

[scotthraban]

GrpcSslContexts has handling for JSSE providers from SunJSSE / IBMJSSE2 / OpenJSSE (specifically in findJdkProvider and configure), but not for BouncyCastle FIPS, which has a provider name of BCJSSE.

#9239 suggests that GrpcSslContexts should be used, but calls out that bc-fipsdoes not provide TLS, which is correct, however bctls-fips is the library that does add TLS support. bc-fips only provides the JCE provider, while bctls-fips provides the JSSE provider that is needed.

If support cannot be added, are there any suggestions for manually configuring to use BouncyCastle? This is a requirement for our project. The call to GrpcSslContexts.forClient() is very deep inside the channel builder code, I don't see a way, without replicating much code, of hooking out to get the BC JSSE Provider :(.

It does appear that Netty (which we are using) supports BouncyCastle, io.netty.handler.ssl.BouncyCastleAlpnSslUtils being referenced from #11441, but it is unclear from that question how the OP even got that far.

Thanks for your time!

TAG: @ejona86

[ejona86]

#9239 suggests

I said that it might be a pretty small change to GrpcSslContexts to add the support, and linked to the relevant lines. Are you able to check whether something like that works?

The call to GrpcSslContexts.forClient() is very deep inside the channel builder code

There is an API on the builder to set the SslContext yourself (this is the old way):
https://grpc.github.io/grpc-java/javadoc/io/grpc/netty/NettyChannelBuilder.html#sslContext(io.netty.handler.ssl.SslContext)

And it is also available in the newer Credentials-based approach, where you pass the credentials in when creating the channel/server builder:
https://grpc.github.io/grpc-java/javadoc/io/grpc/netty/NettySslContextChannelCredentials.html

[scotthraban]

I was able to make some progress, with copious amounts of copying code from GrpcSslContexts, but not all the way.

        for (Provider provider : Security.getProviders("SSLContext.TLS")) {
            // BouncyCastleJsseProvider.PROVIDER_NAME is "BCJSSE", if there is a need to make this check
            // without the bctls-fips library being an explicit dependency.
            if (BouncyCastleJsseProvider.PROVIDER_NAME.equals(provider.getName())) {
                // Borrowed the implementation of the isJava9AlpnAvailable method from JettyTlsUtil
                if (isJava9AlpnAvailable()) {

                    // Copied from GrpcSslContexts
                    List<String> NEXT_PROTOCOL_VERSIONS = Collections.unmodifiableList(Arrays.asList("h2"));

                    // Copied from GrpcSslContexts static initializer
                    ApplicationProtocolConfig ALPN = new ApplicationProtocolConfig(Protocol.ALPN, SelectorFailureBehavior.NO_ADVERTISE,
                            SelectedListenerFailureBehavior.ACCEPT, NEXT_PROTOCOL_VERSIONS);

                    return NettySslContextChannelCredentials
                            .create(SslContextBuilder.forClient()

                                    // Copied from GrpcSslContexts.configure for ALPN
                                    .sslProvider(SslProvider.JDK)
                                    .ciphers(Http2SecurityUtil.CIPHERS, SupportedCipherSuiteFilter.INSTANCE)
                                    .applicationProtocolConfig(ALPN)
                                    .sslContextProvider(provider)

                                    .build());
                }
            }
        }

Unfortunately, this results in an error of:

01:07:49.583 ERROR --- [-worker-ELG-6-2] i.n.h.ssl.BouncyCastleAlpnSslUtils       :   Unable to initialize BouncyCastleAlpnSslUtils.
java.lang.IllegalArgumentException: object is not an instance of declaring class
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.checkReceiver(DirectMethodHandleAccessor.java:197)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:99)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at io.netty.handler.ssl.BouncyCastleAlpnSslUtils.<clinit>(BouncyCastleAlpnSslUtils.java:89)
    at io.netty.handler.ssl.BouncyCastleAlpnSslEngine$2.accept(BouncyCastleAlpnSslEngine.java:41)
    at io.netty.handler.ssl.BouncyCastleAlpnSslEngine$2.accept(BouncyCastleAlpnSslEngine.java:38)
    at io.netty.handler.ssl.JdkAlpnSslEngine.<init>(JdkAlpnSslEngine.java:97)
    at io.netty.handler.ssl.BouncyCastleAlpnSslEngine.<init>(BouncyCastleAlpnSslEngine.java:31)
    at io.netty.handler.ssl.JdkAlpnApplicationProtocolNegotiator$AlpnWrapper.wrapSslEngine(JdkAlpnApplicationProtocolNegotiator.java:138)
    at io.netty.handler.ssl.JdkSslContext.configureAndWrapEngine(JdkSslContext.java:383)
    at io.netty.handler.ssl.JdkSslContext.newEngine(JdkSslContext.java:357)
    at io.grpc.netty.ProtocolNegotiators$ClientTlsHandler.handlerAdded0(ProtocolNegotiators.java:654)
    at io.grpc.netty.ProtocolNegotiators$ProtocolNegotiationHandler.handlerAdded(ProtocolNegotiators.java:1141)

At first I thought that this was a problem with a class mismatch because I was not using grpc-netty-shaded, but switching to gprc-netty-shaded gives the same error.

(FWIW, using grpc-netty-shaded is a no go, since it included various CVEs that are fixed in newer versions of netty-handler.)