If you work an industry that requires a whole lot of file transferring (basically any industry), then you’ve probably struggled to find a way to share files securely but also one that’s not too complex.
FTP, the file transfer protocol that’s been around longer than the internet, is one of the most popular ways to transfer files, but also one of the least secure. According to Deccanhosts, FTP is insecure because it sends your credentials in plain text. And not just the credentials, but “all the files that you exchange with the server (upload or download) are transferred in plain text without any encryption.”
Sending sensitive information over FTP is a pretty large risk since neither the command channel nor the data channel is encrypted. That is why many turn to the secure channels of SFTP (SSH file transfer protocol) and FTPS (file transfer protocol SSL) to transfer files. Both SFTP and FTPS offer a secure file transfer solution, but what is the difference between them? Is one more secure than the other? SFTP vs. FTPS: which one should I choose?
In this article, you’ll get a final recommendation from end-point security and IT experts on the battle between SFTP vs FTPS and I’ll also illustrate key differences and similarities between the technologies.
“We’re Not So Different, You and I,” said SFTP to FTPS
Let’s start off with the similarities between these two file transfer methods. Jaco Toledo, Director of IT at WireSeek, notes that “SFTP and FTPS are both protocols used to connect to a server through an encrypted connection and transfer files, the main difference is the type of encryption that they use and the process of authentication.”
They both use public keys over encrypted tunnels for authentication and are very reliable encryption methods that make it difficult for hackers to break into, but that is where Toledo says the similarities end.
“Actually, We’re Very Different,” said FTPS to SFTP
“The primary difference between the SFTP and FTPS protocols is the underlying transport mechanism. SFTP is an extension to the SSH protocol, whereas FTPS adds a layer around the legacy FTP protocol. Both protocols exist to transfer files between systems, but the transport protocols are completely unrelated,” says Phil Hagen, SANS Certified Instructor and Course Author, who also works as an Evangelist at Red Canary.
To break down those underlying transport mechanisms, we have to understand what the “S” in both SFTP and FTPS means.
SFTP: The “S” Means SSH or Secure Shell
SSH, or Secure Shell, is a cryptographic network protocol. This protocol allows remote machines to verify each other and then connect. Once this connection is verified, the machines can communicate and run commands. This connection can also be used to transfer files, aka SFTP.
Hagen clarifies, “SSH was originally designed to provide secure, remote command-line-based server management functions. Administrators historically used telnet for this purpose, but that protocol is plaintext, offering no protection whatsoever. On the other hand, SSH is fundamentally encrypted, protecting the data transferred from inspection by any third party intermediary.”
“SSH can also provide a number of additional functions – including SFTP. This ‘bolt-on’ function uses the same underlying protocol but for transferring files rather than command-line keystrokes. SFTP, by virtue of the underlying SSH protocol, uses a single connection between the client and the server for all actions: authentication, commands, file transfers, etc.,” said Hagen, “SFTP is an extension to the SSH protocol, whereas FTPS adds a layer around the legacy FTP protocol.”
- Has a great requirements background which strictly specifies most (if not all) elements of operations
- Has only one connection (no requirement for a DATA connection)
- The connection is constantly protected
- The directory site listing is consistent and machine-readable
- The method consists of operations for consent and quality adjustment, file locking, and more capability
- SFTP is supported by Linux and UNIX servers by default
- More options than any other system
- Can perform file system operations, such as file lock, permission and attribute manipulation, and symbolic link creation
- Single data connection makes it easy to use behind a firewall
- The interaction is binary and cannot be logged as is for human reading
- SSH secrets are more difficult to handle and verify
- The requirements specify specific things as optional or suggested, which causes specific compatibility issues in between various software application titles from various suppliers
- No server-to-server copy and recursive directory site elimination operations.
- No integrated SSH/SFTP assistance in VCL and .NET structures
- No server-to-server copy
- No recursive directory removal
- Harder to configure properly
- No built-in support in .NET framework
FTPS: The “S” Means SSL or Secure Sockets Layer
SSL, or Secure Sockets Layer, is a cryptographic protocol. (Now it’s known as Transport Layer Security (TLS), but that screws up our acronym, so just know that the terms are typically interchangeable, even though TLS is what is used today.)
Where SSH is mostly used for remote access, SSL/TLS is a way for two entities (i.e., a server and a client) to connect and communicate securely. This protocol is more popular since much of everything we do on the Internet (surfing, email, watching cat videos, social media, VoIP) use the SSL/TLS protocol to protect communication.
When it comes to transferring files, using FTP over SSL lets you encrypt your communications, but you’ll need to decide between implicit SSL and explicit SSL. Chris Sheaves, VP of Products at SmartFile, defines the differences:
FTPS (Implicit) – TCP port 990(command) + passive ports (data)
FTPS(I) was one of the first attempts to encrypt FTP communication. It let the client connect securely to the server and no negotiation was allowed. All other major operations of FTP stayed the same. This has been deprecated in favor of FTPS (Explicit).
FTPS (Explicit) – TCP port 21(command) + passive ports (data)
This was added to FTP to help negotiate encryption for the FTP communication. FTPS(E) functions the same as FTP except it negotiates an SSL or TLS connection when the client asks for it, prior to authentication.
- Commonly understood and utilized
- Easy to implement
- The interaction can be checked out and comprehended by a human
- Offers services for server-to-server file transfer
- SSL/TLS has excellent authentication systems (X. 509 certification functions)
- FTP and SSL/TLS assistance is constructed into numerous web interactions structures
- Communications can be read by humans, making it easier to troubleshoot a connection attempt
- Easily supported by mobile devices
- Works in operating systems that have FTP support but not SSH/SFTP clients
- Built-in support in .NET Framework
- Does not have a consistent directory site listing format
- Needs a secondary DATA channel, makings it hard to use behind firewall programs
- Does not specify a requirement for filename character sets (encodings)
- Not all FTP servers support SSL/TLS
- Does not have a conventional method to obtain and alter file or directory site characteristics
- Can’t perform file system operations
- Uses multiple ports, making firewall configuration more complicated.
Older FTP servers don’t support SSL
SFTP vs. FTPS? Who wins?
So, which secure file transfer method should you use?
According to Hagen, one is not technically “more secure” than another, “The encryption mechanisms are different, but when properly implemented, they can both sufficiently protect the authentication, commands, and data transferred. I personally feel that SFTP provides an easier path for ‘right-out-of-the-box’ protection, but a competent administrator can deploy either to a similar standard of security.“
Toledo also favors SFTP, “In general, SFTP is a superior protocol to FTPS. By default, unless you are a software developer and need to implement file transfer capability in your application, best practices would be to implement support for both protocols to increase compatibility.”
In the battle of SFTP vs. FTPS, I declare SFTP the winner. Have a different opinion? Leave it in the comments below.
Both Jaco Toledo and Rob Boirun, CEO of Ipinator and StreamJack, contributed to the pros and cons list.
SFTP vs. FTPS: Why Not Both?
Some secure FTP hosting providers make you decide between SFTP and FTPS. SmartFile can handle FTP, SFTP, FTPS and FTPES connections, among others. Give it a try for free today — no credit card required!
3 thoughts on “SFTP vs. FTPS: The Secure File Transfer Methods Battle It Out”
I personally like FTPS over SFTP because instead of implementing a whole new encryption system FTPS uses a tried and true layer of encryption called TLS.
As a programmer I prefer FTPS over SFTP. Since both can provide similar levels of security I will point out another factor. Ease of use for automating data transfer.
I have had to automate sending/receiving many types of transfers between many agencies,. The automation is the kicker here. I have found very few open source clients and fewer servers that have cross platform support and implement SFTP correctly. Open source is needed since GOV/Non-profit have a very tight budget.
Some SFTP report the sizes of files incorrectly when the server is also using compression. (eg returns compressed and not actual size) this throws offs some clients to download only partial files. Some clients do not care, but open themselves up for buffer overrun attacks.
Some clients are easier to include in other processes, since they do not need a separate ‘command’ file you also have to create for each transfer.
They have tons of interactive GUI’s based SFTP and FTPS programs for both graphical OS and text based operating systems. it’s when you try to automate a regular process that it becomes more of an issue.
Also HTTP / web based solutions are not the solutions, since you have yet another non-specific software package to install/setup/maintain. Furthermore; WEB based file trans fer is slower than FTP.
Unfortunately, I have to deal with secured file transfers a lot. I prefer SFTP. It is more standardized and usually just works. I have to jump through a lot of hoops and write more custom code with an FTPS connection.
One huge killer that I have noticed in my personal experience with FTPS is that it will “silently” default to plain FTP if the security handshakes fail. I have enough experience to know this and debug/exception handle each FTPS program I write to ensure that the connection is secure. However, someone less experienced may not know this and be happily sending sensitive data over plain FTP thinking that their connection is secure. Contrast this with SFTP, where if the security handshakes fail, you do not connect.