User:Dinjiin/Sandbox/FTPS
From Wikipedia, the free encyclopedia
FTPS (also known as FTP Secure and FTP-SSL) is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and the Secure Sockets Layer (SSL) cryptographic protocols.
FTPS should not be confused with the SSH File Transfer Protocol (SFTP), an incompatible secure file transfer subsystem for the Secure Shell (SSH) protocol. It is also different from Secure FTP, the practice of tunneling FTP through an SSH connection.
Contents |
[edit] Background
The File Transfer Protocol was drafted in 1971 [1] for use with the scientific and research network, ARPANET. Access to the ARPANET during this time was limited to a small number of military sites and universities, negating the need for data security or privacy requirements within the protocol.
As the ARPANET gave way to the Internet, data began to traverse increasingly longer paths from client to server. The opportunity for unauthorized third parties to eavesdrop on data transmissions proportionally increased. Some limited efforts were made with other protocols to thwart this behavior, such as Base64 encoding of authentication data within the Hypertext Transfer Protocol (HTTP). [2]
In 1994, the Internet browser company Netscape developed and released the application layer wrapper, Secure Sockets Layer. [3] This protocol enables applications to communicate across a network in a private and secure fashion, discouraging eavesdropping, tampering, and message forgery. While it can 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. [4] An official IANA port was registered shortly thereafter. However, the RFC was not finalized until 2005. [5]
[edit] Methods of Invoking
There are generally two ways for a server to force a client to use TLS or SSL security: Explicit or Implicit.
[edit] Explicit
A set of extensions were added to FTP under RFC-2228, including a mechanism for negotiating authentication and security using the new FTP command AUTH. [6]
The RFC does not explicitly define any required security mechanisms. However, it is assumed that the FTP client will challenge the FTP server with a mutually known mechanism. If the security mechanism is unknown by the FTP server, it will respond to the AUTH command with error code 504 (not supported). Clients can determine which mechanisms are supported by querying the FTP server with the FEAT command, although it should be noted that servers are not necessarily required to be honest in disclosing what levels of security they support.
Common methods of invoking FTPS through negotiation include: AUTH TLS and AUTH SSL. Note that RFC-4217 compliance requires that clients should negotiate using the AUTH TLS method. The RFC also requires compatibility with the draft mechanisms AUTH TLS-C and AUTH TLS-P. [6]
[edit] Implicit
Negotiation is not allowed with implicit FTPS configurations. A client is immediately expected to challenge the FTPS server with a TLS/SSL 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-TLS/SSL aware FTP clients, implicit FTPS is expected to listen on the IANA Well Known Port 990/TCP for the FTPS control channel and 989/TCP for the FTPS data 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.
[edit] TLS/SSL
[edit] 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 (but not limited to) AES, RC4, RC2, Triple DES and DES, and hash functions SHA, MD5, MD4 and MD2.
[edit] Scope of Use
In Implicit Mode, the entire FTPS session is encrypted. However, 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.
[edit] 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.
The FTPS client may exit the secure command channel mode at any time by issuing a CCC (clear control channel) command. It may be reentered again later by issuing another AUTH command.
[edit] Secure Data Channel
The secure data channel can be entered through the issue of the PROT command. It is also 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.
[edit] 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, 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 crippled 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 and/or server resides behind a network firewall or network address translation (NAT) device. (See FTPS#Firewall Incompatibility below)
- Repeated use of AUTH and CCC/CDC commands by anonymous FTP clients within the same session. Such behavior can be utilized as a resource-based denial of service attack as the TLS/SSL session must be regenerated each time, utilizing server processor time.
[edit] Firewall Incompatibility
For later...
[edit] References
- ^ RFC-265: File Transfer Protocol (FTP)
- ^ RFC-1945: Hypertext Transfer Protocol 1.0, Section 11.1 Basic Authentication Scheme
- ^ RFC draft, SSL 2.0 Protocol Specification, revision 1995-02-09
- ^ RFC draft, Secure FTP Over SSL, revision 1996-11-26
- ^ RFC-4217: Securing FTP with TLS
- ^ a b RFC-2228: FTP Security Extensions
