FTPS


From Wikipedia, the free encyclopedia




Jump to: navigation, search



This article is about FTP over SSL. For FTP Software, the defunct network software company, see FTP Software.



FTPS (also known as FTP-ES, 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 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


 [hide] 




Background

The File Transfer Protocol was drafted in 1971 for use with the scientific and research network, ARPANET.[1]

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: Explicit or Implicit. The explicit method is a legacy compatible implementation where FTPS-aware clients can invoke security with an FTPS-aware server without breaking overall FTP functionality with non-FTPS-aware clients. The implicit method requires that all clients of the FTPS server be aware that SSL is to be used on the session, and thus is incompatible with non-FTPS-aware clients.

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 unsecure mode or refuse/limit 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.

In the later RFC 4217, FTPS compliance required that clients always negotiate using the AUTH TLS method. The RFC also recommended FTPS servers to accept the draft mechanism AUTH TLS-C.

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 was expected to listen on the IANA Well Known Port 990/TCP for the FTPS control channel, and to 989/TCP for the FTPS data channel. 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.

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



Main article: Transport Layer Security



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. 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.

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, 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 and/or server resides 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 utilized as a resource-based denial of service attack as the TLS/SSL session must be regenerated each time, utilizing server processor time.

SSL certificates

Much like HTTPS, but unlike SFTP, FTPS servers may provide a public key certificate. These certificates can be created using Unix tools such as OpenSSL's ssl-ca.

This certificate should be signed by a certificate authority, or the FTPS client may generate a warning stating that the certificate is not valid.

Firewall incompatibilities

Because FTP utilizes 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



Cryptography portal



Notes



  1. ^ RFC-265: File Transfer Protocol (FTP)
  2. ^ The SSL Protocol, Feb. 9th, 1995
  3. ^ RFC draft, Secure FTP Over SSL, revision 1996-11-26
  4. ^ RFC-4217: Securing FTP with TLS



External links


==============

http://explorer.iteye.com/blog/391627

基于FTP/SSL的开发，推荐使用Indy组件。ICS 也开始全面支持SSL(v5 v6 v7)，也免费开源， 也是候选方案，以前我用ics v5的ssl的相关支持还要收费呢。 Indy的优势在于开发组人马众多、版本更新快，对于不同FTP server 返回的LIST格式的支持比较全面。 

    Indy10开始全面支持SSL，对于FTP/SSL的应用，以客户端为例：只需要新加一个 TIdSSLIOHandlerSocketBase 组件，再将TIdFTP组件的 IOHandler指向它，设置IdFTP组件的 UseTLS、 DataPortProtection 即可。

UseTLS 属性决定了客户端连接服务器的模式:

  • utNoTLSSupport－ 根本不使用TLS
  • utUseImplicitTLS－ 隐式TLS(implicitTLS) 。通常这种模式下，客户端连接到990端口，建立TLS会话，整个会话都是加密的。但是IETF 已经废弃了对ImplicitTLS的支持，所以一般情况下这种设置只是用来连接那些还不支持explicitTLS的ftp服务器。
  • utUseRequireTLS－ 强制显式TLS。这种模式下，客户端像普通ftp会话一样，以非加密方式连接到21端口，ftp服务器给你一个hello信息，然后你发出一个特殊TLS命令(AUTH TLS, AUTH SSL, AUTH TLS-P 或 AUTH TLS-C)开始建立TLS会话，其后再进行ftp USER PASS 认证过程，整个会话保持加密状态持续到结束或你发出一个重初始化命令(REIN)。 如果TLS会话建立不成功，后面的ftp会话就自动断开了，无法继续。
  • utUseExplicitTLS－显式TLS(explicitTLS)。这种模式类似上面的 utUseRequireTLS，只是如果TLS会话建立不成功，仍然可以继续传统的非加密FTP会话。 这种模式可以保证最大的兼容性。

所谓隐式TLS/显式TLS,区别主要在是否独立开监听端口上。

隐式TLS的实现，都是要求服务器单独listen一个特殊端口，客户端连接后直接建立SSL会话，然后再进行应用协议的command，整个过程都是加密的；而显式TLS的实现，是在原应用协议的基础上改进，增加了TLS认证的command，并且server不占用单独的端口。
以FTP/SSL为例：
隐式TLS－服务器在990端口监听，客户端建立TCP连接，然后建立SSL连接，然后进行USER PASS的ftp 认证。 其间是没有 AUTH TLS这种特殊command的。
显式TLS－服务器仍然在21端口监听，客户端正常发起tcp连接、服务器返回hello、客户端发起AUTH TLS－至此建立了TLS认证，以后才是加密状态。如果服务器设置了必须使用TLS，则当server hello后，客户端试图不建立SSL连接而直接进行USER PASS的ftp认证，服务器会踢掉客户端。

 

简而言之：
隐式TLS－干脆利落，服务器listen一个单独端口，上来就直接SSL加密，然后才建立应用层会话。
显式TLS－保持最大的兼容性，还是混在原来的端口，只是应用层会话一旦建立，就用特殊的命令来建立SSL会话。


另：
1.  按Indy的官方说法， Indy8、9 无法支持ftp on SSL的应用，因为老版本缺乏支持ftp on ssl 某些关键特性：比如提供了PORT PASV的加密&不加密数据传输通道及开始explicit TLS会话的命令。 (原话是这样的：In Indy 8.0 and Indy 9.0, you can not do this.  The File Transfer Protocol requires some extensions that those Indy versions do not support them.  The extensions provide encrypted or clear PORT and PASV data channels plus provide a command for starting negotiation with explicit TLS.  )

2.  SSL加密的ftp连接，最好只使用 PASV模式。 因为客户端的NAT无法识别加密后的客户端发出的PORT 命令中的ip地址，它就无法翻译成NAT内的地址