FTPS or SFTP? It’s not Agatha Christie
In 1941 crime novelist Agatha Christie published her detective book “N or M?”; while selecting between FTPS or SFTP is hardly the same thing, you still might need to use some sleuthing skills to make the right choice.
Partners in crime
Let’s start by looking at which protocol was around first; FTP by a mile – but not in a secured state initially. FTPS makes use of either the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols to provide connection security through encryption; this is provided by the FTPS servers x.509 format public key certificate. The certificate may be trusted (provided by a trusted certification authority), or else self-signed. Using a self-signed certificate does not mean the level of encryption is any less, just that you have to be sure that the host is who they say they are. FTPS connections are made secure either implicitly or explicitly. FTPS servers generally listen for implicit connections on port 990 and explicit connections on port 21 – although of course the server administrator may choose to use different ports if they desire.
An implicit connection starts with the client issuing a TLS “Client Hello” message; this message implies that the connection should be secure and if the server doesn’t receive it, the connection is immediately dropped. If however the server does receive the “Client Hello” message, it will send the server certificate to the client, which will authenticate it and use it to encrypt a session key which it then sends back to the server to encrypt the session with.
In the case of explicit FTPS, the client explicitly requests security by sending an “AUTH TLS” (or AUTH SSL) command straight after the connection is made. If the AUTH command is not sent, the FTPS server will treat the client connection as a ‘regular’ non-secure FTP session instead.
Interestingly, implicit connections are not listed in RFC 2228 (the FTPS documentation), only explicit connections.
In either case, once the session has started, the client will need to authenticate to the FTPS server – normally this will be by userid and password, but may also include client certificates if required. All FTP commands are quite naturally passed along the control channel (normally 21 for explicit or 990 for implicit), but FTPS then needs a separate channel for data communications (the actual sending of files or directory lists). The data channels are by default port 20 for explicit FTPS and port 989 for implicit FTPS. Data channels are opened as they are required, then immediately closed again (the control channel remains open for the duration of the session).
In the style of so many detective story plots, SFTP is not what you might immediately suspect it to be – a form of FTP. In fact, FTPS and SFTP are completely unrelated and bear only a passing resemblance in the structure of many commands. SFTP is not FTP over an SSH connection, rather a distinct protocol in its own right which makes use of the underlying SSH protocol to provide connection security and authentication. Because it is using the underlying SSH protocol, it is normal to use the SSH port (generally port 22).
With SFTP we move away from using certificates for encryption and instead use public/private key pairs, which are not signed by trusted authorities. Like an FTPS self-signed certificate, the only area of doubt is that the server is who it professes to be – once you are confident that you have connected to the right server, you simply accept the server key and proceed to exchange files over an encrypted session.
The most important difference between FTPS and SFTP is that SFTP requires just one port to operate on – there is not a separate data and control channel to take care of.
In contrast to FTPS where clients occasionally provide a certificate for authentication, it is common practice for SFTP batch clients to authenticate by key only to avoid the need to store and maintain passwords.
Cards on the table
So having considered some basics of both FTPS and SFTP, let’s look at some of the details and see what each can do that the other can’t. Mostly speaking, what one can do the other can too – there are a few exceptions though:
- FTPS will allow you to create custom commands
- SFTP has better control of file permissions, ownership and properties
- FTPS allows use of Trusted x.509 certificates
- SFTP only requires a single port to be open on the firewall
- FTPS supports EBCDIC transfers
- SFTP allows creation of symbolic links
- Windows servers and clients don’t natively support SFTP
- SFTP is simple to install and manage on Linux and Unix servers
And then there were none
Mostly the decision on which protocol to use comes down to the requirements of the organisation; if there is a prevalence of linux/unix servers in a network, SFTP may be the better choice. Conversely, in a Windows only environment it makes no sense to install SFTP as it would require clients to be installed everywhere.
In addition, some firewall administrators would be happier to use SFTP with it’s single port, while some server administrators may not want SSH access to their servers enabled.
Otherwise it makes sense where possible to invest in file transfer server software that supports both protocols and leave the choice up to the clients.
Get Your Free Copy Of Our Brand New Book,
“THE EXPERT GUIDE TO MANAGED FILE TRANSFER”
The Expert Guide distills our knowledge from more than 700 Managed File Transfer
projects into a resource to get your project started.
- What is Managed File Transfer, EFSS, Big Data, High Availability etc?
- What problems Managed File Transfer can solve? With real life use cases.
- 40 key considerations for a successful Managed File Transfer project.
- A side by side comparison of eight leading Managed File Transfer solutions.