JDK 8u161中的Apache FTPS客户端中的SSL会话重用 [英] SSL Session reuse in Apache FTPS client in JDK 8u161

问题描述

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

这通常可以在服务器，但这是

• 不安全


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

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

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

这个破解工作正常直到JDK 8u161和9.0.4（？）推出一些对SSL的更改，这些更改在更新日志。显然，一些实现细节已经改变，导致黑客无法再工作。

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

• 留在JDK 8u152上，直到有人发现解决方案/ apache-commons-net获取修补程序/ JDK更改回滚（不是真正的选项，因为那样会从安全更新中切断生产系统）


• 使用不同的FTPS客户端（我能找到的唯一替代品是专有的，而且相当昂贵）。反向设计对 SSLSessionContext 实现的更改以找到新的解决方法。这不仅仅是一个不小的任务 - 一个解决方案可能会再次被黑客攻击，因此可能随时再次破解。


• 不要再使用FTP / S
li>

任何人都可以建议如何在这里继续？

---

相关链接：

• http://mail.openjdk.java.net/pipermail/security-dev/2016-December/015254.html
>

• https://bugs.openjdk.java.net/浏览/ JDK-8170813


• https://issues.apache.org/jira/browse/NET-426

解决方案

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

埃森特最重要的是，它正在将改变的行为从JDK8u161恢复到之前的工作方式。您需要设置系统属性

  jdk.tls.useExtendedMasterSecret 
  

到 false 来做到这一点。

有两种方法：

• 调用 System.setProperty（jdk.tls.useExtendedMasterSecret，false）; 在启动FTP / S连接之前


• 通过 java -Djdk.tls.useExtendedMasterSecret = false [ ..]

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

Using Apache Commons-Net's FTPSClient to connect to a modern FTP/S server does not work. The reason is that they require SSL session reuse, i.e. the SSL session from the control connection needs to be re-used for the data connection.

This can usually be deactivated in the server, but that is

• insecure
• not always an option (since the server might not be under your control)

The correct solution would be to make the client actually re-use sessions. There is an open bug for Commons-Net but it does not look like that is going to be resolved any time soon.

Also, there is a "reflection hack" that was created by the authors of Cyberduck (an FTP client application) which is described in their bugtracker and, more in-depth, in a blog post. There is also a related post on StackOverflow describing this solution. They use reflection to access the internal cache of the JDK's SSLSessionContext and inject a new entry.

This hack worked fine until JDK 8u161 and 9.0.4 (?) where some changes to SSL were introduced that are described in the changelog. Apparently, some implementation details have changed causing the hack to not work any more.

As far as I can tell, there are the following options now:

• Stay on JDK 8u152 either until someone finds a solution/apache-commons-net gets patched/JDK changes get rolled back (not really an option, because that would cut off production systems from security updates)
• Use a different FTPS client (the only alternative I could find is proprietary and quite expensive)
• Try to reverse engineer the changes to the SSLSessionContext implementation to find a new workaround. Not only does this seem like a non-trivial task - a solution would likely be hacky again and is thus likely to break again any time.
• Do not use FTP/S any more

Can anyone suggest how to proceed here?

---

Related links:

• 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

解决方案

A possible solution is described here.

Essentially, it is reverting changed behavior from JDK8u161 to the way this worked before. You need to set the system property

jdk.tls.useExtendedMasterSecret

to false to do that.

There are two ways:

• call System.setProperty("jdk.tls.useExtendedMasterSecret", "false"); before initiating the FTP/S connection
• Pass the property to your java process with java -Djdk.tls.useExtendedMasterSecret=false [...]

Keep in mind that this solution disables a security enhancement JVM-wide - proceed with caution.

这篇关于JDK 8u161中的Apache FTPS客户端中的SSL会话重用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！