FileZilla Server 1.0.0-rc5 425 Error data connection not resumed

[joks]

Hello,
my server run under port 2121, passiv port range 30000-30100, i also unblock on server and router port 990.
when i connect to ftp server with WinSCP without encryption i can upload/create new file so everything works.
when i connect to ftp server under WinSCP with explicit encryption i can connect to server i accept the certificate and i can list folder but when i want upload file or delete i have this error:
425 Error while transfering data: TLS session of data connection not resumed.
with older Filezilla server release it was option 'Require TLS session resumption on data connection' but in new version i cant find this option.
any clue how can i fix this error ? or i miss something on firewall/router ? but i test explicit encryption connection also in local network (server and client in the same network with disabled windows firewall) and i have the same error when i connect to server from office to home.

edit:
strange i test explicit encryption connection with filezilla client and with filezilla client works great without error 425 Error while transfering data: TLS session of data connection not resumed.
but under winscp i have automatic scripts that run at a specific time so is it possible to fix it somehow that filezilla server will works with other ftp client like WinSCP ?

[botg]

For security reasons this setting can no longer be changed, resumption is mandatory.

Contact your third-party client vendor for assistance to have the client fixed.

[boco]

Do you have this checked?

2021-09-01 16_15_11-Advanced Site Settings.jpg (33.08 KiB) Viewed 4579 times

[joks]

I tried with this option on and off unfortunately without success. I reported this bug on the winscp forum and noticed that not only I have a problem with it. apparently this will be fixed in a future version 15.9.3 https://winscp.net/tracker/2018 so it is actually not a bug in filezilla server.
anyway, thanks for hard work and release new filezilla server after few years I really appreciate your work

[botg]

Looking at their commits, the changes seem weird. Then again, WinSCP uses OpenSSL which requires users to do weird things, it has a very unfortunate API that leaves much to be desired Anyhow, glad it will be fixed in their next version.

One of the reasons why FileZilla Server 1.x was rewritten from scratch is to move away from OpenSSL, the new server, just like the client, now uses GnuTLS which in my opinion has a much better API.

[martinprikryl]

Hello, OP reported this issue on WinSCP forum:
https://winscp.net/forum/viewtopic.php?t=31396
I'm aware of this problem. It was reported before already. And it will be fixed in the next release:
https://winscp.net/tracker/2018

Though I wanted to note that the behaviour of FileZilla Server 1.0 is unusual (although not necessarily wrong). All other FTP servers (including FileZilla Server 0.9) accept reused session of the control connection for all associated data connections. FileZilla Server 1.0 seems to accept only reused session of the previous connection only. So for the first data connection, is accepts reused session of the control connection. But for further data connections, it accepts only reused session of the previous data connection. I'd expect that not only WinSCP will have a problem with this.

Btw, it works with TLS 1.3. I was not able to reuse session anyhow (even for the first data connection) with TLS 1.2 against FileZilla server 1.0. Though I did not dig deep into this. I could not test this with other clients, as I do not know any that can be configured to use inferior TLS version.

[botg]

FileZilla Server 1.0 seems to accept only reused session of the previous connection only. So for the first data connection, is accepts reused session of the control connection. But for further data connections, it accepts only reused session of the previous data connection.

Very strange, there is no shared state between the control and data connection, except for the session ticket master key and, for TLS <= 1.2 the session identifier itself. In both cases, this data is only ever passed from the control connection to the data connection, it never flows back into the other direction. How are you handling session tickets, as session IDs make no sense with TLS 1.3


Unrelated issue: WinSCP goes into an infinite loop after retrieving a directory listing when there is a file or directory with the filename being purely a single 0x0a byte.

[botg]

I think I found the root cause. Any new session tickets received over the data connection are not associated with the control connection's session if using OpenSSL. It unshares the session structures. See tls_process_new_session_ticket in ssl/statem/statem_clnt.c