FTPS

Last updated
File Transfer Protocol over TLS
Communication protocol
Purpose File transfer
Based on FTP, TLS
Port(s) For implicit FTPS, 990 for control, 989 for data transfer
RFC(s) RFC   959 (FTP), RFC  8446 (TLS 1.3), RFC  4217 (Explicit FTPS)

FTPS (also known as FTP-SSL and FTP Secure) is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer (SSL, which is now prohibited by RFC7568) cryptographic protocols.

Contents

FTPS should not be confused with the SSH File Transfer Protocol (SFTP), a secure file transfer subsystem for the Secure Shell (SSH) protocol with which it is not compatible. It is also different from FTP over SSH, which is the practice of tunneling FTP through an SSH connection.

Background

The File Transfer Protocol was drafted in 1971 for use with the scientific and research network, ARPANET. [1] Access to the ARPANET during this time was limited to a small number of military sites and universities and a narrow community of users who could operate without data security and privacy requirements within the protocol.

As the ARPANET gave way to the NSFNET and then the Internet, a broader population potentially had access to the data as it traversed increasingly longer paths from client to server. The opportunity for unauthorized third parties to eavesdrop on data transmissions increased proportionally.

In 1994, the Internet browser company Netscape developed and released the application layer wrapper, Secure Sockets Layer. [2] This protocol enabled applications to communicate across a network in a private and secure fashion, discouraging eavesdropping, tampering, and message forgery. While it could add security to any protocol that uses reliable connections, such as TCP, it was most commonly used by Netscape with HTTP to form HTTPS.

The SSL protocol was eventually applied to FTP, with a draft Request for Comments (RFC) published in late 1996. [3] An official IANA port was registered shortly thereafter. However, the RFC was not finalized until 2005. [4]

Methods of invoking security

Two separate methods were developed to invoke client security for use with FTP clients: Implicit and Explicit. While the implicit method requires that a Transport Layer Security is established from the beginning of the connection, which in turn breaks the compatibility with non-FTPS-aware clients and servers, the explicit method uses standard FTP protocol commands and replies in order to upgrade a plain text connection to an encrypted one, allowing a single control port to be used for serving both FTPS-aware and non-FTPS-aware clients.

Implicit

Negotiation is not supported with implicit FTPS configurations. A client is immediately expected to challenge the FTPS server with a TLS ClientHello message. If such a message is not received by the FTPS server, the server should drop the connection.

In order to maintain compatibility with existing non-FTPS-aware clients, implicit FTPS was expected to listen on the IANA well known port 990/TCP for the FTPS control channel, and port 989/TCP for the FTPS data channel. [5] This allowed administrators to retain legacy-compatible services on the original 21/TCP FTP control channel.

Note that implicit negotiation was not defined in RFC 4217. As such, it is considered an earlier, deprecated method of negotiating TLS/SSL for FTP. [6]

Explicit

In explicit mode (also known as FTPES), an FTPS client must "explicitly request" security from an FTPS server and then step up to a mutually agreed encryption method. If a client does not request security, the FTPS server can either allow the client to continue in insecure mode or refuse the connection.

The mechanism for negotiating authentication and security with FTP was added under RFC 2228, which included the new FTP command AUTH. While this RFC does not explicitly define any required security mechanisms, e.g. SSL or TLS, it does require the FTPS client to challenge the FTPS server with a mutually known mechanism. If the FTPS client challenges the FTPS server with an unknown security mechanism, the FTPS server will respond to the AUTH command with error code 504 (not supported). Clients may determine which mechanisms are supported by querying the FTPS server with the FEAT command, although servers are not necessarily required to be honest in disclosing what levels of security they support. Common methods of invoking FTPS security included AUTH TLS and AUTH SSL.

The explicit method is defined in RFC 4217. In the later versions of the document, FTPS compliance required that clients always negotiate using the AUTH TLS method.

Transport Layer Security (TLS)/Secure Socket Layer (SSL)

General support

FTPS includes full support for the TLS and SSL cryptographic protocols, including the use of server-side public key authentication certificates and client-side authorization certificates. It also supports compatible ciphers, including AES, RC4, RC2, Triple DES, and DES. It further supports hash functions SHA, MD5, MD4, and MD2.

Scope of use

In implicit mode, the entire FTPS session is encrypted. Explicit mode differs in that the client has full control over what areas of the connection are to be encrypted. Enabling and disabling of encryption for the FTPS control channel and FTPS data channel can occur at any time. The only restriction comes from the FTPS server, which has the ability to deny commands based on server encryption policy.

Secure command channel

The secure command channel mode can be entered through the issue of either the AUTH TLS or AUTH SSL commands. After such time, all command control between the FTPS client and server are assumed to be encrypted. It is generally advised to enter such a state prior to user authentication and authorization in order to avoid the eavesdropping of user name and password data by third parties.

Secure data channel

The secure data channel can be entered through the issue of the PROT command. It is not enabled by default when the AUTH TLS command is issued. After such time, all data channel communication between the FTPS client and server is assumed to be encrypted.

The FTPS client may exit the secure data channel mode at any time by issuing a CDC (clear data channel) command.

Reasons to disable encryption

It may not be advantageous to use data channel encryption when performing transfers under the following scenarios:

  • Files being transferred are of a non-sensitive nature, making encryption unnecessary,
  • Files being transferred are already encrypted at the file level or are passing over an encrypted VPN, making encryption redundant,
  • Available TLS or SSL encryption modes do not meet desired level of encryption. This is common with older FTPS clients or servers that may have been limited to 40-bit SSL due to previous United States high-encryption export laws.

