Difference Between FTPS and SFTP
Recently we were in the process of setting up remote file transfer capabilities for some applications, and we wanted to be as simple and secure as possible.
With that in mind, which is better, FTPS or SFTP?
They are two completely different protocols. FTPS is FTP with SSL for security. It uses a control channel and opens new connections for the data transfer. As it uses SSL, it requires a certificate.
SFTP (SSH File Transfer Protocol/Secure File Transfer Protocol) was designed as an extension of SSH to provide file transfer capability, so it usually uses only the SSH port for both data and control. In most SSH server installations you will have SFTP support, but FTPS would need the additional configuration of a supported FTP server.
In order to address this issue a set of security extensions to the original FTP protocol were proposed in RFC 2228 that protect FTP data as it travels over the network using SSL encryption. FTPS (FTP/SSL) is a name used to provide a number of ways that FTP software can perform secure file transfers. Each way involves the use of a SSL/TLS layer below the standard FTP protocol to encrypt the control and/or data channels.
Secure variants of FTP include FTPS Implicit SSL and FTPS Explicit SSL. Both utilize SSL encryption.
FTPS Implicit SSL
In implicit SSL mode a required SSL session is established between client and server before any data is exchanged. As it’s name suggests, the use of SSL is implied and any connection attempt made by a client without using SSL are refused by the server. FTPS implicit SSL services generally run on port 990. Although still in use today, FTPS Implicit SSL is considered by many to be obsolete in favor of FTPS Explicit SSL.
FTPS Explicit SSL
In explicit SSL mode the client and server negotiate the level of protection used. This is very useful in that the server can support both unencrypted FTP and encrypted FTPS sessions on a single port. In an explicit SSL session the client first establishes an unencrypted connection to the FTP service. Prior to sending user credentials, the client requests that the server switch the command channel to an SSL encrypted channel by sending the AUTH TLS or AUTH SSL command. Upon successful setup of the SSL channel the client sends user credentials to the FTP server. These credentials along with any other commands sent to server during the FTP session are automatically encrypted by the SSL channel. Similar to the way in which the command channel may be protected, the level of protection used on the data channel is negotiated between the client and server using the PROT command.
- Widely known and used
- The communication can be read and understood by a human
- 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 communications frameworks
- Does not have a uniform directory listing format
- Requires a secondary DATA channel, which makes it hard to use behind firewalls
- Does not define a standard for file name character sets (encodings)
- Not all FTP servers support SSL/TLS
- Does not have a standard way to get and change file or directory attributes
Server - Allow inbound connections on port 21 and / or 990. Define passive port range (e.g. 2000-2500) for file transfers and directory listings and allow inbound connections on passive port range. Consult your server documentation for instructions on how to set a passive port range.
Client – Allow outbound connections to port 21 and passive port range defined by server.
The SFTP (SSH File Transfer Protocol), also known as the Secure File Transfer Protocol, enables secure file transfer capabilities between networked hosts. Unlike the Secure Copy Protocol (SCP), SFTP additionally provides remote file system management functionality, allowing applications to resume interrupted file transfers, list the contents of remote directories, and delete remote files. All data sent between client and server is encrypted using an agreed upon encryption cipher. SFTP sessions can also be further protected through the use of public and private keys, which offer an alternative form of authentication known as public key authentication. This can be used as an alternative to or in conjunction with the traditional form of authentication of usernames and passwords.
- Has a good 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 not be logged “as is” for human reading
- SSH keys are harder to manage and validate
- The standards define certain things 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 .NET frameworks
Server – Allow inbound connections on port 22.
Client – Allow outbound connections to port 22.
One of the most noticeable differences between SSL/TLS and SSH is that SSL normally (yes, there can be exceptions) employs X.509 digital certificates for server and client authentication whereas SSH does not. And because SSL uses digital certificates, it consequently also requires the presence of a public key infrastructure (PKI) and the participation of a certificate authority (CA).
Although it’s possible to employ what are known as self-signed certificates, in which case SSL then becomes very similar to SSH due to the absence of a CA, this is not a recommended practice. Self-signed certificates are only acceptable in intra-organizational transactions, except in large (e.g. globally distributed) organizations.
Another big difference is that SSH has more functionality built into it. For instance, on its own, SSH can enable users to login to a server and execute commands remotely. SSL does not have this capability. You would need to pair it with another protocol (e.g. HTTP, FTP, or WebDAV) in order for it to have similar functions.
SSH also readily supports connection multiplexing, flow control, terminal management, and other features. Of course, those additional features no longer fall under our original discussion wherein we started comparing SSL and SSH in relation to SFTP and FTPS.