TLS session resumption problem

[Michael Roy]

Hi,

Using Filezilla 3.53.1 and sessions cache limit with the new TLS session resumption seems to cause problems.
(In order for a session to be restored, a cache of previous sessions needs to be maintained. Essentially, these cached sessions are the stored sessions that can be resumed.) There is a limit of 255 sessions in the cache on our server, which means that not all past sessions are capable of being resumed. I think client should definitely not generate an error because a server does not have a previous session recorded in its cache.

[Tim Kosse]

The client should definitely generate an error, as otherwise we'd be wide open to data connection stealing attacks.

As for your server, it only needs to cache a single session with each active control connection, which is the session of the control connection itself. Do not persist sessions over the live time of the corresponding control connection, it would result in vulnerabilities to data connection stealing and swapping attacks.

There are three important security checks to prevent data connection stealing/swapping attacks:

• The control connection must never be a resumed session
• The data connection must be resumed
• The session of control and data connection must be the same

Rumpus is using OpenSSL from what I can see. The easiest way to implement the first check is to use a fresh SSL_CTX for every control connection.

The third check is very important as otherwise an attacker could inject a session into the SSL_CTX, see https://filezilla-project.org/misc/ftps_connection_stealing_exploit.cpp