2

I've been trying to SSL-ify my gRPC service (which works fine in plaintext mode). Note: this is in a commercial context which limits some of my options (such as development environment & deployment platform).

I followed SECURITY.md which recommends using OpenSSL ... and therefore netty-tcnative ... which leads to Forked Tomcat Native and a number of choices:

  1. netty-tcnative-{arch} - dynamically linked, requires APR and OpenSSL already installed on target systems
  2. netty-tcnative-boringssl-static-{os_arch} - statically linked to APR and google's OpenSSL fork
  3. netty-tcnative-boringssl-static - statically linked uber jar with native libraries for common platforms
  4. netty-tcnative-openssl-static-{os_arch} - statically linked to APR and OpenSSL ... but isn't on maven central so not my first choice

#3

The doc says #3 is the simplest artifact to use. But, for me, that results in a failure to find netty-tcnative.dll (which, in this case, should come from the jar AFAIK).

#2

This looks to be the next simplest. Supposedly I can use os-maven-plugin to figure out, at build time, the classifier to use for the versions of these artifacts that require one (i.e. 2 and 4). Although it correctly works them out (according to mvn compile output), I get different runtime behaviour:

  • using <classifier>${os.detected.classifier}</classifier> I get java.lang.ClassNotFoundException: org.apache.tomcat.jni.SSL
  • hard-coding to <classifier>windows-x86_64</classifier> I get further but still no cigar: now netty-tcnative won't load: java.lang.UnsatisfiedLinkError: C:\Temp\netty-tcnative1392766600896877072.dll: Can't find dependent libraries (an unusual path because the DLL's been copied from the jar to my temp directory and System.load'ed from there)
    • According to dependency walker, that DLL has a whole stack of dependencies some of which really don't appear on my filesystem. But it seems that's because depends.exe hasn't kept up with the times.
    • The same code also doesn't work on a colleague's PC so it's not just me.
    • And I still have a problem because my target system is RHEL, not Windows (my kingdom for a Linux workstation!). So I'd have to figure out how to fix the ${os.detected.filesystem} problem...

#4

This might work I guess. But it's not on maven central so is not my favoured path.

#1

Probably would work. But means installing APR and OpenSSL on whichever servers we deploy upon. I don't like my chances of that for internal PaaS I have to use. Avoid for now.

TLS with JDK

I might try this. But the doc strongly recommends against it as you have to fiddle with Java's bootclasspath (I can imagine more PaaS obstacles here, perhaps unfounded...). And it's apparently not overly performant (>10x slower than OpenSSL). And it's brittle (Jetty-ALPN version must correspond exactly with JRE in use although it sounds like there may be solutions to this).

The bottom line

If I can't solve this problem, it may kill gRPC for my project. Whether or not that's a bad thing is up for debate... In the meantime, does anyone have any ideas or a working SSL-ified gRPC client/server app (grpc-java/examples all use plaintext only).

Community
  • 1
  • 1
Gavin
  • 1,223
  • 15
  • 20
  • For #3, you have to use at least grpc-java-0.14.0 to pull in a new enough Netty. Also, you need to use at least 1.1.33.Fork16 of tcnative. That said, you'd still encounter the same issue as for #2. We're looking into what's wrong with #2. – Eric Anderson May 18 '16 at 17:41
  • Thanks, I'm now using 1.1.33.Fork16 (was on Fork15 before) but, as you say, I'm still getting the same issue. But it looks like @nmittler is working on that :-) – Gavin May 19 '16 at 09:30
  • FWIW I also switched to grpc-java-0.14.0 (from 0.13.2) to re-try #3 but got IllegalArgumentException (but stepping through the code it looks to have the same root cause as #2's failure: cannot load dependent libraries). – Gavin May 19 '16 at 11:15

1 Answers1

3

This is definitely a netty-tcnative bug. I've just created https://github.com/netty/netty-tcnative/issues/141 and will be looking at reducing the list of dependencies brought in by MSVC.

For now, try building openssl[static/dynamic] yourself and see if that works for you.

nmittler
  • 131
  • 1
  • 3
  • I see you've released 1.1.33.Fork17 which does indeed fix my problem. Thanks very much! – Gavin May 23 '16 at 11:09
  • ... although I now have this problem http://stackoverflow.com/questions/37395579/grpc-ssl-uber-jar-linux-failed-to-load-netty-tcnative – Gavin May 23 '16 at 16:00