[Feature Request] support of the CCC command (client and se

[luckyluc78]

Hi everybody
I'd like to use filezilla and filezilla server with SSL/TLS (FTPES - FTP over explicit TLS/SSL) to send my password encrypted. My server is behind a firewall and I cannot change anything on it.

I need to switch FTP in clear text after the authentication in order be able to make transfers or dir. The firewall cannot open data connection if the control connection is encrypted.
The CCC (clear command channel) command allow to do that.

Do you intent to add this command (like ftp7 server on windows 2008)?

[botg]

Just use plain FTP. You do not gain anything by using FTP over TLS and then dropping the security as every attacker could just hijack the connection following the CCC, making it equally insecure as plain FTP. As such, I do not intend to ever implement support for CCC.

[luckyluc78]

I want to use TLS only to avoid to let anybody see my password in clear text!

[boco]

You would mask only the initial login by this method. But transfers use independent connections to the server, for every such connection your data is sent again. To be secure, TLS has to be enabled at all times, including the data connections (PROT P). Besides, you only need to configure your firewall properly to work with encrypted FTP.

[luckyluc78]

can you have a look at this link:
Home > Learn > Deploying Web Sites on IIS 7 > Publishing Content to Web Sites > FTP 7 for IIS 7 > Using FTP Over SSL

http://learn.iis.net/page.aspx/304/using-ftp-over-ssl/

I just wanted to have the same behavior for my filezilla server:

Select the Require only for credentials option for the control channel. Note: This setting requires that all user names and password are encrypted via SSL, but the client can choose whether to encrypt all other control channel activity.

[boco]

As botg said, that won't ever be supported as it doesn't offer any security. Either you're fully encrypted or not at all.

[libit]

Just use plain FTP. You do not gain anything by using FTP over TLS and then dropping the security as every attacker could just hijack the connection following the CCC, making it equally insecure as plain FTP. As such, I do not intend to ever implement support for CCC.

I'm always surprised at this kind of quick and final replies.

While it is true that an attacker could hijack the connection, still there can be perfectly valid reasons to use FTP over TLS with CCC: including:

• the attacker, even if he manages to sniff and steal the connection, at least cannot retrieve the user password so e.g. I might have an insecure FTP server with no confidential data, which I don't care at all if an attacker can see, but I do care to protect my password (which might be my corporate password) and that would be safe even with CCC (so NOT "equally insecure as plain FTP")
• the attacker, even if he manages to sniff and steal the connection, still cannot download or upload files because even after a CCC, only the command channel is in clear but data connections can still be kept TLS protected and requiring prior knowledge of the SSL master secret (which the attacker wouldn't have) so he couldn't do any file transfer or anything requiring a data channel (so NOT "equally insecure as plain FTP")
• an attacker that can just see traffic but not live or anyway that cannot hijack the connection, even with CCC, cannot retrieve the passwords and not steal transferred files (contrary to a plain FTP where both would be possible)
• there are cases where FTP over TLS without CCC (even if that would ofcourse be more secure) is not possible, e.g. because the server is behind a NATting firewall that could not see the IPs and ports communicated in the PASV command if the traffic is encrypted

[botg]

the attacker, even if he manages to sniff and steal the connection, at least cannot retrieve the user password so e.g. I might have an insecure FTP server with no confidential data, which I don't care at all if an attacker can see, but I do care to protect my password (which might be my corporate password) and that would be safe even with CCC (so NOT "equally insecure as plain FTP")

I give you that.

the attacker, even if he manages to sniff and steal the connection, still cannot download or upload files because even after a CCC, only the command channel is in clear but data connections can still be kept TLS protected and requiring prior knowledge of the SSL master secret (which the attacker wouldn't have) so he couldn't do any file transfer or anything requiring a data channel (so NOT "equally insecure as plain FTP")

First thing the attacker does with a stolen control connection is PROT C, after that the transfer connections are not protected anymore. Regardless, even without having to transfer files, an attacker can still do damage through renaming and deleting files, our creating a gazillion directories.

an attacker that can just see traffic but not live or anyway that cannot hijack the connection, even with CCC, cannot retrieve the passwords and not steal transferred files (contrary to a plain FTP where both would be possible)

Apart from stealing passwords, after CCC an active attacker can do everything the user's FTP could have done, including transferring arbitrary files.

there are cases where FTP over TLS without CCC (even if that would ofcourse be more secure) is not possible, e.g. because the server is behind a NATting firewall that could not see the IPs and ports communicated in the PASV command if the traffic is encrypted

Lazy or incompetent administrators should not host FTP servers behind a NAT.

[libit]

First thing the attacker does with a stolen control connection is PROT C, after that the transfer connections are not protected anymore. Regardless, even without having to transfer files, an attacker can still do damage through renaming and deleting files, our creating a gazillion directories.

Apart from stealing passwords, after CCC an active attacker can do everything the user's FTP could have done, including transferring arbitrary files.

Actually RFC4217 says that the server, after receiving a CCC, should "Not accept any more PBSZ or PROT commands. All subsequent data transfers must be protected with the current PROT settings.". An attacker that, after hijacking the connection, tries PROT C would just get a 500 error. In fact, FTPES with CCC wouldn't allow any cleartext data channel transfer so no file nor dir exchanges (if properly implemented, obviously). True, an attacker can still try to remove files or create gazillion of directories, same as in basic FTP, if not prevented with quota, permissions, etc. But FTPS with CCC, while less secure than FTPES without CCC, is still way way better than basic FTP, compatible with most current firewall ALGs (which is not the case for FTPES without CCC), and has good reasons for existing and be supported.

So I'd be happy if you will consider adding support both to CCC and mutual (x509) auth to filezilla one day

Cheers,
libit

[matej]

I second libit's opinion. I would rather be able to connect through a firewall using CCC, than not connect at all, or use plain-text for passwords and file content transfers.

I will greatly appreciate if CCC is implemented.