FTPS, which is also referred to as FTP Secure and FTP-SSL, is an extension of the File Transfer Protocol (FTP). FTPS retains all functionality that is found in FTP but adds support for the cryptographic protocols Transport Layer Security (TLS) and Secure Sockets Layer (SSL). Thanks to SSL and TLS, FTPS is able to encrypt the information that is transmitted through it across the web.
A parallel can be drawn between FTPS and HTTPS. Both protocols were created to add security to already existing protocols, FTP and HTTP respectively while retaining all of the functionality that was already present.
If you are familiar with FTP, then you know that it uses a Control Channel for communication between the client and the server and a Data Channel for the actual transfer of files. FTPS also uses these two channels to function and is able to encrypt the traffic on both.
Originally drafted in 1996 in RFC 2228, FTPS has enjoyed increasing popularity over the years. Today, it is a widely known protocol that is supported by numerous applications and development frameworks across all major operating systems. To learn more about FTPS, its security, how it differs from SFTP, and how to establish an FTPS connection, continue reading or jump to the section that interests you:
- How Does FTPS Secure My Connection?
- Which Port Does FTPS Use?
- What Is the Difference Between FTPS and SFTP?
- What Is the Difference Between FTPS and FTP?
- How Can I Connect Using FTPS?
- Should I Use FTPS?
- Conclusion
How Does FTPS Secure My Connection?
At the heart of FTPS, you will find a TLS/SSL digital certificate. A TLS/SSL certificate is based on the X.509 digital certificate standard and it is further enhanced by adding a few Extended Key Usage attributes. Thanks to these extensions, the TLS/SSL certificate is capable of encrypting the transmitted data between the FTPS client and the FTPS server. In addition, the TLS/SSL certificate aids in the user authentication process which is used to grant access to the protected information.
Digital certificates based on the X.509 standard include two sets of keys: public and private keys. The public key in a TLS/SSL certificate is used to validate and encrypt data. The private key, on the other hand, is used for decrypting the data that was encrypted using the public key. While the public key is widely available, as its name implies, the private key is stored separately from the public key, and only the FTPS client and the FTPS server have access to it.
FTPS further augments its security measures by implementing strong encryption algorithms such as AES, Triple DES, RC4, and RC2. Furthermore, it supports hashing functions like SHA, MD5, MD4, and MD2.
Thanks to its robust set of cryptographic features, FTPS can be set up to comply with various security requirements such as HIPAA, SOX, HITECH, PCI DSS, and other privacy laws.
So far, we have discussed the benefits of a TLS/SSL certificate, but how do you actually get one? There are two ways to do so – you can either purchase an SSL certificate from a trusted Certificate Authority (CA), or you can generate the certificate manually using a tool such as OpenSSL.
If generating an SSL certificate through a utility like OpenSSL is free, fast, and easy, you may be wondering why anyone would opt to pay for an SSL certificate to be generated by a Certificate Authority. The answer is that when the SSL comes from a reputable Certificate Authority, it establishes a chain of trust. The chain goes like this:
- Your device has a repository called a key store where it keeps the certificates of all Root Certificate Authorities. These certificates are trusted implicitly.
- The Root Certificate Authorities issue trusted certificates to Intermediate Certificate Authorities. Here at AwardSpace, we have partnered with a few Intermediate Certificate Authorities so that we can provide you with quality SSL products.
- The Intermediate Certificate Authorities then issue end-user SSL certificates. These certificates are recognized and trusted because they have been issued by a known Intermediate Certificate Authority which, in turn, has been certified by a Root CA.
The chain of trust is very important to businesses and organizations that have an online presence as it proves their identity and guards against man-in-the-middle attacks. To learn more about the value that TLS/SSL certificates bring to your online interactions, you can read our in-depth article on SSL.
At the other end of the trust spectrum, you will find self-signed TLS/SSL certificates that are created using tools like OpenSSL. These certificates are not implicitly trusted by your FTPS client. When you try to connect to an FTPS server that is using a self-signed TLS/SSL certificate, your FTPS client will likely pop up a warning message saying that the identity of the server cannot be confirmed. The reason why the TLS/SSL certificate is not trusted is that it has not been issued by a known and trusted Certificate Authority.
Most FTPS clients should allow you to ignore the warning and proceed with the connection. Others may even offer to save the public key of the self-signed TLS/SSL certificate in your trusted key store. If you allow the FTPS client to do so, it will regard the self-signed TLS/SSL certificate as trustworthy should it ever try connecting to it again.
During the FTPS connection process, the FTPS client is expected to challenge the FTPS server using a mutually known security mechanism. The client may query the server which mechanisms are supported using the FEAT command. The two most common security mechanisms that are used to start an FTPS connection are AUTH TLS and AUTH SSL.
Once the FTPS client has accepted the server’s TLS/SSL certificate, you will likely need to authenticate yourself in some fashion. User authentication in FTPS is carried out through usernames and passwords. User certificates can also be used as an added layer of security or they may serve as password replacements. When a user certificate is utilized, it must either be signed by a trusted Certificate Authority or its public key must be present in the key store on the FTPS server.
The above scenario where TLS/SSL authentication takes place at the very start of the FTPS connection is called Implicit FTPS. In addition to Implicit FTPS, there is another method of invoking a secure connection that is called Explicit FTPS. With the explicit security model, the connection begins using the regular File Transfer Protocol (FTP) and it can later be encrypted using TLS/SSL. We explore both of these security methods in greater detail below.
What Is Implicit FTPS?
Implicit FTPS offers a fully secure connection for both the Control and Data Channels from beginning to end. In fact, when you initiate an Implicit FTPS connection, the first thing the server will expect is a cryptographic challenge such as a TLS ClientHello message. If such a message is not received, the FTPS server is expected to reject the connection attempt.
There are two main downsides to using Implicit FTPS. The first is that Implicit FTPS is very resource-intensive since it encrypts every part of the client-server communication, even the parts that are not sensitive. The other downside is that by mandating a cryptographic challenge at the start of the client-server interaction, Implicit FTPS breaks compatibility with all FTP clients and FTP servers that do not support the FTPS protocol.
Lastly, we should note that nowadays Implicit FTPS is considered a deprecated protocol, and as such, it should not be used. Instead, you should be using Explicit FTPS which we will explore next.
What Is Explicit FTPS?
Explicit FTPS, also known as FTPES, is the second and more widely used security mode supported by FTPS. With an Explicit FTPS connection, the FTPS client needs to explicitly request an elevated level of security from the server. If such a request is sent, the client and the server must agree on a mutually supported encryption method and use it going forward.
That said, the FTPS client is not required to upgrade the non-secure connection to a secure one. If no security elevation request is made, the server can either continue communicating with the FTPS client through an unencrypted connection or may refuse the connection altogether. If the connection is upgraded to a secure one, it can later be downgraded back to an unsecure one as well.
Since FTPS is based on FTP, it uses two channels to transmit information – a Control Channel and a Data Channel. When an FTPS client wishes to encrypt the connection, it must use different commands depending on the channel that needs to be encrypted.
If you wish to encrypt the Control Channel, then your FTPS client must issue the command AUTH TLS. In the past, the command AUTH SSL was also permitted, but nowadays it is considered deprecated.
When the AUTH TLS command is used, the server must acknowledge the request and respond that the TLS authentication has been successful. Once you see this acknowledgment from the server, all future communication that occurs on the Control Channel will be encrypted.
It is important to stress that the AUTH TLS command will encrypt only the Control Channel where you mostly issue commands. Files are transmitted through the Data Channel which is not encrypted using AUTH TLS. It is generally recommended that you issue the AUTH TLS command as soon as possible, ideally, before you send any sensitive information such as your FTPS username and password.
So far, we have discussed encrypting the Control Channel only. To encrypt the Data Channel, you need to issue a different command which is PROT. Issuing this command will encrypt the files that are transmitted using the FTPS connection.
Just as you can encrypt either channel at any time, you may also opt to stop the encryption process on demand. The commands used to stop the encryption for the Control Channel and Data Channel are CCC (Clear Control Channel) and CDC (Clear Data Channel) respectively.
At this time, you may be wondering why someone would want to stop their encryption. When compared to regular unencrypted transfers, encryption consumes a lot of processing power. So, if you are going to be transferring a lot of non-sensitive files, it may be worth downgrading the FTPS connection so that you do not put unnecessary pressure on the server’s CPU.
Another popular scenario is to encrypt only the Control Channel while leaving the Data Channel unencrypted. Doing so will protect your username and password from being seen, but will transmit your files as-is without any encryption on them.
Which Port Does FTPS Use?
Implicit FTPS uses Port 990 for its Control Channel and Port 989 for its Data Channel. If you connect to an FTPS server using Port 990, it will expect a cryptographic challenge. If such a challenge is not received, the connection will be terminated by the FTPS server.
Explicit FTPS, on the other hand, uses Port 21 for its Control Channel which is also the default FTP Port. FTPES is able to re-use Port 21 in such a manner because all Explicit FTPS connections always begin as regular FTP sessions which later can have their security upgraded.
The idea behind the reusing of Port 21 for Explicit FTPS is to maintain compatibility with FTP clients that are not aware of the FTPS protocol. For example, you can use an FTP client that has no support for FTPS and still manage to successfully connect to an FTPS server and transfer files. As you might expect, the transfer will be unencrypted because your FTP client lacks FTPS knowledge and will never upgrade the connection security by sending the AUTH TLS command.
What Is the Difference Between FTPS and SFTP?
While FTPS and SFTP sound incredibly alike, they are two distinctly different file transfer protocols that are built upon different technologies. As we have discussed previously, FTPS is built upon the regular File Transfer Protocol (FTP) and uses X.509 Digital Certificates for authentication and encryption.
SFTP, on the other hand, is an entirely different protocol that is built as an extension to the popular SSH (Secure Shell) protocol. SFTP does not use digital certificates for security as FTPS does. Instead, it leverages the secure SSH keys and tunnel between the client and the server that is established during the creation of the SSH connection.
SFTP is generally seen as the more convenient solution, especially if the client or the server is protected behind a firewall. While FTPS uses Port 21 for Control Channel messages and a random high-level port for its Data Channel, SFTP uses a single Port 22 for all of its communication. As such, if you use FTPS, you will need to open a single port in your firewall as opposed to a whole range of ports to make FTPS work.
To learn more, you can read our article on the differences between FTPS and SFTP.
What Is the Difference Between FTPS and FTP?
The File Transfer Protocol (FTP) has been around since the dawn of the Internet. Back then, there was little to no malicious activity in cyberspace and as a result, the File Transfer Protocol was created without any security protections in place.
Nowadays, it is a different story. Security has become paramount due to a large number of threats such as hackers, spyware applications, man-in-the-middle attacks, and so on. All of these threats can be kept at bay using strong authentication and encryption. And that is precisely what FTPS brings to the table.
FTPS represents an evolution that builds upon the features found in FTP but adds support for encryption, data integrity, and secure authentication. In that sense, FTPS’ relationship with FTP is identical to the one HTTPS has with HTTP. In both cases, the original protocol was extended by adding support for TLS/SSL certificates.
How Can I Connect Using FTPS?
Most FTPS-aware clients allow you to specify the transfer protocol that will be used. When making the selection it is important to know which file transfer protocols are supported by the server. If you try forcing a protocol that the server does not support, your connection attempt will fail.
Some FTPS-aware clients like FileZilla fold FTPS connection options under the FTP umbrella. So, in order to connect using FTPS, you need to initially choose FTP as your connection method and later select that you wish to use encryption as well.
Other FTPS-aware clients will list FTPS as a connection option right alongside other options like FTP and SFTP. Cyberduck is a prime example of such a client.
Do All FTP Servers Support FTPS?
Sadly, not all FTP-capable servers will be able to support FTPS. This happens when the FTP server in question does not support TLS/SSL. What is more, even if a server has support for SFTP/SSH, it may still lack support for FTPS. As such, you may need to contact the server administrator in order to find out which transfer protocols are supported.
Here at AwardSpace, we try to bring support to as many transfer protocols as we possibly can. As a result, on our free hosting plan we have full FTP support, the most popular and widely used protocol. And on our premium shared hosting packages, semi-dedicated servers, and virtual private server instances we support FTP, FTPS, and even SFTP.
Which FTP Clients Support FTPS?
There is a wealth of clients out there that have FTPS support. You can find FTPS-capable clients for any operating system, either free or paid and with or without a graphical user interface. Some of the more notable FTPS clients include (in no particular order):
Should I Use FTPS?
FTPS enjoys widespread support and adoption throughout a lot of different applications. As such, it is a good option to transfer files securely, especially with older software. Developers who use Microsoft’s .NET framework will be happy to learn that support for FTPS is built right in and there’s no need to use third-party frameworks to achieve this functionality.
If you are the type of person who likes to see the inner workings of software, then FTPS will be right up your alley. All communication and messages are transmitted in human-readable form. In contrast, SFTP transmits all data in binary which makes it difficult to read.
Perhaps the biggest drawback of FTPS is that it uses multiple ports during communication. This makes it a less-than-ideal file transfer protocol if you or the remote server is located behind a firewall.
Lastly, we should note that FTPS offers encryption that is strong enough to pass industry and regulatory requirements such as HIPAA and PCI DSS.
Overall, FTPS is a perfectly adequate protocol to use. It offers strong encryption and can effectively protect the entire communication between the client and the server. As such, we can recommend its usage. The only exception will be when there is a firewall between you and the server. In those cases, we can recommend the use of SFTP as it provides an equal level of protection while using a single port for communication and data transfer.
Conclusion
FTPS takes the existing File Transfer Protocol (FTP) and augments it by adding support for TLS/SSL certificates. Thanks to the added certificate support, FTPS is capable of ensuring privacy by encrypting all data that is transmitted.
Nowadays, FTPS enjoys widespread adoption. Most FTP programs out there also support FTPS. There is also support for FTPS in most development frameworks like the .NET Framework.
Despite its wide use, FTPS is slowly being supplanted by SFTP. SFTP is an extension of the Secure Shell (SSH) protocol and also allows the secure transfer of files in a client-server model. SFTP is seen as more streamlined and as such newer applications prioritize support for SFTP and are slowly dropping support for the aging FTPS protocol.
