Thanks for your assistance; I’m looking forward to the updated version in the future (which is probably at least a few monts away since 6.1 was just released).

Thanks for providing the details about the behavior you’re seeing in SecureFX 6.0.

You mentioned that after the login succeeds, nothing happens. Is SecureFX hung at this point?

I will enter feature requests to add the options “Use unencrypted command channel after SSL authentication” and “Use unencrypted data channel”. It sounds like the latter option is the one you need to connect to your server. These will be considered for a future version of SecureFX. If you would like to be notified by e-mail if these get implemented, please send a note to me at Maureen.Jett@vandyke.com.

Thanks for your response. My statement that SecureFX “doesn’t support FTPES” was not totally accurate. It doesn’t support FTPES for the purposes I wanted to use it for (or at least I could not get it to work as described below), but it does of course support FTPES when certain conditions are met. Here’s the scoop:

Last time I tried the 6.x version (while writing this post), its explicit FTP/SSL support seemed to disallow encrypting just the login (and the command channel) while keeping the data channel open.

I reinstalled the latest trial version of SecureFX (I usually use it at client locations) to look at the issue again, and this is what I found: When attempting to connect to a pure-ftpd server via FTPES where the login would be secured, but the data channel open, the login itself succeeds but the subsequent operations fail:

–
i SecureFX version 6.0.3.311 (Official Release – July 24, 2008)
i Session 00006 established for session Inertia (FTPES)
i Control connection successfully established.
< 220-FTP server ready.
< 220-<<
< 220-THIS IS INERTIA FTP SERVICE!
>
AUTH TLS
USER limited
PASS
< 230-User limited has group access to: nogroup
SYST
FEAT
< 211-Extensions supported:
< EPRT
< IDLE
< MDTM
< SIZE
< REST STREAM
< MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
< MLSD
< TVFS
< ESTP
< PASV
< EPSV
< SPSV
< ESTA
< AUTH TLS
< PBSZ
< PROT
PWD
TYPE A
PBSZ 0
PROT P
< 534 Fallback to [C]
–

After that, nothing happens. Pure-ftpd – a popular open-source FTP server for UNIX environments – does not support encrypted data channel via FTPS. I took another pass at SecureFX FTPS settings, and could not find an option to keep the data channel clear. Since I prefer to use FTPES for pre-encrypted (and usually rather large) file system dump transfers, and since I use pure-ftpd in most of the customer applications, this obviously became a problem. Obviously, when this method of data transfer is used, users have to make sure that no sensitive data is being transferred over the insecure connection but often, like in my example, the content is pre-encrypted and transfer layer security would be redundant and would introduce overhead to the transfer speed (or to the bandwidth requirement).

For comparison’s sake I also installed Ispwitch WS_FTP and opened its SSL configuration dialog. It includes the options “Use unencrypted command channel after SSL authentication” and “Use unencrypted data channel” options, of which the latter needs to be used with pure-ftpd server. It would be great if VanDyke could add these options to SecureFX as well since its integration with SecureCRT comes very handy in many applications.

I’m the product manager for SecureFX and I was surprised by your post. Since version 4.0, SecureFX has supported FTP/SSL (implicit) and FTP/SSL (explicit). If these don’t do what you need, I would be interested in finding out more about your situation to determine if there’s a problem in SecureFX or if a feature request should be
entered in our development database.

I will monitor this thread or feel free to contact me directly at Maureen.Jett@vandyke.com.

One clarification I would like to make would be WebDrive. WebDrive does support both Implicit and Explicit FTPS (through SSL v3 and TLS). From an SFTP/SSH perspective, RSA and DSS keys are supported in lengths up to 4K. Versions 3 and 4 of the SFTP protocol are currently supported and we hope to have support for v5 and 6 later this year.

Thanks!