What is FTPS?

This article explains the FTPS protocol and how FTPS server software such as CompleteFTP can be used to securely transfer files.

FTPS (FTP Secure) is FTP over SSL connections.

A significant problem with "plain" FTP is that it is not secure - usernames, passwords and data are sent across the network in the clear. This means eavesdroppers sniffing the network will have little trouble obtaining credentials and copies of the transferred files.

The FTPS protocol was designed to fix this by encrypting communications using the SSL/TLS protocol, which is specifically designed for securing network connections.

FTPS is an IETF standard as described in RFC 4217.

1. Implicit FTPS and Explicit FTPS

An early version of the FTPS protocol is now known as implicit FTPS Protocol. Upon connecting, implicit FTPS protocol clients automatically start securing the connection using SSL/TLS.

This is a problem for unencrypted FTP clients - they will no longer be able to connect on a server port that requires securing the connection immediately. If FTP and FTPS (implicit) are to be supported on the same server, they require different port numbers. Typically, the implicit FTPS protocol uses port 990 rather than the standard FTP port 21.

Explicit FTPS fixed this by requiring the AUTH command to be sent by the client prior to securing the connection. This meant that unencrypted FTP clients can connect on the same port as FTPS protocol clients - the unencrypted clients simply never send an AUTH command and the session remains unencrypted. FTPS protocol clients send the AUTH command prior to logging in so that credentials are secured.

Implicit FTPS clients can still be found, but explicit mode is always preferred. Unless implicit mode is required it is best to have the implicit mode FTPS protocol disabled in CompleteFTP.

2. Securing Control and Data Channels

FTP sessions use two channels: control and data. Only one control-channel is used in each session, but several data-channels may be used – one for each data transfer. The AUTH command only secures the control-channel. Data- channels are not secured until PBSZ and PROT commands are issued. These commands tell the server whether or not subsequent data-channels should be secure.

Clients can connect to FTPS servers in unencrypted mode, and then switch to secure mode upon request. To do so, the client issues an AUTH command, upon which the client and the server negotiate a secure connection. After the switch, all FTP commands are encrypted, but importantly, data is not encrypted unless further commands are provided.

3. FTPS Protocol Commands

Three commands are used, AUTH, PBSZ, and PROT. One of these, PBSZ, appears to be redundant and is probably included only to satisfying the RFC specification.

3.1 AUTH (AUTHentication)

The AUTH command takes a single parameter which defines the security mechanism to be used, usually 'SSL' or 'TLS'.

With this command, an attempt is made to negotiate a TLS connection on the control channel. The server tries to validate itself to the client by sending its certificate (Server Validation). It may also involve the client sending its certificate to the server (Client Validation).

3.2 PBSZ Protection Buffer SiZe)

The PBSZ command is intended to define the buffer-size to be used by the security mechanism when it is encrypting data on the data-channel. However for TLS this setting is redundant and a value of '0' is always passed as a parameter.

While this call is redundant, it is required and must precede the PROT command.

3.3 PROT (data channel PROTection level)

PROT defines whether or not the data channel is to be protected or not. Either the data channel is Clear (the default), or Private. Clear means that no security is used on the data-channel (meaning files are transmitted without encryption), and Private means that the data-channel should be encrypted. So there are two possible PROT commands:

for an unsecured data-channel, and

for an encrypted data-channel.

4. FTPS Protocol Usage

A typical explicit FTPS session might consist of the following sequence of commands:

In this example, the first three commands (USER, PASS, and LIST) are standard FTP and therefore insecure. The AUTH command causes the rest of the commands to be sent to the server securely, in other words, an attacker cannot see which commands are issued. The RETR command (to fetch a file from the server), being after AUTH, is protected, but the actual file that is transferred is not protected since it precedes the PBSZ and PROT commands. PBSZ and PROT tell the server to use TLS on all future data-channels, thus the file transferred in the STOR command (which stores a file on the server) is secure.

4.1 Rules

There are two rules regarding the issuing of explicit FTPS protocol commands that must be followed:

Apart from these, a FTPS server has policies regarding access permissions to its resources. These policies will also determine the order in which commands must be issued. There are too many possible policies to list here, but a few examples of such policies are given below along with their consequences in terms of the issuing of commands.