It may not be advantageous to use control channel encryption under the following scenarios:

  • Use of FTPS when the client or server reside behind a network firewall or network address translation (NAT) device. (See Firewall Incompatibilities below.)
  • Repeated use of AUTH and CCC/CDC commands by anonymous FTP clients within the same session. Such behavior can be used as a resource-based denial of service attack as the TLS/SSL session must be regenerated each time, using server processor time.

SSL certificates

Much like HTTPS, FTPS servers must provide a public key certificate. These certificates can be requested and created using tools such as OpenSSL.

When these certificates are signed by a trusted certificate authority, this provides assurance that the client is connected to the requested server, avoiding a man-in-the-middle attack. If the certificate is not signed by a trusted CA (a self-signed certificate), the FTPS client may generate a warning stating that the certificate is not valid. The client can choose to accept the certificate or reject the connection.

This is in contrast to the SSH File Transfer Protocol (SFTP), which does not present signed certificates, but instead relies on Out-of-band authentication of public keys.

Firewall incompatibilities

Because FTP uses a dynamic secondary port (for data channels), many firewalls were designed to snoop FTP protocol control messages in order to determine which secondary data connections they need to allow. However, if the FTP control connection is encrypted using TLS/SSL, the firewall cannot determine the TCP port number of a data connection negotiated between the client and FTP server. Therefore, in many firewalled networks, an FTPS deployment will fail when an unencrypted FTP deployment will work. This problem can be solved with the use of a limited range of ports for data and configuring the firewall to open these ports.

See also


Notes

  1. ↑ Abbay Bhushan; Bob Braden; Will Crowther; Eric Narslem; John Heafner; Alex McKenzie; John Melvin; Bob Sundberg; Dick Watson; Jim White (17 November 1971). THE FILE TRANSFER PROTOCOL. Network Working Group. doi: 10.17487/RFC0265 . RFC 265.Unknown. NIC 781. Obsoleted by RFC  354. Updated by RFC  281, 294, 310. Obsoletes RFC  172.
  2. ↑ "The SSL 0.2 Protocol". mozilla.org. Feb 9, 1995. Archived from the original on 2001-06-14.
  3. ↑ Paul Ford-Hutchinson; Tim Hudson; Eric Murray (1996-11-26). Secure FTP Over SSL. I-D draft-murray-auth-ftp-ssl-00.
  4. ↑ P. Ford-Hutchinson (October 2005). Securing FTP with TLS. Network Working Group. doi: 10.17487/RFC4217 . RFC 4217.Proposed Standard. Updated by RFC  8996
  5. ↑ "Service Name and Transport Protocol Port Number Registry". Internet Assigned Numbers Authority. Retrieved 9 October 2015.
  6. ↑ "Deprecated SSL negotiation mechanisms". Securing FTP with TLS. 5 April 2001. sec. A. I-D draft-murray-auth-ftp-ssl-07. Retrieved 9 October 2015.

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by e-mail clients to retrieve e-mail from a mail server. Today, POP version 3 (POP3) is the most commonly used version. Together with IMAP, it is one of the most common protocols for email retrieval.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

The Secure Shell (SSH) Protocol is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

Telnet is a client/server application protocol that provides access to virtual terminals of remote systems on local area networks or the Internet. It is a protocol for bidirectional 8-bit communications. Its main goal was to connect terminal devices and terminal-oriented processes.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network. FTP is built on a client–server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a plain-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).

Virtual private network (VPN) is a network architecture for virtually extending a private network across one or multiple other networks which are either untrusted or need to be isolated.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network, such as the Internet. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded. A SOCKS server accepts incoming client connection on TCP port 1080, as defined in RFC 1928.

In computing, the SSH File Transfer Protocol is a network protocol that provides file access, file transfer, and file management over any reliable data stream. It was designed by the Internet Engineering Task Force (IETF) as an extension of the Secure Shell protocol (SSH) version 2.0 to provide secure file transfer capabilities, and is seen as a replacement of File Transfer Protocol (FTP) due to superior security. The IETF Internet Draft states that, even though this protocol is described in the context of the SSH-2 protocol, it could be used in a number of different applications, such as secure file transfer over Transport Layer Security (TLS) and transfer of management information in VPN applications.

File eXchange Protocol is a method of data transfer which uses FTP to transfer data from one remote server to another (inter-server) without routing this data through the client's connection. Conventional FTP involves a single server and a single client; all data transmission is done between these two. In the FXP session, a client maintains a standard FTP connection to two servers, and can direct either server to connect to the other to initiate a data transfer. The advantage of using FXP over FTP is evident when a high-bandwidth server demands resources from another high-bandwidth server, but only a low-bandwidth client, such as a network administrator working away from location, has the authority to access the resources on both servers.

OpenVPN is a virtual private network (VPN) system that implements techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It implements both client and server applications.

In computer networks, a tunneling protocol is a communication protocol which allows for the movement of data from one network to another. It can, for example, allow private network communications to be sent across a public network, or for one network protocol to be carried over an incompatible network, through a process called encapsulation.

This article lists communication protocols that are designed for file transfer over a telecommunications network.

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

HTTP tunneling is used to create a network link between two computers in conditions of restricted network connectivity including firewalls, NATs and ACLs, among other restrictions. The tunnel is created by an intermediary called a proxy server which is usually located in a DMZ.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

SMTPS (Simple Mail Transfer Protocol Secure) is a method for securing the SMTP using transport layer security. It is intended to provide authentication of the communication partners, as well as data integrity and confidentiality.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.