The Best (S)FTP(ES) Client!

I’ve been using Van Dyke Software’s SecureFX for a long time for FTP transfers. It’s a decent software, but I’ve always found its user interface a bit clumsy (floating windows inside a master window..). Recently the need for secure connections has become increasingly important, and SecureFX doesn’t support Explicit FTPS, or “FTPES”. The difference of the “explicit” and “implicit” FTPS was well described on a page found on Enterprise Distributed Technologies site:

Before the FTPS Internet Draft was published a somewhat abortive attempt at offering a secure version of FTP was made. This is now referred to as implicit FTPS. It is a very simplistic technique which involves using standard secure TLS sockets in place of plain sockets at all points. Since standard TLS sockets require an exchange of security data immediately upon connection, it is not possible to offer standard FTP and implicit FTPS on the same port. For this reason another port needs to be opened – usually port 990.

Implicit FTPS is in the process of being phased out in favour of FTPS as described in the Internet Draft. This newer variant of FTPS is now referred to as explicit FTPS. It has a some substantial advantages over implicit FTPS:

  1. It is a standard extension of FTP and is therefore supported by most FTP servers.
  2. It uses standard FTP ports meaning that there is no need to open addition ports in firewalls when upgrading from FTP to FTPS.
  3. It is more flexible in that it allows security to be turned off and on in a single session.
  4. It is compatible with the RFC2228 standard.

I decided to review some other FTP clients at hand. The excellent Filezilla would be perfect, except it doesn’t yet support RSA-key based SFTP authentication making it unsuitable for accessing the roots of remote systems. Its Explorer integration was also imperfect in that attempting to drag a file from a connected ftp site to the desktop (outside of the program window) resulted in an error.

I tried FTPRush, but gave up on it after a while — could not get FTPES working properly. It probably would work, but the reason for why it did not work was not obvious.

WinSCP offers SCP/SFTP (both key and password based), but it doesn’t support FTPS, explicit or implicit.

CuteFTP Pro supports all three connectivity types, but while existing key types can be defined, it’s finicky on the format of the key (I could not get an externally generated key working). Additionally it only supports *one* RSA key globally for all profiles AND it doesn’t allow dragging-and-dropping items from a connected remote site to the local desktop or other explorer location (i.e. outside of the application window). I crossed it out.

I looked at the screen shots of CoreFTP.. and they were enough to convince me I would not want to try it.

Finally, I gave the latest version of the ‘ol WS_FTP Professional by Ipswich systems a try, and found all three connectivity types easily configured. It also wants to generate RSA keys itself, but at least each profile can have its own key and drag-and-drop out of the application window works. Seems it’s the winner, for now (Filezilla holds a lot of promise — once they implement RSA key authentication it may well come out at the top.. especially since it’s free software).

Two other slightly different kind of FTP clients worth mentioning here are WebDrive and SFTP Drive which map Windows drive letter(s) to remote FTP site(s). Both work very well; WebDrive is a bit more configurable (and a bit more expensive) of the two. Both support SFTP (password or RSA key pair authentication), WebDrive additionally supports WebDAV, Amazon S3, and insecure FTP. Neither program offers support for FTP(E)S. (Update: read the post comments regarding FTPS support in WebDrive.)

10 thoughts on “The Best (S)FTP(ES) Client!”

  1. Thanks for the review on the various secure clients; there are quite a few very nice ones out on the market today.

    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.


  2. Michael, thanks for the clarification. I had missed the “Encryption Method” options in WebDrive configuration when “FTP” Server Type is selected (I had been looking for “FTPS” Server Type.)

  3. Another Windows utility to map an ftp site to a drive letter is NetDrive (which is “free for home use”). However, it has significantly fewer features than SFTP Drive or especially WebDrive.

  4. Ville,

    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

  5. Maureen,

    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 (Official Release – July 24, 2008)
    i Session 00006 established for session Inertia (FTPES)
    i Control connection successfully established.
    < 220-FTP server ready.
    < 220-<<
    USER limited
    < 230-User limited has group access to: nogroup
    < 211-Extensions supported:
    < EPRT
    < IDLE
    < MDTM
    < SIZE
    < MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
    < MLSD
    < TVFS
    < ESTP
    < PASV
    < EPSV
    < SPSV
    < ESTA
    < AUTH TLS
    < PBSZ
    < PROT
    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.

  6. Ville,

    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

  7. The connection is hung, but the application is not. I assume this is because there’s nowhere to go at that point. The client has authenticated successfully, command channel works (pure-ftpd supports encrypted command channel) but no data can be transferred because SecureFX wants to transfer it encrypted and pure-ftpd doesn’t support it. Thus I can select “disconnect” and SecureFX closes the connection gracefully. I believe “use encrypted data channel” option would fix this problem.

    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).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.