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

Question

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

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

• 不安全
• 并不总是一个选项（因为服务器可能不在您的控制之下）

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

此外，还有一个由Cyber​​duck（一个FTP客户端应用程序）的作者创建的“反射黑客”，在in their bugtracker中描述blog post并且更深入。还有一个相关的post on StackOverflow描述了这个解决方案。他们使用反射来访问JDK的SSLSessionContext的内部缓存并注入一个新条目。

这个hack工作正常，直到JDK 8u161和9.0.4（？），其中引入了对changelog中描述的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

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

基本上，它正在将改变的行为从JDK8u161恢复到以前的工作方式。您需要设置系统属性

jdk.tls.useExtendedMasterSecret

到false这样做。

有两种方法：

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

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