5. SSL Certificates (a.k.a. TLS Certificates)

While users of the FTPS protocol may safely remain ignorant of most of the underlying security mechanisms, it is necessary that they understand the basics of public keys and certificates. In some cases, it is also necessary to understand which encryption/decryption algorithms (or ciphers) are available and what level of protection they offer.

5.1 Public Key Cryptography

Public Key Cryptography (PKC) is a paradigm which uses a pair of keys in a given communication; one key is used for encrypting the message and the other key is used for decrypting it. Each key may serve either purpose, but a message encrypted using one key may ONLY be decrypted by the other key.

The following illustration demonstrates how such a pair of keys may be employed for secure communication:

Party A has generated a key-pair. They retain one key, the private key, and distribute they other key, the public key, to Party B in a trustworthy way (see Section 4.1.2).

1. A encrypts a message using the private key and sends it to B. If B is able to decrypt the message using the public key, then B may be confident that the message did in fact originate from A, since only A has the private key.

2. B encrypts a message using the public key and sends it to A. Since the message may only be decrypted using the private key, and only A has this key, B may be confident that only A will be able to read the message.

Thus, using A's private/public pair of keys, B can ensure that (1) A is who they purport to be, and (2) Any messages that are sent to A can be read by that party only. However, the following weakness remain: (1) A cannot be confident that B is who B purports to be, and (2) Communications from A to B may be read by anyone who has the public key.

While both of these weaknesses may easily be overcome if B has their own key-pair and has provided the public key to A, this is often not practical due to the amount of effort involved. However, the latter shortcoming may easily be overcome in the following way:

3. B automatically generates a temporary key-pair. Since B may be confident that its messages to A are only read by A, B can securely provide one of the keys to A. Once A has received this key, they may use it to encrypt any messages sent to B. They may therefore be confident that only B can read any subsequent messages.

Thus, a single private-public key-pair has the potential to offer the following security:

I.Parties receiving messages from the owner of the key-pair can verify that encoded messages originated from the owner.

II.Secure messages may be sent between the owner and other parties.

As mentioned, this presumes that the owner of the key-pair is able to distribute their public keys in a trustworthy manner. In practice, this is achieved by means of public key certificates and Certificate Authorities.

5.2 Certificates and Certificate Authorities (CAs)

The previous section emphasized the need for public keys to be distributed in a trustworthy manner. Simply sending the key electronically should not be considered safe as the message might be tampered with on the way, though this is done in many cases. Having one person physically hand another a memory-stick containing the key would be probably acceptable, but is usually impractical. The solution used on the Internet is to use a trusted third party called a Certificate Authority (CA).

A CA is an organization which specializes in issuing public key certificates. They only issue certificates to parties (or subjects) after they have provided sufficient documentary evidence of their identity. There are only a few CAs in the world and, since their viability relies on their trustworthiness, they can usually be relied on to do a good job of validating their subjects.

Each CA has its own private-public key-pair and its own certificate (called a root certificate). Since there are so few CAs and since they rarely change their keys, it is feasible for software to be distributed with a list of the certificates of all existing CAs. For example, Microsoft's and Netscape's browsers are both distributed with files containing lists of root certificates.

A certificate issued to a subject by a CA contains:

• the identification of the subject,
• the public key of the subject,
• the identification of the CA which issued the certificate, and
• the digital signature, provided by the CA, which verifies the contents of the message.

A subject's certificate may be validated in the following way:

1. Use the identification of the CA to find the appropriate root certificate.
2. Use that root certificate to check the digital signature and thereby prove that the CA issued the certificate and that the information in the certificate has not been tampered with.
3. Verify the identification of the subject.

Once this has been done, the party can trust that the public key in the certificate is indeed the public key that they expected. This public key may henceforth be used to establish secure communications with the subject in the manner described in Section 12.

Note that although the CA has signed a certificate containing the public key of the subject, the CA does not have the subject's private key. To issue a certificate, the CA only requires access to the public key. The CA obtains this public key from the subject applying for a certificate. It is therefore up to the subject to generate the private-public key-pair before applying to a CA for a certificate.

5.3 Obtaining Keys and Certificates

