What Users Don't Understand About FTP Security

In a previous post I noted that the original FTP specification devised over 40 years ago is inherently insecure.  Why?  Because the transmission stream itself is exposed (in the clear).

This means that the conversation between the FTP client and the FTP server has no protection at all. The User IDs, passwords and the data itself can be easily intercepted (or modified) by anyone listening to a router or other device in the path of the transmission.  It's akin to doing all your banking in the street: Anyone sleuth can see your transactions with just a little bit of effort.

Obviously, the solution is to upgrade your FTP transmissions to use some form of "Secure FTP" encryption technology.  But which one?

SFTP vs. FTPS

The two popular Secure FTP protocols are named SFTP (meaning FTP over SSH) and FTPS (meaning FTP over SSL).  Both SFTP and FTPS will create encrypted tunnels between your system and your trading partners.  In essence, anything that flows over those tunnels will be protected, including any user ids, passwords, commands, as well as any data that is transmitted.

One of the main differences between SFTP and FTPS is the way authentication is handled. 

With SFTP, clients can be authenticated with just a password or a Private Key.  SFTP is a binary protocol, the latest version of which is standardized in RFC 4253. All commands (requests) are packed to binary messages and sent to the server, which replies with binary reply packets. In later versions, SFTP has been extended to provide not just file upload/download operations, but also some file-system operations, such as file lock, symbolic link, creation, and so forth.

By comparison, FTPS (or, to be more precise, SSL/TLS protocol under FTP) uses X.509 certificates, whereas SFTP (SSH protocol) uses SSH keys.

With FTPS, clients can be authenticated with certificates, which are either self-signed (by your organization) or signed by a Certificate Authority (e.g. Verisign).

So what do these choices give to your users, who are trying to configure their FTP clients?  The answer is simple: Confusion!

Choosing the right type of Secure FTP protocol to use will depend on your trading partner's capabilities and authentication requirements.  You should not leave it up to your users to decide which secure protocol or methodology works best.  This can create a hodgepodge of approaches, none of which may meet your overall security and authentication policies.

This is an area where IT's expertise is required to ensure that the right form of encryption is utilized, that authentication mechanisms are properly implemented and that regulatory requirements have been met.

SFTP and FTPS Pros and Cons

Here are some technical pros and cons comparing SFTP to FTPS.

SFTP Pros:

  • Has good standards background that strictly defines most (if not all) aspects of operations
  • Has only one connection (no need for 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

SFTP Cons:

  • 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 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

FTPS Pros:

  • Widely known and used
  • The communication can be read and understood by humans
  • 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

FTPS Cons:

  • 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
  • No built-in SSH/SFTP support in VCL and .NET frameworks

But since, in a business setting, file transfer standards are often set by the business partner, choosing the right security protocol becomes complicated.  Often times a business partner's user will be faced with the same FTP security choices, and so there's no guarantee that IT can set a security standard that will be followed in all cases. 

So what can IT do?  The next post will describe a methodology for bringing the FTP environment under control.

© Copyright 2011, IT Incendiary