With FTP/TLS there is a risk that data connections are guessed by attackers and there is no binding of the login credentials on the control connection and the data connection.
Some FTP servers implement protection about this by requiring the data connection to resume the cached TLS session from the control connection. For example vsftpd 2.1.0 introduced the `require_ssl_reuse` option for this: http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html There is now a problem for Java implementations: if you implement a FTP client (like Apache Commons Net is doing) with SSLSocket (JSSE) you have no control over session re-use. In fact the JSSE internal session context cache is keyed by the destination address and port. The initial control connection is stored under ftp.vendor.com:20 but the additional data connections to random ports like ftp.vendor.com:12345 (or ip:port) will not re-use this cache entry. There have been some discussions in 2010 and Apache Commons Net implemented a hook method which can be used by application code to do some nasty setup. Cyberduck the FTP client for example uses reflection to poke into JSSE internals to provide the same session cache key: https://trac.cyberduck.io/ticket/5087 https://trac.cyberduck.io/changeset/10760 And there is no good solution in Commons Net either: https://issues.apache.org/jira/browse/NET-408 https://issues.apache.org/jira/browse/NET-426 (and a lot of discussions around vsftpd, filezilla, proftpd with Java all over stack exchange) Here I found a good writeup describing the reflection workaround (and the different versions needed): http://eng.wealthfront.com/2016/06/10/connecting-to-an-ftps-server-with-ssl-session-reuse-in-java-7-and-8/ I do wonder is it planned to offer a standard interface to get some more control? Has this been discussed here? The SSLContext provides getClientSessionContext() which talks about "Returns the client session context, which represents the set of SSL sessions available for use during the handshake phase of client-side SSL sockets." but does not make it clear that it uses some strict destination-port filtering. Also SSLSessionContext does not allow to add or modify a session or the cache key. Gruss Bernd
