TLS 1.3 Session Ticket reused after expiry

[vsteiner]

I've observed an issue where file uploads from FileZilla result in 0-byte files on the server (when using TLS 1.3, ProFTPD). The problem occurs when uploading multiple files, and after several hours, at a transition point between two consecutive file transfers.

I'm able to reproduce the issue using the latest stable (3.68.1) and preview (3.69.0-rc1) on Windows 10.

Here are the exact mechanics:

• TLS 1.3 uses session tickets with a specific lifetime (maximum age), set by the server.
• FileZilla uses the same TLS context between the control and the data connection(s).
• Since the control connection is first, FileZilla reuses the control connection's TLS context for all data connections that are established during the life of the control connection.
• That means that at the beginning of each file transfer, there is a chance that the session ticket has expired.
• FileZilla does not seem to verify that the session ticket is still valid (i.e. not expired).
• So, at some point, FileZilla attempts to open a data connection with an expired session ticket.
• ProFTPD rejects the connection, but writes a 0-byte file.
• FileZilla prints: "Error: TLS session resumption on data connection failed. Closing control connection to start over."
• Closing the data and control connection is a total reset, resulting in a clean sheet, and new TLS context.
• Assuming default settings, FileZilla will then ask what to do with the 0-byte file that now exists on the server.

In my view, both components could behave better (client and server).

In essence, I'm filing this bug because FileZilla appears to ignore the TLS 1.3 session lifetime hints. This is against RFC 8446.

Clients MUST NOT attempt to use tickets which have ages greater than
the "ticket_lifetime" value which was provided with the ticket.

(​https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.11.1)

The remedy could be, before establishing a new data connection, to check if the session ticket's age is below its lifetime. If yes, continue with the data connection. Otherwise, close the control connection and start a new control connection, without attempting to reuse the session ticket.

For completeness: ProFTPD uses a value of 15840s (4h 24min) by default. It can be modified using the TLSSessionCache directive.

[Tim Kosse]

Doesn't appear GnuTLS offers a way to read the ticket lifetime.

Did you verify yet that the client actually attempts to use the expired ticket on the wire, as opposed to a regular non-resumption handshake?

FileZilla Server addresses the ticket lifetime issue by always issuing a new ticket right before sending the response to the PASV/EPSV/PORT/EPRT commands.