[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.
[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.
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.
A client is immediately expected to challenge the FTPS server with a TLS ClientHello message.
[5] This allowed administrators to retain legacy-compatible services on the original 21/TCP FTP control channel.
In the later versions of the document, FTPS compliance required that clients always negotiate using the AUTH TLS method.
Explicit mode differs in that the client has full control over what areas of the connection are to be encrypted.
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.