SFTP versus FTPS – What is the best protocol for secure FTP?

This entry was posted by on Thursday, 20 October, 2011 at

SFTP versus FTPSAn increasing number of our customers are looking to move away from standard FTP for transferring data, so we are often asked which secure FTP protocol we recommend. In the next few paragraphs, I will explain what options are available and their main differences.

The two mainstream protocols available for Secure FTP transfers are named SFTP (FTP over SSH) and FTPS (FTP over SSL). Both SFTP and FTPS offer a high level of protection since they implement strong algorithms such as AES and Triple DES to encrypt any data transferred. Both options also support a wide variety of functionality with a broad command set for transferring and working with files. So the most notable differences between SFTP and FTPS is how connections are authenticated and managed.

With SFTP (FTP over SSH), a connection can be authenticated using a couple different techniques.  For basic authentication, you (or your trading partner) may just require a user id and password to connect to the SFTP server. Its important to note that any user ids and passwords supplied over the SFTP connection will be encrypted, which is a big advantage over standard FTP.

SSH keys can also be used to authenticate SFTP connections in addition to, or instead of, passwords. With key-based authentication, you will first need to generate a SSH private key and public key beforehand. If you need to connect to a trading partner’s SFTP server, you would send your SSH public key to them, which they will load onto their server and associate with your account. When you connect to their SFTP server, your client software will transmit your public key to the server for authentication. If the keys match, along with any user/password supplied, then the authentication will succeed.

With FTPS (FTP over SSL), a connection is authenticated using a user id, password and certificate(s).  Like SFTP, the users and passwords for FTPS connections will also be encrypted. When connecting to a trading partner’s FTPS server, your FTPS client will first check if the server’s certificate is trusted. The certificate is considered trusted if either the certificate was signed off by a known certificate authority (CA), like Verisign, or if the certificate was self-signed (by your partner) and you have a copy of their public certificate in your trusted key store.

Your partner may also require that you supply a certificate when you connect to them.  Your certificate may be signed off by a 3rd party CA or your partner may allow you to just self-sign your certificate, as long as you send them the public portion of your certificate beforehand (which they will load in their trusted key store).

In regards to how easy each of the secure FTP protocols are to implement, SFTP is the clear winner since it is very firewall friendly. SFTP only needs a single port number (default of 22) to be opened through the firewall.  This port will be used for all SFTP communications, including the initial authentication, any commands issued, as well as any data transferred.

On the other hand, FTPS can be very difficult to patch through a tightly secured firewall since FTPS uses multiple port numbers. The initial port number (default of 21) is used for authentication and passing any commands.  However, every time a file transfer request (get, put) or directory listing request is made, another port number needs to be opened.  You and your trading partners will therefore have to open a range of ports in your firewalls to allow for FTPS connections, which can be a security risk for your network.

In summary, SFTP and FTPS are both very secure with strong authentication options.  However since SFTP is much easier to port through firewalls, and we are seeing an increasing percentage of trading partners adopting SFTP, I believe SFTP is the clear winner for your secure FTP needs.

Be Sociable, Share!

Bob Luebbe

Bob Luebbe has worked in the IT field since 1985. During his career, he has worked in a wide variety of roles including software development, project management, consulting and architecting large-scale applications. Bob has been with Linoma Software since 1994 and is currently serving its Chief Architect. His main focus for the last several years has been developing technologies to help organizations to automate and secure their file transfers, as well as to protect data at rest through encryption and key management.

More Posts - Website

