CCC - Clear Command Channel

Would it be possible to implement the CCC command (RFC2228) to remove encryption from the command channel of an encrypted FTP connection after authentication?

There are a few servers, unfortunately, that require this.

Thank you,

glauber

Thanks for your post. This request has been added to tracker.

Thank you for considering this. I've been keeping a certain commercial product around just because of lack of support for this feature in open source products. CCC requirement is, unfortunately, rather common for FTP/SSL servers that interact with firewalls (because firewalls need to be able to read and respond to "PORT" commands).

If i may make a further suggestion, the way i see this could work, is a checkbox or advanced option to "turn off command channel encryption after authentication". There should never be a need to turn off encryption before authentication IMHO, and there should never be a need to turn off encryption on the data channel.

Thanks again,

glauber

Did this get solved???
Does WinSCP support CCC?

Thanks

banto wrote:

Did this get solved???
Does WinSCP support CCC?

Thanks

Not yet.

g

glauber wrote:

banto wrote:

Did this get solved???
Does WinSCP support CCC?

Thanks

Not yet.

g

I found another program that supports CCC, everything is working, but I don't want to use that program. Btw, Filezilla does not support CCC either, they said there are to many security issues, like a hacker could overtake a session.

Any thoughts about this?

banto wrote:

I found another program that supports CCC, everything is working, but I don't want to use that program. Btw, Filezilla does not support CCC either, they said there are to many security issues, like a hacker could overtake a session.

Any thoughts about this?

Thoughts?

(1) In a perfect world, we wouldn't need CCC, but this is not a perfect world.

(2) IMHO, that danger is overstated. Certainly the danger is less than with plain unencrypted FTP (which Filezilla is happy to support).

(3) The developer of Filezilla has very strong feelings about this and is not likely to change his mind. Filezilla is his app and he has the right to do what he wants with it. It's an excellent app if you don't need this feature.

Any chance this has been added to WinSCP since the last post?

jpadgett wrote:

Any chance this has been added to WinSCP since the last post?

Was not.

still not, I assume?

Any chance this feature will be implemented? I would greatly appreciate being able to pass through application-aware firewalls.
Thanks.

matej sk wrote:

Any chance this feature will be implemented? I would greatly appreciate being able to pass through application-aware firewalls.
Thanks.

I have raised priority of this request.

Has this feature been implemented?

rradnay wrote:

Has this feature been implemented?

Not yet. What is your use case?

martin wrote:

rradnay wrote:

Has this feature been implemented?

Not yet. What is your use case?

I was using WinSCP client with FTPS passive mode and connected to Windows FTP server, it was successfully authenticated using explicit TLS and data transfer established. These were all accomplished successfully over the same network without any firewall.

However, I tried with the same WinSCP client w/ FTPS passive mode over Internet, and attempted to make connection to the same Windows FTP Server (using same public IP address internally and externally), TCP port 21 and 20 were allowed from ASA firewall. It successfully authenticated username and password over explicit TLS but then failed on data transfer. I read from someone mentioned and believed that was because firewalls or server could not read and respond to "PORT" or "PASV" commands due to encryption. I also read that CCC may be able to address this issue. Thanks!

netvigators wrote:

I read from someone mentioned and believed that was because firewalls or server could not read and respond to "PORT" or "PASV" commands due to encryption. I also read that CCC may be able to address this issue. Thanks!

CCC does not really "address this issue". It turns off the encryption. What indeed may solve your problem (but it might not, if the firewall gets confused by the previous encrypted part of the session). But it is not secure.