A private-public key-pair is easy to generate. Likewise, an “uncertified” certificate may be generated with little effort, but obtaining a trustworthy certificate from a CA necessarily requires some work, time, and (usually) cost. It involves interacting with the CA to prove identity, and waiting for the CA to digitally sign the certificate.

Alternatively OpenSSL may be used. The reader is referred to the OpenSSL for instructions on generating key-pairs and certificates. It is recommended that keys with a length of at least 768 bits are used.

5.4 Server and Client Validation

The previous sections described how public key certificates may be used to validate parties involved in secure communications. They also explained why some work, time, and cost is involved in obtaining certificates.

The nature of Internet usage is such that it is important to distinguish between server validation and client validation. Server validation allows a client to know that it is talking to the intended server such as CompleteFTP. Conversely, client validation allows a server to know that it is talking to the intended client.

It is often more important for a client to know that it is talking to the intended server than the converse. The reason for this is often financial. For example, if a client is purchasing an item from an online retailer, the client needs to be certain that their credit card details are going to the intended destination. While it might be nice for the retailer to be certain where the money if coming from, it is not usually essential. Therefore, server validation is nearly always used in such transactions, but client validation is less often used. Other applications, such as Internet banking often use both client and server validation.

In the FTPS protocol, both server and client validation by certificate are optional. Though the server's certificate is always sent, it is up to the client whether or not it validates the certificate. It is up to the client whether or not it will try to validate itself to the server, but some servers have a policy of not allowing unvalidated clients to access some or all its resources.

It is important to note that, although many FTPS servers don't request client certificates, most require a user-name and password to be sent. If these are sent over a secure control channel then a reasonable level of client validation is inherent.

5.5 Hostname Checking

One of the steps in server validation is host-name checking. Host-name checking is a simple check that is performed when a secure connection is being established. It involves comparing the following two items:

• the host-name that is (usually) contained in the certificate which the FTPS server is presenting
• the host-name of the machine on which the FTPS server is running

If they match then one can be confident that the server to which the client is connected is in fact the server to which the certificate was issued. If they do not match, then there's a possibility that the certificate has been stolen and that the server, to which the client is connected, is attempting to "impersonate" the actual server to which the client is actually connected. This is a form of "man-in-the-middle" attack, which gives the attacker complete control over the data being sent and received.

Unfortunately, the most widely compatible version of the X.509 certificate standard does not specify exactly how a host-name should be defined within a server certificate. The convention is that the Common Name (CN) field of the certificate should be used, and, while this is followed by the majority of Certificate Authorities (CAs), it is not universal.

If it is possible to configure the FTPS server's certificate then the Common Name (CN) field of the certificate must be the same as the host-name of the machine on which the FTPS server is running.

Disabling host-name checking is strongly discouraged and should only be done as a last resort if the FTPS server's certificate cannot be configured so that its CN parameter contains its host-name.

6. Ciphers

SSL and TLS can use a variety of encryption/decryption algorithms (called ciphers). In a single secure connection, as many as four different ciphers may be used for various purposes; this set of ciphers is called a cipher suite. Each party in a secure connection must designate which cipher suites it is going to support. When a new secure connection is made, the parties involved try to agree on which cipher suite to use. There must be at least one cipher suite that is available on both sides of the connection for this to be possible.

Different cipher suites have different levels of security and performance. The lower the level of security, the easier the cipher is to break. Unfortunately, stronger ciphers usually offer slower performance. Hence, there is a certain level of trade-off between the two. For this reason, the decision on which cipher suites to support is left to the developers and/or users of SSL and TLS applications.

Every cipher suite has a standard name (e.g. TLS_RSA_WITH_RC4_128_SHA). This name reveals which ciphers are used in the suite.

Some guidelines which may be useful when selecting cipher suites are:

• Triple DES offers high security but relatively poor performance (look for names with the characters, 3DES).
• DES (not 3DES) can be cracked relatively easily
• 128-bit RC4 offers high performance and reasonable security (look for names with the characters RC4_128).
• SHA is preferable to MD5 (choose algorithms whose names ending with SHA ahead of those ending with MD5).
• Export version of algorithms are deliberately weakened; avoid them if possible (i.e. avoid 40-bit suites).

More information on how the FTPS protocol works.

What about SFTP?

Although superficially similar, SFTP is actually a completely different protocol. For a comparison with FTPS, please refer to FTPS vs SFTP.