TLS with FileZilla FTP Server - TLS data session not resumed

[superflexible 1]

Hello,

I am using ICS v8.67.

 

Trying to make an FTP connection to a FileZilla FTP server, I get:

425 Unable to build data connection: TLS session of data connection not resumed.

 

Is there a setting to share the TLS session between the control and data channels?

 

[Angus Robertson 574]

No real idea what that response means, ICS does not share TLS sessions, they are new for each connection. 

 

Which ICS component are you using?  It should be TIcsFtpMulti for which there is a sample OverbyteIcsXferTst.dpr which will allow you to test again FileZilla saving a proper log that may show the error.

 

Angus

[superflexible 1]

Hello,

I am using TSslFtpClient.

 

I will try TIcsFtpMulti.

 

As you know, the FTP protocol makes two connections, a control channel and a data channel. FileZilla FTP Server requires that these two connections share the same TLS session (or session ID).

 

If the data channel tries to open an independent TLS session, the server rejects it for security purposes.

 

The Internet is full of problem reports related to "TLS session of data connection has not resumed". In older FileZilla Server versions, the requirement could be turned off, but now it is mandatory.

 

[Angus Robertson 574]

The ICS FTP components have been tested regularly against FileZilla Server since 0.9.10 beta 15 years ago as you can read in the source code, can not recall testing it for a while, since I don't recall it every being broken.  If FileZilla has re-invented the FTP protocol in some non-standard way, I'll look at it, once I see full logs from OverbyteIcsXferTst.

 

Angus

 

[superflexible 1]

Hello,

many thanks, I will try to set up a basic testing project and get log files next week.

 

So far only Indy works with FileZilla server, for me. It would be good to have an alternative.

 

[Angus Robertson 574]

OverbyteIcsXferTst.dpr is a complete ready to build testing project, takes a couple of minutes to start downloading stuff, with logs.  I have FileZilla on one of my public servers, will test it later.

 

Angus

 

[superflexible 1]

Hello,

I have tested it with OverbyteIcsXferTst and I get the same error message. I am attaching two log files, a short one and a detailed one.

 

This is a very basic test installation of FileZilla Server v1.1.0. If necessary, I can provide an FTP test account.

 

 

filezillalog_short.txt

 

filezillalog_detailed.txt

Edited January 3, 2022 by superflexible

[Angus Robertson 574]

Thanks, I already have FileZilla installed, albeit an older version, will test later and see what FileZilla has broken.

 

Angus

 

[Angus Robertson 574]

I can find no problem accessing my own FileZilla servers.  My hosted server had v0.9.60 beta from a year ago:

 

> PASV
< 227 Entering Passive Mode (217,146,102,143,82,95)
! Passive connection requested to: 217.146.102.143:21087, control channel: 217.146.102.143
> MLSD /webapps/telerest/templates/testing/
Check for Old SSL Session
Old SSL Session Found Cached
< 150 Opening data channel for directory listing of "/webapps/telerest/templates/testing"
! SSL Connected OK with TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384, key auth ECDSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD
filezilla.ftptest.org SSL Connected OK with TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384, key auth ECDSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD
< 226 Successfully transferred "/webapps/telerest/templates/testing"

 

It seems after a decade of beta releases, v1 finally came out this summer, so I installed v1.2.0 on my hosted server, unfortunately Windows Firewall blocks it, despite it being added manually, so installed it locally, and it also works. 

15:05:41:693 > PASV
15:05:41:693 Starting SSL Session
15:05:41:693 Cache SSL Session: New
15:05:41:693 < 227 Entering Passive Mode (192,168,1,105,251,19)
15:05:41:693 ! Passive connection requested to: 192.168.1.105:64275, control channel: 192.168.1.105
15:05:41:693 > LIST
15:05:41:694 Check for Old SSL Session
15:05:41:695 Old SSL Session Found Cached
15:05:41:695 < 150 Starting data transfer.
15:05:41:697 ! SSL Connected OK with TLSv1.3, cipher TLS_AES_256_GCM_SHA384, encryption AESGCM(256), message auth AEAD
15:05:41:697 pc21-web5.magenta SSL Connected OK with TLSv1.3, cipher TLS_AES_256_GCM_SHA384, encryption AESGCM(256), message auth AEAD

 

So no idea why you are seeing error 425, is there something more useful in the FileZilla server log? 

 

If this is something to do with re-using SSL sessions, when ICS caches a session it adds the port number to the IP address when saving it, to prevent different services being accessed by the same session, but this is effectively what happens with the FTP data channel.  So in TIcsFtpMulti you could try removing  FtpCli.ControlSocket.PeerPort from xxNewSession and xxGetSession and see that improves matters.  I'm not going to change this until I find out how FileZilla is configured to cause the error.

 

Angus

 

 

[superflexible 1]

Hello,

many thanks, I will try this! I will also provide a server login to test for you, so you can see it happening for yourself.

 

 

[superflexible 1]

Hello,

I just tried it. Changes to GetSession or NewSession don't help because these functions are always called with the main FTP port, not the passive mode port number.

 

I just found that it works fine with TLS 1.3 but not with TLS 1.2! If you change it to 1.2, you can probably see the problem with your local FileZilla too.

 

Interesting. I guess not a problem then, I will just use TLS 1.3.

 

 

[Angus Robertson 574]

Okay, I can reproduce it by forcing ICS to use TLSv1.2.  So not sure if this is really a FileZilla bug given it works on the older versions that did not support TLSv1.3. 

 

The old version also has a configuration option 'require TLS session resumption of data connection when using PROT P' which sound like the error message, but I have that ticked on the old beta, and that setting and lots of other interesting and useful ones have disappeared from the new version. 

 

Seems like users should go back to the reliable beta rather than the 'release' version <g>

 

Angus

[superflexible 1]

Hi,

yes I agree it really looks like a FileZilla bug!

 

Many thanks for your help, I saw TLS 1.3 in your log and then I thought that might be it.

 

[Angus Robertson 574]

You said you did not get the error with Indy, was that using TLSv1.3?  If this is down to re-using TLS sessions, it might our caching is broken, despite the logging suggesting it is attempting to re-use an old session.  Without tracing TLS packets, which is tedious, hard to know if caching really works.

 

Angus

 

[superflexible 1]

Hi,

many thanks for double-checking on this, I will look into it and compare the two libraries. I didn't intentionally choose TLS 1.3 with Indy, but maybe it was chosen by the library.

 

And another customer did have problems with Indy too. So there might be other factors and it might still be a FileZilla bug.

 

[Angus Robertson 574]

Did a quick Google search for the error, seems the developer has messing with this 'security feature' for years causing a lot of problems, and recently with TLSv1.3  that changed how sessions are created. and in fixing 1.3 probably broke 1.2.  What is really needed is the tick box to turn off the feature, which seems to have gone. 

 

I'm removing the port from the session cache name anyway, since conceptually it is wrong even if it does not fix this particular bug, it should save one TLS session set-up.

 

Angus