Explicit TLS fails with Proftpd 1.3.7b version. Direct Curl command execution works fine for one of our customer, but the same fails while running via cpp code.
/var/log/proftpd # curl -v --ssl --verbose --ssl --cert /cs/.crt.pem --cert-type PEM --key .key.pem --key-type PEM ftp://:@:2121//app/prod/data/input/ --pass *********--libcurl /cs/dev/libcur24052023.log
The CURLOPT_URL generated through the cpp code is same as the direct curl command used in the above step. The following are the proftpd log :
Code execution proftpd.log (Failed case): 2023-05-29 03:27:05,745 mod_tls/2.9[1973619]: SSL/TLS-P requested, starting TLS handshake 2023-05-29 03:27:05,746 mod_tls/2.9[1973619]: unable to accept TLS connection: system call error: [0] Success 2023-05-29 03:27:05,746 mod_tls/2.9[1973619]: SSL/TLS-P negotiation failed on control channel
Direct CURL command proftpd.log (Success Case): 2023-05-29 03:30:09,801 mod_tls/2.9[1974094]: SSL/TLS-P requested, starting TLS handshake 2023-05-29 03:30:09,814 mod_tls/2.9[1974094]: client supports secure renegotiations 2023-05-29 03:30:09,814 mod_tls/2.9[1974094]: Client: DC = etit, DC = CS-GROUP, OU = Services, CN = s5 (s5) 2023-05-29 03:30:09,814 mod_tls/2.9[1974094]: TLSv1.3 connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits) 2023-05-29 03:30:09,814 mod_tls/2.9[1974094]: matched client cert 1.3.18.0.2.18 extension '1#0!~B^*****~B^G5' to user 's5' 2023-05-29 03:30:09,814 mod_tls/2.9[1974094]: TLS/X509 TLSUserName '1.3.18.0.2.18' check successful for user 's****5' 2023-05-29 03:30:09,817 mod_tls/2.9[1974094]: Protection set to Private 2023-05-29 03:30:09,831 mod_tls/2.9[1974094]: TLSv1.3 data connection accepted, using cipher TLS_AES_256_GCM_SHA384 (256 bits)
The same cpp code works fine in older version of proFtpd 1.2.* deployed in a different linux server.
Can this be a server firewall issue ? Could someone please throw some light on this issue ?
Regards, Karthika
Tried setting all the curl properties as per direct curl command through cpp code. Even with the same set of properties set, handshake fails. The same works fine with user ID password authentication.
