gRPC + SSL = UnsatisfiedLinkError

Question

我一直在尝试对我的 gRPC 服务进行 SSL 化（在纯文本模式下运行良好）。注意：这是在商业环境中限制了我的一些选择（例如开发环境和部署平台）。

我关注了SECURITY.md，它建议使用 OpenSSL ...，因此netty-tcnative ...导致Forked Tomcat Native 和许多选择：

1. netty-tcnative-{arch} - 动态链接，需要已在目标系统上安装 APR 和 OpenSSL
2. netty-tcnative-boringssl-static-{os_arch} - 静态链接到 APR 和谷歌的 OpenSSL 分支
3. netty-tcnative-boringssl-static - 静态链接 uber jar 与通用平台的原生库
4. netty-tcnative-openssl-static-{os_arch} - 静态链接到 APR 和 OpenSSL ...但不在 maven Central 上，所以不是我的首选

#3

文档说#3 是最简单的工件。 但是，对我来说，这会导致无法找到 netty-tcnative.dll（在这种情况下，它应该来自 jar AFAIK）。

#2

这看起来是最简单的。 假设我可以使用os-maven-plugin 在构建时找出用于这些工件版本的分类器，这些版本需要一个（即 2 和 4）。 尽管它可以正确解决它们（根据mvn compile 输出），但我得到了不同的运行时行为：

• 使用<classifier>${os.detected.classifier}</classifier> 我得到java.lang.ClassNotFoundException: org.apache.tomcat.jni.SSL
• 硬编码到<classifier>windows-x86_64</classifier> 我得到了进一步但仍然没有雪茄：现在netty-tcnative 不会加载：java.lang.UnsatisfiedLinkError: C:\Temp\netty-tcnative1392766600896877072.dll: Can't find dependent libraries（一个不寻常的路径，因为 DLL 已从 jar 复制到我的临时目录和System.load从那里编辑）
  • 根据dependency walker，该DLL 有一个完整的依赖堆栈，其中一些确实没有出现在我的文件系统中。但这似乎是因为depends.exe hasn't kept up with the times。
  • 同样的代码也不能在同事的电脑上运行，所以不只是我。
  • 我仍然有一个问题，因为我的目标系统是 RHEL，而不是 Windows（我的 Linux 工作站王国！）。所以我必须弄清楚如何解决${os.detected.filesystem} 问题...

#4

我猜这可能有用。但它不在 maven central 上，所以不是我喜欢的路径。

#1

可能会起作用。但这意味着在我们部署的任何服务器上安装 APR 和 OpenSSL。我不喜欢我必须使用内部 PaaS 的机会。暂时避免。

TLS 与 JDK

我可能试试这个。 但是the doc 强烈建议您不要这样做，因为您必须摆弄 Java 的引导类路径（我可以在这里想象更多的 PaaS 障碍，也许是没有根据的......）。 而且它的性能显然并不过分（比 OpenSSL 慢 10 倍以上）。 而且它很脆弱（Jetty-ALPN 版本必须与使用的 JRE 完全对应，尽管听起来可能有解决方案）。

底线

如果我不能解决这个问题，它可能会为我的项目杀死 gRPC。这是否是一件坏事还有待商榷......与此同时，有没有人有任何想法或工作的 SSL 化 gRPC 客户端/服务器应用程序（grpc-java/examples 都只使用纯文本）。

Answer 1

这绝对是一个 netty-tcnative 错误。我刚刚创建了https://github.com/netty/netty-tcnative/issues/141，并将考虑减少 MSVC 引入的依赖项列表。

现在，尝试自己构建 openssl[static/dynamic] 看看是否适合您。