TLS session of data connection not resumed Error (v1.1.0)

[lanopk]

Hello.
Communication fails between FileZilla Server Version 1.1.0 and Rebex FTPS client.
Rebex Client throws error "425 Unable to build data connection: TLS session of data connection not resumed".
This error is from FileZilla Server.
I tried to connect by specifying the tls version as "TLS 1.3 | TLS 1.2 | TLS 1.0 | SSL3.0".

I reported this problem to Rebex company, and Rebex company sent me the following reply.

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 the 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/r ... tion-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.

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.


I hope this issue gets fixed soon.

Thank you.
Best Regards.

BooKyung Oh.
OpenboxLab Inc.

[botg]

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.

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.

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.

What is the workaround?

[lanopk]

Hello.
I contacted Rebex again and got the following response.
At the end of the response, it is written what kind of problem there is.

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.

[botg]

Going on a hunch here: In which order do the PSK modes appear in the ClientHello? Ideally, please attach a Wireshark dump showing the entire conversation.

[Styx31]

We have exactly the same error occurring from various clients since we upgraded to the new FileZilla server engine.

One of the clients is a component we use in our company. Here is the log I have received:

Code: Select all

ChilkatLog:
  PutFileFromBinaryData:
    DllDate: Sep 28 2020
    ChilkatVersion: 9.5.0.84
    UnlockPrefix: (redacted)
    Architecture: Little Endian; 64-bit
    Language: .NET 4.8 / x64
    VerboseLogging: 0
    ProgressMonitoring:
      enabled: yes
      heartbeatMs: 0
      sendBufferSize: 65536
    --ProgressMonitoring
    uploadFromMemory:
      numBytesToUpload: 200304
      uploadFromDataSource:
        initialGreeting: 220-FileZilla Server 1.1.0
220 Please visit https://filezilla-project.org/
        restartNext: 0
        modeZ: 0
        binaryMode: 1
        pbsz_protp:
          simpleCommand:
            sendCommand:
              sendingCommand: PROT P
            --sendCommand
            readCommandResponse:
              replyLineQP: 200 Protection level set to P
            --readCommandResponse
          --simpleCommand
        --pbsz_protp
        setupDataConnection:
          passive transfer mode
          setupPassiveDataSocket:
            sendCommand:
              sendingCommand: PASV
            --sendCommand
            readCommandResponse:
              replyLineQP: 227 Entering Passive Mode (xxx,175,208)
            --readCommandResponse
            dataConnect:
              hostname: (redacted)
              port: 45008
              socketOptions:
                SO_SNDBUF: 262144
                SO_RCVBUF: 4194304
                TCP_NODELAY: 0
                SO_KEEPALIVE: 1
              --socketOptions
              dataConnectSuccess: 1
            --dataConnect
          --setupPassiveDataSocket
        --setupDataConnection
        sendUploadCommand:
          sendCommand:
            sendingCommand: STOR FMT2021_air.csv
          --sendCommand
        --sendUploadCommand
        Reading intermediate response for upload...
        readCommandResponse:
          replyLineQP: 150 Starting data transfer.
        --readCommandResponse
        convertDataConnToSsl:
          ConvertToTls: Elapsed time: 0 millisec
        --convertDataConnToSsl
        sendUploadFileData:
          sendBufferSize: 65536
          Sending uncompressed...
          Error sending on socket (1)
          SocketError: WSAECONNABORTED An established connection was aborted by the software in your host machine.
          For more information see this Chilkat Blog post: http://www.cknotes.com/?p=91
          send_size: 16406
          Failed to send TLS message.
          Failed to send on socket from source.
          lastBytesSent: 373B544C533B544F554C4F5553453B42
          Failed to upload data.
          UploadData: Elapsed time: 0 millisec
        --sendUploadFileData
        Reading final response...
        readCommandResponse:
          replyLineQP: 425 Unable to build data connection: TLS session of data connection not res=
umed.
        --readCommandResponse
        FinalReply: Elapsed time: 0 millisec
      --uploadFromDataSource
    --uploadFromMemory
    Failed.
  --PutFileFromBinaryData
--ChilkatLog

I can try to recreate the issue locally. Do you want me to share any additional detail? You also can reach me directly using the email adresse attached to my account.

Regards,

[botg]

Looks like this is due to a bug in GnuTLS. I've filed https://gitlab.com/gnutls/gnutls/-/issues/1303

[Styx31]

Thank you!

[Styx31]

Looks like this is due to a bug in GnuTLS. I've filed https://gitlab.com/gnutls/gnutls/-/issues/1303

Hello Tim,

We tried using another .net library to deal with TLS error (https://github.com/robinrodricks/FluentFTP) expecting that the problem was due to our FTP client library, but we just discovered was the issue was still there, event with latest 1.3 version.

When coming back to this topic, I also discovered that a maintainer on the gnutls repository has replied to your issue: https://gitlab.com/gnutls/gnutls/-/issues/1303, so I decided to ping you here

I also discovered this issue which could be related?

(Also it seems our problem are not related at all with the original topic. Maybe this topic should be splitted?)