JDK 8u161 中 Apache FTPS 客户端中的 SSL 会话重用

Question

使用 Apache Commons-NetFTPSClient连接到现代 FTP/S 服务器不起作用。原因是它们需要 SSL 会话重用，即来自控制连接的 SSL 会话需要重新用于数据连接。

这通常可以在服务器中停用，但那是

• 没有安全感
• 并不总是一个选项（因为服务器可能不受您的控制）

正确的解决方案是让客户端实际重用会话。Commons-Net有一个开放的错误，但它看起来不会很快得到解决。

此外，还有一个由 Cyber​​duck（一个 FTP 客户端应用程序）的作者创建的“反射黑客”，在他们的错误跟踪器中进行了描述，更深入地在博客文章中进行了描述。StackOverflow 上还有一篇相关的文章描述了这个解决方案。他们使用反射来访问 JDK 的内部缓存SSLSessionContext并注入一个新条目。

在 JDK 8u161 和 9.0.4 (?) 之前，此 hack 一直运行良好，其中引入了一些更改日志中描述的 SSL更改。显然，一些实现细节发生了变化，导致黑客不再起作用。

据我所知，现在有以下选项：

• 继续使用 JDK 8u152，直到有人找到解决方案/apache-commons-net 被修补/JDK 更改被回滚（这不是一个真正的选择，因为这会切断生产系统的安全更新）
• 使用不同的 FTPS 客户端（我能找到的唯一替代方案是专有的且相当昂贵）
• 尝试对SSLSessionContext实现的更改进行逆向工程以找到新的解决方法。这不仅看起来像是一项不平凡的任务 - 解决方案可能会再次变得笨拙，因此随时可能再次崩溃。
• 不再使用 FTP/S

任何人都可以建议如何在这里进行？

---

相关链接：

• http://mail.openjdk.java.net/pipermail/security-dev/2016-December/015254.html
• https://bugs.openjdk.java.net/browse/JDK-8170813
• https://issues.apache.org/jira/browse/NET-426

Answer 1

这里描述了一种可能的解决方案。

本质上，它是将 JDK8u161 中更改的行为恢复到之前的工作方式。需要设置系统属性

jdk.tls.useExtendedMasterSecret

来false做到这一点。

有两种方法：

• System.setProperty("jdk.tls.useExtendedMasterSecret", "false");在启动 FTP/S 连接之前调用
• 将属性传递给您的 java 进程java -Djdk.tls.useExtendedMasterSecret=false [...]

请记住，此解决方案会禁用 JVM 范围内的安全增强功能 - 请谨慎操作。