Cosine Jeremiah and his Musings

It is the File Transfer Protocol. FTP has been an important part of the Internet for more than 20 years. Businesses depend on it to transfer data from system to system and from business to business. In today’s world of SOX, HIPPA, PCI, and other standards and regulations companies are not only required to get the data moved, but to move it securely. “We need secure FTP,” cry the business units.

However, in the rush to address the needs to secure file transmissions we ended up with multiple protocols. And even among those protocols there are multiple standards regarding how to operate them. To connect a client to a server both sides have to select the same technology, and simply saying “we want/do secure FTP” just leaves implementors in a quandary about which kind of secure FTP.

SFTP — FTP over SSH

SFTP (S before FTP) is the protocol that describes an FTP-like protocol that is secured over an SSH channel. SSH’s standard port is 22, and so SFTP’s standard port is also 22. SFTP is very “firewall friendly” because all communications run over a single connection. On the down side, most implementations of SFTP carry with them a full implementation of SSH, and SSH is traditionally used for shell access. For a typical business connection, allowing shell access is highly undesirable. The most recent versions of SSH servers are beginning to realize an “SFTP only” configuration is a good feature to support, so this situation is fast improving.

FTPS — FTP over SSL

FTPS (S after FTP) is a different protocol entirely. FTPS is a super-set of the same FTP protocol that the Internet has relied upon for years and years, but it allows for encryption of the connection over an SSL or TLS encrypted socket. This protocol is harder to allow through firewalls because it follows the same process of opening additional connections from server to client or from client to server as the unencrypted version of the FTP protocol.

Implicit FTPS

To further complicate things a little, the FTPS protocol can be run in an “implicit” mode or an “explicit” mode. The implicit mode was used originally; it is an SSL encrypting socket wrapped around the entire communication starting at the point of initial connection. To differentiate this original FTPS from unencrypted FTP, the encrypted FTPS was assigned a standard port of 990. If you see an FTPS server running on port 990, that is almost certainly an implicit FTPS server. It is called “implicit” because the directive to encrypt the connection is implied by using port 990. Note that this mode is far less common than the explicit mode.

Explicit FTPS

Soon after FTPS was in use some smart people decided it would be best if we could have an FTP server that could support unencrypted as well as encrypted connections, and do it all over the same port. To accommodate this the “explicit” FTPS protocol connection begins as a normal unencrypted FTP session over FTP’s standard port 21. The client then explicitly informs the server that it wants to encrypt the connection by sending an “AUTH TLS” command to the server. At that point the FTPS-enabled server and the client begin the SSL or TLS handshake and further communications happen encrypted. Note that most (if not all) explicit FTPS servers can be optionally configured to require encryption, so it will deny clients that attempt to transfer data unencrypted. Often this can be configured on a user by user basis.

Of these three “secure FTP” protocols, only explicit FTPS is defined by an RFC. In this case it is RFC 4217, released in 2005, even though all these protocols had been in use for years prior.

By the way, I have not discussed what encryption algorithms each of these modes use. They all can use AES if you want, and they often have other good options, too. Do not worry about the algorithm when simply selecting which protocol to use; they are all good from this standpoint.

Comparison

Which kind of secure FTP should you use? It really depends on your business, software availability, and network firewall situation. I personally have no preference for or against any of these protocols on their base merits. Here is a table recapping some of the differences:

Firewall Implications

I have been mentioning some firewall implications for the FTP over SSL variants, but let us go into more detail. The FTP protocol initially opens one connection to authenticate the user and for the user to issue commands to the server. This is all well and good until the user wants to view the contents of a directory or transfer a file. Once either of those activities are requested, there is another connection made. To make things even more fun, the connection can be either from client to server (called passive mode) or from server to client (called active mode). I will just simply call these passive and active data connections, respectively, based on the name of the mode of transfer.

When FTP is always unencrypted, firewalls have been using a little trick to allow the active and passive data connections. They can snoop your connection and see what ports are being decided upon for these connections, and then they quickly allow the connection to get through once. That option is not available when the connection is encrypted. Thus, firewalls need another way to figure things out.

The active data connections (from server back to client) turn out to be relatively easy to firewall from the server side. They always use port 20 (for explicit FTPS) or port 989 (for implicit FTPS) as the source port of the connection (this can be configured to be a different port in many servers). A firewall protecting an FTPS server can just confirm that there exists at least one FTPS connection to that server, and assume that outbound connections with the right source port are okay. Most firewalls just end up being configured to always allow these connections based on the source port, and that is usually okay, too.

The passive data connections, by default on most servers, could be anything inbound between 49152 and 65535 (or sometimes between 1024 and 65535, depending on OS and server). Most organizations do not want to allow this many ports through the firewall to the server. Fortunately, the better FTPS servers also allow this range to be configured. Select a fixed range large enough to handle your traffic load and configure your FTPS server to only use that range for its passive ports. Then allow those ports through the firewall in addition to the main connection at 21 or 990.

If you want to serve the greatest number of clients with your FTPS server, you will want to support both active and passive mode connections. Some clients can figure out how to get one type but not the other through their firewalls. You can never guess which one it will be, though passive mode is more likely because all they have to do is allow the connections out from their network. If for some reason your organization decides to only support one mode and not the other, make sure your clients have some means of being notified! Even better if you can configure your FTP server to simply deny an attempt to open data connections using the mode your firewalls do not permit.

Note that even if you are not using SFTP or FTPS, there are other means of securing FTP connections defined in RFC 2228. Someone could, in theory, refer to a “secure FTP” connection that uses another means besides SSH or SSL to secure the connection via the extensions to the FTP protocol defined by that RFC. In practice (excepting Kerberized FTP), I have seen only the types of secure FTP I described above.

I wrote this article to help you decide which type of secure FTP to use. You need to know all these issues to make the best decision for your company: SFTP versus FTPS, implicit versus explicit, and active versus passive. Perhaps even more important is that you need to know how to correctly communicate your decisions to other technical implementers, and you need to understand the right questions to ask of others intending to implement (or already have implemented) “secure FTP” but who do not know about the differences between these forms.