1. What type of secure FTP does edtFTPj/PRO support?

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.

2. SFTP vs FTPS - which is better?

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.

3. What is the difference between SSL and TLS?

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.

4. Does IIS support FTPS?

No, Microsoft's Internet Information Server (IIS) does not currently support SFTP or FTPS, but our completely free FTP server, edtFTPD, supports FTPS.

5. The SSLFTPClient freezes when a single file transfer is complete.

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.

6. After a file transfer has completed, the file lock on the transferred file (on the server) is never released.

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.

7. The SSLFTPClient throws a SSLPrematureCloseException.

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.

8. Can edtFTPj/PRO be used with Perl?

Yes, edtFTPj/PRO can be easily called from Perl by means of the INLINE::JAVA module.

9. What FTPS servers does edtFTPj/PRO support?

See our list of tested servers.

10. Can edtFTPj/PRO be used for standard FTP, without using FTPS?

edtFTPj/PRO operates as a normal FTP client until you call the auth() method. See the examples for sample code to get started.

11. The SSHFTPClient throws a SSHFTPException (Could not authenticate SSH client: FAILED)

If you are using password authentication and authentication fails, make sure that "PasswordAuthentication yes" is set in sshd_config.