Security in FTP is provided by employing the SSL/TLS protocol for channel encryption as defined in RFC 2228. The secured version of FTP is called FTPS.

The SFTP abbreviation is often mistakenly used to specify some kind of Secure FTP, by which people most often mean FTPS. Another (similar) mistake is that SFTP is thought to be some kind of FTP over SSL. In fact SFTP is an abbreviation of “SSH File Transfer Protocol”. This is not FTP over SSL and not FTP over SSH (which is also technically possible, but very rare).

Both FTPS and SFTP use a combination of an asymmetric algorithm (RSA, DSA), symmetric algorithm (DES/3DES, AES, Twofish etc.) and key-exchange algorithm. For authentication FTPS (or, to be more precise, the SSL/TLS protocol under FTP) uses X.509 certificates, while SFTP (the SSH protocol) uses SSH keys.

X.509 certificates include the public key and certain information about the certificate owner. This information lets the other side verify the integrity of the certificate itself and the authenticity of the certificate owner. Verification can be done both by computer and to some extent by a human. An X.509 certificate has an associated private key, which is usually stored separately from the certificate for security reasons.

An SSH key contains only a public key (the associated private key is stored separately). It doesn’t contain any information about the owner of the key. Neither does it contain information that lets one reliably validate integrity and authenticity. Some SSH software implementations use X.509 certificates for authentication, but in fact they don’t validate the whole certificate chain — only the public key is used (which makes such authentication incomplete and similar to SSH key authentication).


  • FTP: the old file transfer protocol (RFC959). Problematic with firewalls since it is using dynamic ports and the information about these ports gets exchanged at the application level.
  • FTPS: the old FTP protocol but support for TLS added. Even more problematic with firewalls since these can no longer look into the application level to find out which ports are used.
  • SFTP: something completely different, because it uses the SSH protocol to transfer files. No problems with firewalls.



  • Widely known and used.
  • Human-readable communication.
  • Provides services for server-to-server file transfer.
  • SSL/TLS has good authentication mechanisms (X.509 certificate features).
  • FTP and SSL/TLS support is built into many internet communication frameworks.


  • Doesn’t have a uniform directory listing format.
  • Requires a secondary DATA channel, which makes it hard to use behind the firewalls.
  • Doesn’t define a standard for file name character sets (encodings).
  • Not all FTP servers support SSL/TLS.
  • Doesn’t have a standard way to get and change file and directory attributes.



  • Has a standards background which strictly defines most (if not all) aspects of operations.
  • Has only one connection (no need for a DATA connection).
  • The connection is always secured.
  • The directory listing is uniform and machine-readable.
  • The protocol includes operations for permission and attribute manipulation, file locking, and more functionality.


  • The communication is binary and can’t be logged “as is” for human reading.
  • SSH keys are harder to manage and validate.
  • The standards define certain parts as optional or recommended, which leads to certain compatibility problems between different software titles from different vendors.
  • No server-to-server copy and recursive directory removal operations.
  • No built-in SSH/SFTP support in VCL and the .NET Framework.

What to Choose

In general, SFTP is technologically superior to FTPS. Of course, it’s a good idea to implement support for both protocols, but they are different in concepts, in supported commands, and in many other things.

It’s a good idea to use FTPS when you have a server that needs to be accessed from personal devices (smartphones, tablets, etc.) or from some specific operating systems that have FTP support but don’t have SSH / SFTP clients. If you are building a custom security solution, SFTP is probably the better option.

Developer Tools

In .NET you have built-in support for FTPS in the .NET Framework (see the FtpWebRequest class). However, the functionality of this class is severely limited, especially in the aspect of control over SSL/TLS. The .NET Framework doesn’t include support for SSH or SFTP.


Can I use FtpWebRequest class for SFTP transfers?

Answer: NO.

See FtpWebRequest documentation:

Implements a File Transfer Protocol (FTP) client.

SFTP is not FTP.


Last modified: August 22, 2019



Write a Reply or Comment