Grpc-java client with TLS

[Dino Wernli]

Hi grpc-io

I am currently building Polyglot, a universal grpc client which figures out how to talk to any grpc server at runtime (based on proto files or proto descriptors). As part of that, I would like to get the client to open TLS connections and I have done the following:

- Added the BoringSSL uberjar to my bazel WORKSPACE 

- Constructed an SslContext when creating the client channel

However, when I try connecting to a grpc server (written in go) using TLS this way, I get the stack trace depicted at [1]. I then found this thread which seems to suggest I should use GrpcSslContexts.java to create my SslContext instead, but then I get the stack trace depicted at [2]. The fact that some kind ALPN negociation is failing could also mean it's an HTTP2 thing. The versions of the various libraries I'm using can be found in the WORKSPACE file linked above.

Am I doing something wrong? I could imagine a variety of potential solutions involving things like upgrading grpc, upgrading netty, adding things to my classpath, etc. Unfortunately, I was not able to find a working combination so far. Does anyone have any pointers?

Thanks a lot

Dino Wernli

[1]

java.util.concurrent.ExecutionException: io.grpc.StatusRuntimeException: UNKNOWN

at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:476)

at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:455)

at polyglot.Main.main(Main.java:49)

Caused by: io.grpc.StatusRuntimeException: UNKNOWN

at io.grpc.Status.asRuntimeException(Status.java:431)

at io.grpc.stub.ClientCalls$UnaryStreamToFuture.onClose(ClientCalls.java:358)

at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$3.runInContext(ClientCallImpl.java:462)

at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:54)

at io.grpc.internal.SerializingExecutor$TaskRunner.run(SerializingExecutor.java:154)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at java.lang.Thread.run(Thread.java:745)

Caused by: java.lang.Exception: Failed ALPN negotiation: Unable to find compatible protocol.

at io.grpc.netty.ProtocolNegotiators$BufferUntilTlsNegotiatedHandler.userEventTriggered(ProtocolNegotiators.java:500)

at io.netty.channel.ChannelHandlerInvokerUtil.invokeUserEventTriggeredNow(ChannelHandlerInvokerUtil.java:75)

at io.netty.channel.DefaultChannelHandlerInvoker.invokeUserEventTriggered(DefaultChannelHandlerInvoker.java:136)

at io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:147)

at io.netty.channel.ChannelInboundHandlerAdapter.userEventTriggered(ChannelInboundHandlerAdapter.java:108)

at io.netty.channel.ChannelHandlerInvokerUtil.invokeUserEventTriggeredNow(ChannelHandlerInvokerUtil.java:75)

at io.netty.channel.DefaultChannelHandlerInvoker.invokeUserEventTriggered(DefaultChannelHandlerInvoker.java:136)

at io.netty.channel.AbstractChannelHandlerContext.fireUserEventTriggered(AbstractChannelHandlerContext.java:147)

at io.netty.handler.ssl.SslHandler.setHandshakeSuccess(SslHandler.java:1203)

at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1018)

at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:912)

at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:369)

at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244)

at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83)

at io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:154)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:154)

at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:913)

at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)

at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:510)

at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:467)

at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:381)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353)

at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742)

... 3 more

[2]

Exception in thread "main" java.lang.IllegalArgumentException: Jetty ALPN/NPN has not been properly configured.

at io.grpc.netty.GrpcSslContexts.selectApplicationProtocolConfig(GrpcSslContexts.java:151)

at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:128)

at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:117)

at polyglot.DynamicGrpcClient.createTlsChannel(DynamicGrpcClient.java:72)

at polyglot.DynamicGrpcClient.create(DynamicGrpcClient.java:32)

at polyglot.Main.main(Main.java:42)

[Eric Anderson]

You should be using GrpcSslContexts. Tcnative isn't setup correctly for you.

io.netty:netty-tcnative-boringssl-static:1.1.33.Fork14 is not an uberjar; just check its file size. I've not seen an uberjar on Maven Central yet. You should choose a platform-specific jar, as we've documented.

Note also that any uberjar won't work with Netty CR3 because the necessary support code isn't present in that version.

As a side note, grpc-java 0.13.2 depends on Netty CR3, not CR1 like you are using. You will get strange methoddef errors if trying to use tcnative Fork14 with netty CR3. This was mentioned in our release notes.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAP7rZ4SbfdZ7QZc8yF369_qU3OuvsmeJdJDAY29gkKJSKjqgsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Dino Wernli]

Hi Eric

Thanks a lot for your response. I have now:

- Updated Netty to CR3 as per your suggestion

- Switched to using the platform-specific version of boringssl-static. FWIW, the reason I had thought this was an uberjar was the documentation here.

- Switched back to using GrpcSslContexts.

And now everything works :) Thanks!

Cheers

Dino

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

[Eric Anderson]

On Tue, Mar 29, 2016 at 1:31 PM, Dino Wernli <dinow...@gmail.com> wrote:

Thanks a lot for your response. I have now:

- Updated Netty to CR3 as per your suggestion

- Switched to using the platform-specific version of boringssl-static. FWIW, the reason I had thought this was an uberjar was the documentation here.

Ah, gotcha. Yeah, that was written before Beta15 was actually released and wouldn't apply to previous versions. And then the actual release had bumps making the uber jar.

We will definitely send out an email to grpc-io mailing list once all the pieces are in place and known to work.

- Switched back to using GrpcSslContexts.

And now everything works :) Thanks!

Excellent. Glad to hear you're working.

[yoga.u...@gmail.com]

I have tried, for longtime with so many solutions and finally, the final solutions works for me.

Solutions:

=========

1.       As suggested by google, use jetty container instead of tomcat, this solution works, but in our production, applications deployed on tomcat container. – No from team

2.       On debugging the gRPC code, found that guava version causing the issue, updated the guava version 18.0, (where in some classes missed in previous versions) , solved the problem , but failed while deploying in CF

3.       Customized emebed-tomcat-core, and it works fine consistently – but team say no to custom tomcat container.

4.       Java –jar apm-asset-xxxx.jar – works fine locally, but need to provide a custom command to CF start, didn’t have luxury to change the CF start process.

5.       Finally, trick, the class loader to use tcnative-boring-ssl, library instead of tomcat-core library at runtime, by providing the following dependency in pom.xml. From past 3 days, this solution is working CF.

 

  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.hibernate</groupId>
            <artifactId>*</artifactId>
        </exclusion>
        <exclusion>

            <groupId>org.apache.tomcat.embed</groupId>

            <artifactId>tomcat-embed-core</artifactId>

        </exclusion>

    </exclusions>

 </dependency>

<dependency>

    <groupId>org.apache.tomcat.embed</groupId>

    <artifactId>tomcat-embed-core</artifactId>

    <scope>provided</scope>

</dependency>