FTPS : TLS session of data connection not resumed

Question

Hello.
An error occurred when using FileZiller Server 1.1.0.
"TLS session of data connection not resumed"

Settings.SslReuseSessions = true;
Settings.ReuseControlConnectionSession = true;
Settings.ForceListHiddenFiles = ShowHiddenFiles;
Settings.ConnectPassiveLater = false;
Settings.KeepAliveDuringTransfer = true;
Settings.KeepAliveDuringTransferInterval = 30;
Settings.UseLargeBuffers = true;
Settings.SslAcceptAllCertificates = true;
Settings.SslAllowedVersions = TlsVersion.Any | TlsVersion.SSL30 | TlsVersion.TLS13;
Settings.SslAllowedSuites = TlsCipherSuite.All;
Settings.SslAllowedCurves = TlsEllipticCurve.All;
Connect(FtpAddress, FtpPort, sslMode);

After setting up and connecting like this, I get an error when I get folder lists.

Please let me know what further action I should take.
The log file is long, so I'll attach it by e-mail.

Thank you.

Comments

Hi,
thanks for the report. We are investigating the issue.

Answer 1

The behavior lanopk reported we have classified as a bug in FileZilla behavior. We most likely add a workaround in one of our next releases.

Details:
1) FTP control connection - Rebex client sends ClientHello with pskkeyexchangemodes extension and advertises that supports both pskke, pskdheke.
From our point of view, this behavior strictly conforms to TLS 1.3 specification.

" The semantics of this extension are that the client only supports the use of PSKs with these modes, which restricts both the use of PSKs offered in this ClientHello and those which the server might supply via NewSessionTicket.“

See details here.
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.9

2) The handshake is completed, but the FileZilla server does not send NewSessionTicket.

3) FTP data connection requires that the client uses (New)SessionTicket from the FTP control connection. But we don't have any session tickets. TLS handshake for data connection is completed, but communication fails with ". "TLS session of data connection not resumed" exception.

The workaround is simple - we are sending psk_dhe_ke mode only in the psk_key_exchange_modes extension and then FileZilla provides NewSessionTicket that we can use when securing FTP data connection.

Comments

Thank you very much for the detailed answer.

---

Also, please note that the workaround will only work with FileZilla servers that are configured to use explicit FTP/TLS security (usually running over port 21). With servers that use implicit FTP/TLS, it's not possible to easily detect the server before TLS negotiation, which means the workaround won't be effective. We could add an option to enable it, but hopefully this will get fixed in FileZilla Server before it's needed.

---

So, does FileZiller know about this?
Or should I report this issue to FileZiller?

---

We didn't create a bug report on the FileZilla site  - yet.
Feel free to report this issue yourself.

---

Hello.
I contacted FileZiller and got a response.
Please see the link below.

If using TLS 1.3, FileZilla Server sends NewSessionTicket in response to EPSV/PASV/EPRT/PORT. According to 8446, servers can send it at any time after the handshake completes.

https://forum.filezilla-project.org/viewtopic.php?f=6&t=54333

---

Hello,
thanks for the response
.
Please see the part of the log for the successful connection.

2021-12-14 09:47:11.416 INFO Ftp(3)[15] Command: PASV

****2021-12-14 09:47:11.427 DEBUG Ftp(3)[5] TLS: HandshakeMessage:NewSessionTicket was received.*****

2021-12-14 09:47:11.480 INFO Ftp(3)[15] Response: 227 Entering Passive Mode (192,168,37,66,212,70)

2021-12-14 09:47:11.480 DEBUG Ftp(3)[15] Info: Establishing data connection to 192.168.37.66:54342.
2021-12-14 09:47:11.480 DEBUG Ftp(3)[15] Proxy: Connecting to 192.168.37.66:54342 (no proxy).
2021-12-14 09:47:11.532 DEBUG Ftp(3)[15] Proxy: Connection established.
2021-12-14 09:47:11.532 DEBUG Ftp(3)[15] Info: Established data connection from 192.168.37.138:49339.
2021-12-14 09:47:11.533 INFO Ftp(3)[15] Command: MLSD
2021-12-14 09:47:11.590 INFO Ftp(3)[15] Response: 150 Starting data transfer.
2021-12-14 09:47:11.590 DEBUG Ftp(3)[15] Info: Upgrading data connection to TLS.
[...]
After FTP PASV command and before the response to the PASV command is read NewSessionTicket is received.
So the scenario works as described by the FileZilla.

Part of the log from the failed connection.

2021-12-14 10:10:34.801 INFO Ftp(2)[14] Command: PASV

****The line present in the previous log is missing. NewSessionTicket is not received. ****

2021-12-14 10:10:34.813 INFO Ftp(2)[14] Response: 227 Entering Passive Mode (192,168,37,66,212,78)
2021-12-14 10:10:34.816 DEBUG Ftp(2)[14] Info: Establishing data connection to 192.168.37.66:54350.
2021-12-14 10:10:34.818 DEBUG Ftp(2)[14] Proxy: Connecting to 192.168.37.66:54350 (no proxy).
2021-12-14 10:10:34.830 DEBUG Ftp(2)[14] Proxy: Connection established.
2021-12-14 10:10:34.830 DEBUG Ftp(2)[14] Info: Established data connection from 192.168.37.138:52645.
2021-12-14 10:10:34.831 INFO Ftp(2)[14] Command: MLSD
2021-12-14 10:10:34.884 INFO Ftp(2)[14] Response: 150 Starting data transfer.
2021-12-14 10:10:34.885 DEBUG Ftp(2)[14] Info: Upgrading data connection to TLS.
[...]
2021-12-14 10:10:35.070 INFO Ftp(2)[14] Response: 425 Unable to build data connection: TLS session of data connection not resumed.


The only difference between these two scenarios is the following:
1) First scenario allows only PskKeyExchangeMode.psk_dhe_ke mode. (our workaround is active).
2) Second scenario allows both PskKeyExchangeMode.psk_ke and PskKeyExchangeMode.psk_dhe_ke modes.

---

I understand the situation very well.
However, I am confused.
Should I ask FileZilla again with the above?
Or do I need to configure something in Rebex R6.0?

---

This workaround didn't make it to R6, sorry. We are still testing the workaround.
In the meantime, you may want to contact the FileZilla developer again. I think that the behavior of the FileZilla server is (at least) surprising and users of the FileZilla server will benefit from the fix.

---

it seems to be a GnuTLS bug.
https://gitlab.com/gnutls/gnutls/-/issues/1303

---

Hi lanopk,
thanks for letting us  know.

---

R6.1 has a workaround for this issue, which is enabled if FileZilla is detected. To enable it for other servers, call this before the Connect method:
    Rebex.Security.Cryptography.CryptoHelper.SetOption(ftp, "UseOnlyPskDhKeMode", true); // 'ftp' is an instance of Ftp object