Android Question FTPS - require TLS session resumption on data connection

[togax]

I've been doing some FTP coding using the standard Net library with much success. One issue I've come across is the support for FTPS (FTP over TLS) is missing one feature. I've been testing my code against a FileZilla FTP server. The following startup code works fine as long as the server setting for "Require TLS session resumption on data connection when using PROT P" is disabled as shown in the attached screenshot. Would it be possible to update the Net library to accommodate such a feature?

If FirstTime Then
    FTP.Initialize("FTP", "xxxxx", 21, "xxxxx", "xxxxx")
    FTP.PassiveMode=True
    FTP.UseSSLExplicit = True
    ssltrustmanager.InitializeAcceptAll
    FTP.SetCustomSSLTrustManager(ssltrustmanager)
End If

 

[togax]

Oh BTW, the error message I get on the phone via Msgbox(LastException,"Error connecting") is:
(SSL Exception) javax.net.ssl.SSLException:Connection closed by peer

and on the FTP server log file:
450 TLS session of data connection has not resumed or the session does not match the control connection

 

[Erel]

I think that this is an OS feature. I don't see how it can be added to the Net library. The SSL handshake is done by the OS.

 

[togax]

I think that this is an OS feature. I don't see how it can be added to the Net library. The SSL handshake is done by the OS.

I've searched through the FileZilla forum and there were similar discussions with other FTP client utilities and often the fix was done by the developer or vendor in a later release of the client. This does indicate the handshaking is done inside the client but you may still be correct in that it's system dependent. I'll investigate it further.

Notre that TLS session resumption is an important security feature; it prevents FTP data connection stealing attacks.

 

[togax]

I had a look at the SSLSocket classes used by another Android development tool and it talks about caching session ids or session tickets for reuse and checking the secondary data connections associated with FTP over TLS sessions are still authentic. I would say don't worry about it for now. I'll instigate my own method of checking that each transfer is authentic to prevent a man-in-the-middle attack of the secondary data connections.