Support Ipswitch WS_FTP Server CCC Command

[kevanb]

Ipswitch WS_FTP Server 5.0 introduced a new command
"CCC" ("Clear Command Channel") which is issued
immediately after authentication to signal that the
command channel should no longer be encrypted. This
allows for secure authentication via explicit FTPS,
while also allowing firewall FTP application
gateways/proxies to correctly handle passive
connections (as they can now see the passive response
from the FTP server behind them). Currently, only
Ipswitch's WS_FTP Pro client supports this command.

[Alexander Schuch]

Taken from now deleted:
[ 1702382 ] Please add RFC 4217 CCC Command Support to FileZilla 3.0

"Per RFC 4217 Securing FTP with TLS section 12.3, please add support for the Clear Command Channel (CCC) command to the FileZilla 3.0 client."

[Ray Van Dolson]

This should have been added long ago. Many environments are using Layer 7
firewalls now that break TLS encrypted FTP transfers. CCC is one way around
this issue when changes to your firewall configuration are not an option.

Can someone bump this up the priority ladder since it's been open going on
three and a half years?

[Tim Kosse]

Rejected since CCC is a security risk.

What's the point of encrypting the logon sequence if the rest of the session is unencrypted? An attacker could just wait till after the CCC command and could then hijack your connection.

[kevanb]

RE: codesquid (2008-03-01, "Rejected since..."

Two reasons to add this feature:

1) Encrypting the username and password provides a method of secure authentication beyond the basic clear-text method provided by the FTP protocol and without the need for additional services such as Kerberos. However, there are two reasons why you may not want to encrypt the entire command channel and data channels: a) You want to take advantage of your firewall's FTP application gateway for proxied PASV sessions rather than lock down your FTP server to a range of persistently open ports through the firewall, and b) You don't want to pay the added overhead of encryption on a slow link or less powerful computing device.

2) It's part of the RFC for "Securing FTP with TLS" (RFC 4217).

Guess I'll have to stick to other FTP clients that implement the protocol per the RFC until FileZilla gets its act together. That's too bad as I really like FileZilla except for this one annoying limitation.

[Ray Van Dolson]

Replying to codesquid:

Rejected since CCC is a security risk.

What's the point of encrypting the logon sequence if the rest of the session is unencrypted? An attacker could just wait till after the CCC command and could then hijack your connection.

I would put forth that this should be left up to the user of the FTP client to decide whether or not a situation is appropriate for use of CCC. After all, you allow the use of unencrypted FTP completely when it is inherenty insecure. An administrator may be perfectly confident that all data transferred isn't critical and doesn't need to be encrypted but wants the login information to be encrypted.

Please reconsider adding this feature -- make it an option that must be explicitly activated by an administrator who needs it.

[Tim Kosse]

Won't ever get implemented. Read my previous comment why CCC makes no sense at all.

[Glauber Ribeiro]

Respectuflly, please reconsider implementing this.

In a perfect world, CCC wouldn't be required, but it's not as loarge a security risk as you think, because only the command channel is not encrypted. The data connection continues to be encrypted.

Lack of support for this feature is preventing Filezilla from being the best FTP client available. It's not an "Ipswitch feature", but a standard feature.

[Ray Van Dolson]

Recommend using CoreFTP if you need a solid FTP client with CCC support.

[Glauber Ribeiro]

I know! But i LIKE Filezilla. :-)

[Tim Kosse]

My decision is final. You simply need to upgrade to a proper server if your's fails to handle encryption properly.

[Ray Van Dolson]

This has more to do with firewalls than FTP servers. It's trivial to configure the firewalls protecting your local FTP servers to deal correctly with TLS, but we FTP site administrators typically don't have control over remote end users behind various corporate firewalls. The most common case is that these firewalls automatically open up ports based on the PORT command (which is obviously not visible in an encrypted TLS session).

In that regard, CCC really helps out. And, if we allow the FTP site administrator to be the judge of whether or not encrypting everything but RETR, PORT commands, etc, then it really is no more of a security risk than allowing that same administrator to decide if they want to allow plain-text unencrypted regular 'ol FTP (which FileZilla obviously supports).

Anyways, the developer's position here is not entirely rational, but it is his project to do with as he sees fit. Either fork FileZilla and implement yourself, or use another product if you need CCC.

[Glauber Ribeiro]

Replying to rayvd:

Anyways, the developer's position here is not entirely rational, but it is his project to do with as he sees fit. Either fork FileZilla and implement yourself, or use another product if you need CCC.

Agreed. Fortunately there are several other FTP clients available. Not worth fighting about.

[ftpguy]

Unfortunately, the developer's response is not at all surprising. FileZilla is a nice FTP client but it has lagged behind other products in the area of RFC support and compatibility for as long as I can remember. It seemed like an eternity before some of the NAT compatibility features (such as overriding the server's address in the PASV response with the external site address) that other clients had been providing for quite some time ever showed up in FileZilla. The refusal to support the CCC command as it is described in the RFC is yet another example of the same situation; developer opinion versus RFC support, usability, and compatibility.

[Tim Kosse]

Nowhere in the RFCs does it say that a client has to support CCC.

In case you don't know how the internet works, standards go like this: Whoever accepts commands or parses data needs to support the full standard. Whoever issues commands or merely sends data can use any subset of the standard he wants.

In other words, FileZilla is fully standards compliant even without CCC.

On the totally unrelated NAT issue: I'm inclined to just switch to the EPSV command. Standards compliant too.

[sun zubing]

please please reconsider this important feature.
I have to satuation that must use CCC.
1) my ftp server behind NAT, to have NAT automaticly map ports. NAT must phase PASV commands from ftp control connection.
2) i don't have so much security documents to protect(mostly movie shareing, i want to low CPU occupy). but i must have user accounts be protected.
3) let user deside whether or not protect data connection(and/or direction listing)

[Ray Van Dolson]

The author has a philosophical objection to CCC. Use CoreFTP instead.

[sun zubing]

if no CCC will be support. maybe can do "PROT C" first? which temporay clear data channel encryption. this will low server loads as well as good bandwidth usage.

[Alexander Schuch]

Replying to starmoon:

if no CCC will be support. maybe can do "PROT C" first? which temporay clear data channel encryption. this will low server loads as well as good bandwidth usage.

This RFE is solely about CCC. PROT is covered in #2161.

[Tim Kosse]

CCC will never be implemented.