According to RFC 4217, the protection level of the FTP data channel can be changed during a TLS-secured session using the PROT command.
PROT C is intended to switch the data connection back to clear (unencrypted) mode while the control connection remains protected by TLS.
In LightFTP this downgrade seems to be ignored. After establishing a TLS session using AUTH TLS and successfully enabling protected data transfers with PROT P, sending PROT C receives a 200 Command okay response, but subsequent passive data connections still behave as if TLS is required.
ssize_t ftpPROT (pftp_context context, const char *params)
{
if ( context->access == FTP_ACCESS_NOT_LOGGED_IN )
return sendstring(context, error530);
if ( params == NULL )
return sendstring(context, error501);
if ( context->tls_session == NULL )
return sendstring(context, error503);
switch (*params)
{
case 'C':
context->data_protection_level = 0;
return sendstring(context, success200);
break;
case 'P':
context->data_protection_level = 100;
return sendstring(context, success200);
break;
default:
return sendstring(context, error504);
}
}
https://github.com/hfiref0x/LightFTP/blame/94dff49252e7afd34fdb1f7f295a79cf3cb928f9/src/ftpserv.c#L1551
When processing PROT C LightFTP sets context->data_protection_level = 0; and confirms the change with a 200-type message.
However, this value is never referenced anywhere else in the codebase. In particular, when establishing a data connection, the server only checks whether the control channel TLS session (context->tls_session) is active. As a result, the data channel TLS behavior is implicitly tied to the control channel state rather than the configured protection level.
According to RFC 4217, the protection level of the FTP data channel can be changed during a TLS-secured session using the
PROTcommand.PROT Cis intended to switch the data connection back to clear (unencrypted) mode while the control connection remains protected by TLS.In LightFTP this downgrade seems to be ignored. After establishing a TLS session using AUTH TLS and successfully enabling protected data transfers with
PROT P, sendingPROT Creceives a 200 Command okay response, but subsequent passive data connections still behave as if TLS is required.https://github.com/hfiref0x/LightFTP/blame/94dff49252e7afd34fdb1f7f295a79cf3cb928f9/src/ftpserv.c#L1551
When processing
PROT CLightFTP setscontext->data_protection_level = 0;and confirms the change with a200-type message.However, this value is never referenced anywhere else in the codebase. In particular, when establishing a data connection, the server only checks whether the control channel TLS session (
context->tls_session) is active. As a result, the data channel TLS behavior is implicitly tied to the control channel state rather than the configured protection level.