9 Responses to “SFTP versus FTPS – What is the best protocol for secure FTP?”

  1. Personally, I believe that the use of any secure FTP is a step in the right direction. I’ve been out in the field, and you’d be surprised how much sensitive data is still being transacted in the clear. However, if I were to have a choice over which secure FTP technology were to be leveraged, then I’d choose SFTP.

    The firewall concern is a big deal, especially for a busy server, with lots of concurrent connections. It’s not uncommon that an FTP server, which supports passive mode connections, needs open inbound port ranges in the 100′s, sometimes even the 1000′s. These are ports that an organization has to open to the internet and monitor for abuse. But, most network engineers already know to cringe about this aspect of passive mode FTP.

    However, there’s another side to the firewall story: the clients. I’ve been finding that an increasing amount of organizations are blocking outbound as well, on the firewall. Passive mode ports (which lack an allocation standard) must be defined as permissible destination ports. Another big network headache.

    In terms of encryption and authentication, SFTP supports key-based authentication and fingerprinting; whereas, FTPS does not. And, in my honest opinion, I’ve yet to see any significant, practical advantages a CA-signed cert has over self-signed, in the area of FTP. For instance, FTPS clients can store host SSL certs as approved key material.

  2. Good points Brian. Thanks for your feedback.

  3. Vince Ponko

    I really wanted to comment on FTPS and SFTP. I always get
    the two confused. So if I have done that here, I apologize
    in advance. Here I use FTPS to refer to the extensions
    of FTP that use the SSL/TLS protocol and its authentication
    mecganisms. I use SFTP to refer to the SSH-pased protocol
    that uses SSH authentication.

    It seems to me that a case can be made that the different
    models of trust and key management underlying the two
    protocols are actually one of the most significant and
    useful differences between them. And that these differences
    can actually be leveraged to build a complex system with
    some interesting properties. I know the models of trust and authentication were discussed above, but I will repeate some of that information here because that is the focus of my comments and I want to highlight some things about them. Most of the discussions I have seen about the differences between FTPS and SFTP focus on administration and firewall navigation. Classic FTP is not very firewall-friendly, as it were, because of the need to open two ports per session and the need in one of the more efficient permutations, to open one of the ports inbound. These are naturally also concerns for FTPS because it is an extension of FTP. SSH, and consequently SFTP, only needs one outbound port as I understand it.

    WHat FTPS brings to FTP, however, is a hierarchical model
    of trust and public key management based on X.509 certificates
    and certificate authorities. SSH has a direct model of trust
    based on direct comparisons of key copies in local repositories and key management based on out-of-band direct distribution of public keys. Note that self-signed certificates can be used in FTPS. This is common in actual business practice although In my opinion it technically violates standard up to TLS 1.0. There may be an acknowledgement of it in newer versions of TLS.
    I haven’t checked recently and it is not necessary for these
    comments. The point about self-signed certificates that I want to make here is that you they are essentially functionally the same in terms of trust model as SSH keys. They have to be exchanged out-of-band for obvious reasons and authentication of the information in them performed by direct comparison with a local copy, again for obvious reasons.

    I think it can be argued that direct trust is in some ways
    unwieldy, especially on a large scale, because of the need to
    keep up to date local copies of public keys and, in the case
    of SSH keys, to manually associate them with remote systems.

    These were some of the problems that CA trust was invented
    to address. With CA trust, you do not need to maintain local
    copies of server certificates. You just need to maintain
    secure local copies of issuing certificates. If you trust
    the issuing certificates, you can trust the information in
    server certificates. You can rely on the CA to maintain
    information about revocation of server certificates instead
    of having to modify a local database if a key is compromised.

    Even more interestingly, in my opinion, you can use CA trust
    and client authentication to build closed trading partner
    networks where access can can be administred centrally and
    independently of the databases on the server systems if you
    want to maintain a private CA. You simply issue client
    certificates to those you want to allow on your network and
    revoke them when you want to shut off access. The CA and
    its signing certificates can be located deep within a secure
    enterprise infrastructure protected by physical and procedural
    controls and administered by separate individuals from network
    servers used for communication. You just have to be able to
    publish CRLs or run an OCSP responder somewhere the communication servers can get to it.

    The idea of a hybrid model is that if you are using the system to transmit business documents or messages that contain all the information needed by business systems for processing (for instance EDI) you could consider putting FTPS servers in a DMZ area and using CA trust to control access to them by trading partners, perhaps in conjunction with firewall access rules. If the business documents have all the information needed for further processing, you do not need to propagate any meta-data from the communication servers further. If that is the case, you could find a way to aggregate inbound business documents into one or a few directories. Then you could consider putting SFTP servers that can access the machines with those directories
    inside the DMZ and only opening outbound firewall ports to them. Because you would be administering potentially only a few SFTP servers and clients, you would not have issues with managing large numbers of direct trust relationships.

    These are just some thoughts about these prococols based on my experience with them. I did not do any detailed specific research for these comments. They are presented here merely as ideas for discussion. They may be entirely misguided. Use them at your own risk and at your own discression. Any security architecture should have a detailed evaluation by competent, preferably outside, experts before being implemented by an organization.

  4. Bob Luebbe

    Thanks for your detailed feedback Vince. I like your points on how CA trust can simplify FTPS authentication.

  5. Oscar

    By the way… SFTP is not FTP over SSH. Its has nothing to do with FTP or FTPS. SFTP goes under RFC 4253.

  6. Its true that SFTP is a different RFC standard, however it does provide many of the same command line capabilities of FTP such as get, put, etc. so many just refer to it as as FTP over SSH. FTP has been such a popular approach for transferring files over the last few decades, that it often seen as synonymous with file transfers.

Trackbacks/Pingbacks

  1. Hacking and File Transfers: What You Need to Know
  2. FTP Hacking – What you need to know. | Managed FTP
  3. Secured FTP - SFTP Vs. FTPS | Java CodeBook

Leave a Reply



*