Solution “Client did not reuse SSL session from control channel, rejecting data connection”

I once ran ProFTPd with TLS and users connected successfully, but one client was trying to transfer files via cURL and got the error:

curl --upload-file "test.txt" --ssl-reqd --ftp-create-dirs ftp://ixnfo.com:21/test/ --user test@ixnfo.com:password --insecure

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100     5    0     0  100     5      0     40 --:--:-- --:--:-- --:--:--    40
curl: (18) server did not report OK, got 425

In the ProFTPd logs I saw:

SSL/TLS-P requested, starting TLS handshake
client supports secure renegotiations
TLSv1.3 connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits)
Protection set to Private
starting TLS negotiation on data connection
client reused SSL session for data connection
Client did not reuse SSL session from control channel, rejecting data connection (see the NoSessionReuseRequired TLSOptions parameter)
unable to open data connection: TLS negotiation failed

Then I tried connecting from Windows and MacOS, and noticed that they were using TLS 1.2, and cURL was connecting with TLS 1.3.

To solve the problem, I tried to add an option in the curl command:

--tls-max 1.2

After that, the error disappeared.

This problem can also be solved by specifying NoSessionReuseRequired in the ProFTPd configuration:

nano /etc/proftpd/tls.conf
    <IfModule mod_tls.c>
      ...
      TLSOptions NoSessionReuseRequired
      ...
    </IfModule>

Here’s what I found about it in the official ProFTPd documentation:

As of ProFTPD 1.3.3rc1, mod_tls only accepts SSL/TLS data connections that reuse the SSL session of the control connection, as a security measure. Unfortunately, there are some clients (e.g. curl) which do not reuse SSL sessions.

An example of logs with the NoSessionReuseRequired option enabled upon successful file transfer using cURL:

SSL/TLS-P requested, starting TLS handshake
client supports secure renegotiations
TLSv1.3 connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits)
Protection set to Private
starting TLS negotiation on data connection
TLSv1.3 data connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits)

See also my articles:
Configuring FTPS in ProFTPd
How to compile cURL on Ubuntu

Leave a comment

Leave a Reply