最近的 Java 升级导致椭圆曲线服务器证书的 TLS 握手失败？

Posted 2023-02-22

【中文标题】最近的 Java 升级导致椭圆曲线服务器证书的 TLS 握手失败？

【英文标题】：Recent Java upgrade causes TLS handshake failure with elliptic curve server certificate?

【发布时间】：2020-02-22 01:25:08

【问题描述】：

10 月 19 日，我升级到 OpenJDK Java 1.8.0_232，我的 Java 进程开始无法使用 EC 服务器证书连接到由 stunnel 提供的服务。我有一个 EC 客户端证书，如果初始握手成功，我会向服务器出示该证书，但还没有到那么远。

我无法获得正在运行的上一个 Java 版本的版本号——我在客户端上有一个长时间运行的进程，它能够成功连接到服务。 Java 已升级，但该客户端自升级后未重新启动。我重新启动了客户端，它也开始失败。

我即将开始阅读announcement 以查看其中是否有任何建议“修复”某事的内容，但我相信我已在客户端和服务器上正确配置了所有内容。我目前的想法是这是JVM中的一个错误。

使用ssltest，只要我使用 Java 1.8.0_181 或 Java 11.0.3（这些是我碰巧在我的笔记本电脑上放置了两个版本进行测试）。使用 Java 1.8.0_232 时，使用相同的文件、命令行等会失败。

有人见过这样的吗？

更新

我已经从here 下载了 x86-64 OpenJDK 版本 8u222 和 8u232，我可以确认版本 8u222 会连接，而 8u232 不会连接。

更新 降级到以前版本的OpenJDK，暂时解决了我的问题。我正在使用 Debian Stretch，并且可以使用以下命令降级：

$ sudo apt-get install openjdk-8-jdk-headless=8u222-b10-1~deb9u1 openjdk-8-jre-headless=8u222-b10-1~deb9u1

请注意，我只安装了“无头”包，所以我只降级了“无头”包。

更新 我可以在这里确认客户端证书是红鲱鱼。我放宽了对服务器的要求，不需要客户端证书，并且初始 TLS 握手仍然失败。我正在尝试将其缩小到我能得到的最简单的测试用例。

更新 仍在尝试诊断问题，在这里。我有一个测试服务器，我可以在各种配置下启动它，看看会发生什么。我已经确定，虽然 Java 8u222 支持 secp256k1 曲线，但 Java 8u232 不支持，因此握手失败。

【问题讨论】：

可能与客户端和服务器没有共同的密钥交换算法有关，以便他们可以协商/同意建立连接？

secp256k1 曲线已被 jdk 8u232 禁用（请参阅 java.com/en/download/faq/release_changes.xml）。它可以通过java系统属性jdk.tls.namedGroups重新启用。

@SteveHarrington 我写了一个客户端+服务器，它们在一个进程中一起运行。它在 8u222 中运行良好，但在 8u232 中由于握手失败而失败。连接的服务器端没有错误；它只是在握手失败。我本来希望服务器无法以不受支持的密钥算法启动。

@FelixSchumacher 非常感谢您的参考；愚蠢的我没有看到它。我正在阅读发布公告，奇怪的是没有提到大规模禁用高达 7 曲线。把它变成一个答案，我会接受它。

【参考方案1】：

secp256k1 曲线已被 jdk 8u232 禁用（请参阅https://java.com/en/download/faq/release_changes.xml）。可以通过java系统属性jdk.tls.namedGroups重新启用。

常见问题解答中的示例列出了其他一些也被禁用的过时的 NIST EC 曲线。列出的曲线有sect283k1、sect283r1、sect409k1、sect409r1、sect571k1、sect571r1 和secp256k1。系统属性jdk.tls.namedGroups 采用逗号分隔的这些名称列表。

【讨论】：

我写了一些代码来询问Provider 支持哪些曲线，并且在两个版本中，曲线都表示它们受支持。你知道如何找出哪些曲线实际上是启用的吗？