Filter by Category

SFTP vs. FTPS: What's the Best Protocol for Secure FTP?

SFTP versus FTPS apples to oranges comparisonAn increasing number of our customers are looking to move away from standard file transfer protocol (FTP) for transferring data, and often wonder which secure FTP protocol is recommended, what options are available and the main differences between them.

Protocol Overview

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.

Authentication: SFTP vs. FTPS

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).

Implementation: SFTP vs. FTPS

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, we believe SFTP is the clear winner for your secure FTP needs.

Use a more secure file transfer protocol.


Comments (12)

  1. Brian Buchholtz:
    Nov 01, 2011 at 09:32 AM

    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.

    1. Bob Luebbe:
      Nov 02, 2011 at 08:51 AM

      Good points Brian. Thanks for your feedback.

  2. Vince Ponko:
    Feb 12, 2012 at 09:59 AM

    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.

  3. Bob Luebbe:
    Feb 16, 2012 at 10:34 AM

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

  4. Hacking and File Transfers: What You Need to Know:
    Dec 04, 2012 at 09:35 AM

    [...] at the firewall. Then, for permitted file transfers, allow only secure encryption protocols such as SFTP, FTPS, HTTPS, PGP, or GPG for file exchanges in and out of the network. These security restrictions will [...]

  5. FTP Hacking – What you need to know. | Managed FTP:
    Jan 17, 2013 at 01:48 PM

    [...] at the firewall. Then, for permitted file transfers, allow only secure encryption protocols such as SFTP, FTPS, HTTPS, PGP, or GPG for file exchanges in and out of the network. These security restrictions will [...]

  6. Oscar:
    Aug 11, 2013 at 07:20 PM

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

    1. Bob Luebbe:
      Aug 20, 2013 at 08:16 AM

      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.

  7. Secured FTP - SFTP Vs. FTPS | Java CodeBook:
    Oct 31, 2013 at 07:35 AM

    […] […]

  8. Joshua Pettus:
    May 06, 2017 at 02:18 PM

    Those are some great points Vince about the advantages of CA certificates. But still, having to open a range of ports really makes FTPS a no go. Do I worry about the third lock on the back door when the front door is wide open?

  9. Steve:
    May 18, 2017 at 03:18 PM

    We are a small company and are doing an increasing amount of secure file transfer. We host our server on Lunarpages. When I asked them about setting up SFTP they said that SFTP requires root access for every user and recommended against it for transferring data between organizations. They recommended using FTPS and suggested that when most people say "SFTP" they really mean "FTPS". We have been led to believe that SFTP is not practical for sending and receiving files between organizations.

    Any comments?

  10. Josh Pettus:
    Oct 04, 2017 at 03:29 AM

    Whoever said SFTP requires root access for all users really doesn't know much about how to setup an SFTP server or the many many features of SSH...I used special accounts that are "jailed" to their home directory that have no further access.

Add a Comment

Allowed tags: <b><i><br>

Latest Posts

Tradeshow Recap: Exploring Cloud File Transfer at Red Hat Summit 2018

May 21, 2018

Last week marked the first year for GoAnywhere as an exhibitor at Red Hat Summit in San Francisco. The three-day conference was a whirlwind of activity, great conversations, and opportunities to…

3 Reasons to Attend VMUG's June 7 Virtual Event

May 17, 2018

Whether you’re already using VMware to manage multiple virtual machines in one console, or you’re just getting started with datacenter virtualization, staying on top of trends, changes,…

GoAnywhere MFT Not Affected by EFAIL Vulnerabilities

May 16, 2018

Ashland, NE, May 16, 2018  In light of the recent OpenPGP & S/MIME warning (EFAIL), GoAnywhere has performed a software security review of its managed file transfer solution to ensure…

Need Help with GDPR Compliance? 3 Simple Steps to Take Now

May 14, 2018

Do you need help preparing for the General Data Protection Regulation (GDPR) deadline on May 25, 2018? If you’re like 67% of IT and security professionals we recently surveyed, you may be well…

3 Cybersecurity Takeaways from RSA Conference 2018

May 8, 2018

The speed and intensity of cyberattacks are growing, and cyber siege is no joke. But the 45,000+ attendees who attended this year’s RSA Conference in San Francisco proved the force of…