There is considerable confusion when using the term "secure FTP". There are two different types of
secure file transfer protocols available, SFTP and FTPS. They are both supported by edtFTPj/PRO.

Firstly, there is an enhancement to standard FTP (as defined in RFC 959),
which uses the same FTP commands (and protocol) over secure sockets, i.e. over SSL/TLS.
This is implemented by edtFTPj/PRO. This is variously known as FTPS, FTP-SSL, and FTP-over-SSL.
There are many FTP servers that support FTPS.

There is also another protocol, unfortunately known as SFTP, which also provides secure file access,
but which is not related to the standard FTP protocol. This is implemented using SSH (Secure SHell),
a suite of secure network connectivity tools (when used with SSH2 this is known as SFTP). The primary
purpose of SSH is to enable users to remotely log into a machine over a secure connection. The two
protocols are completely different and not related. For a comparison see the FTPS vs SFTP FAQ below.
Support for this protocol is also in edtFTPj/PRO.

As already noted, SFTP is built on SSH2, while FTPS is standard FTP over an SSL connection. FTPS has a
number of advantages over SFTP.

Security. Standard SSH provides a secure remote shell for the user, and includes a command
called SCP (secure copy) which is used to implement FTP-like features in SFTP. The problem arises when
you want to allow client SFTP access on a server but not SSH access. This is possible but very tricky (see
SSH: The Definitive Guide). So if
you are not very careful when you set up your servers, users on machines with the SFTP client installed
will be able to use an SSH client to log into the server and execute commands. This is not a problem with FTPS.

Flexibility. FTPS is a straight-forward extension to an existing FTP infrastructure. It is supported
by most commercial servers and many open source servers (e.g. wu-ftpd and proftpd), so enabling
FTPS on a server is usually just a matter of adding a few configuration options. There is no need to
run additional servers since FTPS servers invariably also support FTP. There is also no need to
open additional ports in firewalls since FTPS uses the same ports as FTP.

Certificates. SFTP uses keys rather than certificates. This means that it can't take advantage of the "chains of trust"
paradigm facilitated through Certificate Authorities. This paradigm makes it possible for two entities
to establish a trust relationship without directly exchanging security information, which is important
for some applications. FTPS uses certificates and therefore can take advantage of this paradigm. SFTP
clients must install keys on the server.

SSL is short for Secure Sockets Layer, and is a protocol designed and implemented by Netscape. Version
3.0 of SSL was used as the basis for the Transport Layer Security (TLS) standard, version 1.0 (defined in
RFC 2246, The TLS Protocol Version 1.0). The differences between SSL 3.0 and TLS 1.0 are not substantial,
but the two protocols do not interoperate. TLS does, however, support a mechanism to back down to SSL 3.0.
edtFTPj/PRO supports TLS 1.0. We generally use the term "SSL" interchangeably with "TLS", as SSL is more
commonly known.

This is generally because the FTP server has not correctly responded to
the standard SSL/TLS closure exchange sequence. This causes the client
to wait for a signal that never arrives. The client can be prevented
from waiting by passing DISABLE_CONTROL_WAIT_ON_ CLOSE (in SSLFTPClient.ConfigFlags)
into the SSLFTPClient constructor.

This is generally because the FTP server has not correctly responded to
the standard SSL/TLS closure exchange sequence. In this case, the server
waits for more data that never arrives, as it does not realize it has
entered the closure exchange sequence. The server can be prevented from
waiting by passing DISABLE_DATA_SSL_CLOSURE (in SSLFTPClient.ConfigFlags)
into the SSLFTPClient constructor.

This is generally because the FTP server has not correctly responded to
the standard SSL/TLS closure exchange sequence. In this case, the server
abruptly closes the connection without sending an acknowledgement to the
client. This error can be prevented by passing
DISABLE_SSL_CLOSURE (in SSLFTPClient.ConfigFlags) into the SSLFTPClient
constructor.