TLS Session Resumption Issue with FileZilla Server 1.8.1 and Micrium FTP Client

[ldietrich]

Hello,

We're working with Micrium FTP and mbedtls as crypto stack,
I'm experiencing an issue where the FTP client cannot upload a file to FileZille Server 1.8.1. Wireshark and FileZilla logs files are attached.

FileZilla logs :

Code: Select all

<1/29/2024 1:16:37 PM> FTP Session 28 172.23.19.119 ftp_test [Error] TLS session of data connection not resumed.
<1/29/2024 1:16:37 PM> FTP Session 28 172.23.19.119 ftp_test [Response] 425 Unable to build data connection: TLS session of data connection not resumed.

Our FTP client uses TLS1.2 and doesn't support session tickets, it uses session ID for TLS session resumption exclusively .
Wireshark logs show that FileZilla server immediately closes the connection after the handshake for "data" connections, without any TLS (encrypted) alert.
It seems like the filezilla server is unable to resume the session based on the session ID ?
However Tim Kosse (botg) states that both session ID and tickets are supported by FileZilla: viewtopic.php?f=6&t=55242&p=182369&hili ... ts#p182369

As a comparison, when using our FTP client with vsftpd server, the session is properly resumed and everything works as expected.
I didn't test FileZilla server with another client which does not support session tickets for comparison.

Do you have any idea of what is happening with FileZilla server. Thank your for your help.

EDIT: Filtered out useless packets in wireshark logs

[botg]

Faulty client. It uses TLS 1.2, and when establishing the data connection to the peer IP, it fails to copy over the SNI from the control connection, thus making resumption unavailable.

When resuming sessions, the SNI of the resumed session must match the SNI of the resumed from session. If there's a mismatch, resumption must fail. See RFC 6066 section 3. See also RFC 8446 section 4.6.1 for ever so subtly different semantics in TLS 1.3. (MUST NOT vs. SHOULD NOT)

[botg]

Also, I don't think IP addresses are valid in a SNI of type "host name" to begin with, that's a different issue.

Edit: Indeed they aren't. The RFC is explicit on that.

[ldietrich]

I fixed the client: simply adding the SNI for data connections, as you suggested, solves the resumption issue to FileZilla server.
I have nothing to add to your accurate explanations.

Thank you for your quick help