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?)

[smartftp]

We are still seeing this issue with the latest version (1.7.0) of FileZilla server, respectively GnuTLS 3.8.0.

It's a TLS 1.3 interoperability issue between GnuTLS and Window's Schannel. The issue can be reproduced with any client which uses Schannel. For example, on Windows with curl (it uses Schannel by default):

Code: Select all

curl -v --insecure --ssl-reqd ftp://user:pass@localhost/Apps/uwd.exe -o out.exe

Code: Select all

* Connected to localhost (127.0.0.1) port 21 (#0)
< 220-FileZilla Server 1.7.0
< 220 Please visit https://filezilla-project.org/
> AUTH SSL
< 234 Using authentication type TLS.
* schannel: disabled automatic use of client certificate
> USER user
< 331 Please, specify the password.
> PASS pass
< 230 Login successful.
> PBSZ 0
< 200 PBSZ=0
> PROT P
< 200 Protection level set to P
> PWD
< 257 "/" is current directory.
* Entry path is '/'
> CWD Apps
< 250 CWD command successful
> EPSV
* Connect data stream passively
* ftp_perform ends with SECONDARY: 0
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< 229 Entering Extended Passive Mode (|||64371|)
* Connecting to 127.0.0.1 (127.0.0.1) port 64371
*   Trying 127.0.0.1:64371...
* Connected to localhost (127.0.0.1) port 21 (#0)
> TYPE I
< 200 Type set to I
> SIZE uwd.exe
< 213 624640
> RETR uwd.exe
< 425 Unable to build data connection: TLS session of data connection not resumed.
* RETR response: 425
* Remembering we are in dir "Apps/"
* schannel: shutting down SSL/TLS connection with localhost port 21
  0  610k    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host localhost left intact
curl: (19) RETR response: 425

I was hoping the patch in this GnuTLS issue (https://gitlab.com/gnutls/gnutls/-/issues/1303) would address the issue, but it isn't the case. Note that there are no TLS 1.3 interoperability issues between Schannel any other TLS 1.3 stack we have tested (OpenSSL/LibreSSL, wolfSSL, etc) which makes me believe that the culprit is in GnuTLS.

It affects every FTP client which uses Schannel and there are quite a few:
curl (bundled version on Windows uses Schannel by default)
SmartFTP
any component which uses .NET and Schannel
Rebex FTPS client
FluentFTP

[botg]

It looks like schannel still does not compute obfuscated ticket age correctly, see viewtopic.php?p=179877#p179877

You can easily confirm this yourself by compiling GnuTLS 3.8 with -O0 -g, rebuild lfz and FZS and set a breakpoint in pre_shared_key.c:640
You'll see that the obfuscated ticket age received from the schannel client is always wrong.

Since you are an actual schannel user, maybe you have more luck than me getting support from Microsoft.

[botg]

Note that there are no TLS 1.3 interoperability issues between Schannel any other TLS 1.3 stack we have tested (OpenSSL/LibreSSL, wolfSSL, etc) which makes me believe that the culprit is in GnuTLS.

Have you verified that the third-party servers using the other TLS libraries actually are secure, ie. require session resumption on the data connection? Not requiring TLS session resumptions leaves the server wide open to data connection stealing attacks.

[smartftp]

Thank you for your insight. You are correct, Schannel does not support session resumption with TLS 1.3:
https://b.poc.fun/decrypting-schannel-t ... resumption
https://github.com/microsoft/msquic/blo ... el.c#L1598

Now I'm wondering how those other FTP server products ensure security with data connections.

[botg]

Schannel does not support session resumption with TLS 1.3:

From what I'm seeing, schannel if used as client _almost_ supports session resumption with TLS 1.3, if not for one small issue: Wrong calculation of obfuscased_ticket_lifetime in the psk client hello extension. If I for a test disable ticket expiration check in GnuTLS as used in FZS, resumption actually works just fine with the curl command you mentioned. I suspect what schannel is doing wrong most likely boils down to something simple as wrong endianess, using signed vs. unsigned type, or a mixup between seconds and milliseconds. Should be very easy to fix, but it is Microsoft we're talking about here after all...

Now I'm wondering how those other FTP server products ensure security with data connections.

Most likely answer: They don't, particularly not in their default configuration.