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

[David M. Lloyd]

I haven't run into this personally, but I may soon, so I have a 
question: did anyone try simply lying about the destination port (which 
is easy with SSLEngine, but might only be possible for SSLSocket if you 
do something funny with socket factorys - or maybe not at all)?

On 12/06/2016 11:56 AM, Xuelei Fan wrote:
> Hi Bernd,
>
> Thanks for the enhancement request.
>
> I filed a new Request For Enhancement (RFE) so that we can track the issue:
>    https://bugs.openjdk.java.net/browse/JDK-8170813
>
> Regards,
> Xuelei
>
> On 12/5/2016 11:58 AM, Bernd Eckenfels wrote:
>> 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
>>

-- 
- DML