TLS session cache access (for FTP clients with data connection session reuse)

[Bernd Eckenfels]

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