0 votes
ago by (180 points)

Hello,

We are currently evaluating the Rebex File Server library.

We implemented a sample server using the Rebex File Server library and observed what appears to be a memory leak during FTPS testing.

FTPS Server Environment

  • OS: Windows Server 2022
  • .NET 6

FTPS Server Configuration

server.Settings.AllowedAuthenticationMethods = AuthenticationMethods.Password;
server.Settings.AcceptWindowsPaths = true;
server.Settings.MaxIdleDuration = 60 * 2;
server.Settings.MaxPendingConnectionsQueueLength = 256;
server.Settings.FtpRequireDataSessionResumption = false;
server.Bind(21, FileServerProtocol.Ftp); // Bound using FileServerProtocol.Ftp only
server.Settings.FtpControlProtection = FtpProtection.Required;
server.Settings.FtpDataProtection = FtpProtection.Required;
server.Settings.TlsParameters.Version = TlsVersion.TLS10 | TlsVersion.TLS11 | TlsVersion.TLS12 | TlsVersion.TLS13;
- A PFX certificate (private certificate) is configured.

FTPS Client Information

  • Apache FTPSClient v3.10.0
  • Operation flow: connect > login > file upload > logout > disconnect
  • Upload file size: 64 KB

Test Conditions

  • Number of concurrent test threads: 100
  • Total number of test iterations: 180,000
  • Number of iterations per thread: 1,800

Test Results

  • Initial memory usage: 52 MB
  • Memory usage after the test: 451 MB

Questions

We found a previous Q&A post regarding the TlsOptions.DoNotCacheSessions option.

After applying this option, the memory increase no longer occurs. However, since the post is quite old, we are concerned whether this is still the appropriate approach.

Reference post:
https://forum.rebex.net/2800/tlssocket-negotiate-tlsexception-session-already-session?show=2801#a2801

Would using this option alone be sufficient, or are there any additional recommendations or considerations we should be aware of?

Best Regards.

Applies to: Rebex FTP/SSL, File Server

1 Answer

0 votes
ago by (78.7k points)

Hello,

This is unfortunately behavior by design of FTP over TLS itself. The FTP protocol requires a new TCP connection to be established for each data transfer (and directory listing). TLS session resumption is common practice when protecting data connections with TLS. The main reason is security - it binds the data connection to the FTP client that initiated the transfer. Without TLS session resumption, the server does not know whether the newly established data connection is legitimate (i.e. whether it was really established by the original FTP client).

However, it seems that the TLS session cache can be flooded unreasonably, and we will look into this issue.


TlsOptions.DoNotCacheSessions disables the use of TLS sessions altogether (no caching on the server). Please note that if it is disabled, data connections are rejected unless you set server.Settings.FtpRequireDataSessionResumption = false (it is required by default).

It seems reasonable that if FtpRequireDataSessionResumption is disabled, there is no need to cache TLS sessions on the server either. We will address this as well.

Also please note that TLS session resumption works differently in TLS 1.3. Do you see a different memory profile when using TLS 1.3?

...