File Transfer Protocol
File Transfer Protocol
History
The original specification for the File Transfer Protocol was written by Abhay
Bhushan and published as RFC 114 on 16 April 1971, before TCP and IP even
existed.[2] It was and later replaced by RFC 765 (June 1980) and RFC 959 (October
1985), the current specification.[2] Several proposed standards amend RFC 959, for
example RFC 2228 (June 1997) proposes security extensions and RFC 2428
(September 1998) adds support for IPv6 and defines a new type of passive mode.[4]
for storing file>).[1] A file transfer in progress over the data connection can be aborted
using an interrupt message sent over the control connection.
FTP can be run in active or passive mode, which determine how the data connection
is established.[7] In active mode, the client sends the server the IP address and port
number on which the client will listen, and the server initiates the TCP connection.[6]
In situations where the client is behind a firewall and unable to accept incoming TCP
connections, passive mode may be used. In this mode the client sends a PASV
command to the server and receives an IP address and port number in return.[6][7] The
client uses these to open the data connection to the server.[5] Both modes were updated
in September 1998 to add support for IPv6. Other changes were made to passive
mode at that time, making it extended passive mode.[9]
While transferring data over the network, four data representations can be used:[2][3][4]
ASCII mode: used for text. Data is converted, if needed, from the sending
host's character representation to "8-bit ASCII" before transmission, and
(again, if necessary) to the receiving host's character representation. As a
consequence, this mode is inappropriate for files that contain data other than
plain text.
Image mode (commonly called Binary mode): the sending machine sends each
file byte for byte, and the recipient stores the bytestream as it receives it.
(Image mode support has been recommended for all implementations of FTP).
EBCDIC mode: use for plain text between hosts using the EBCDIC character
set. This mode is otherwise like ASCII mode.
Local mode: Allows two computers with identical setups to send data in a
proprietary format without the need to convert it to ASCII
For text files, different format control and record structure options are provided.
These features were designed to facilitate files containing Telnet or ASA formatting.
Data transfer can be done in any of three modes:[1][2]
Stream mode: Data is sent as a continuous stream, relieving FTP from doing
any processing. Rather, all processing is left up to TCP. No End-of-file
indicator is needed, unless the data is divided into records.
Block mode: FTP breaks the data into several blocks (block header, byte
count, and data field) and then passes it on to TCP.[4]
Compressed mode: Data is compressed using a single algorithm (usually runlength encoding).
[edit] Login
FTP login utilizes a normal username/password scheme for granting access.[2] The
username is sent to the server using the USER command, and the password is sent
using the PASS command.[2] If the information provided by the client is accepted by
the server, the server will send a greeting to the client and the session will be open.[2]
If the server supports it, users may log in without providing login credentials. The
server will also limit access for that session based on what the user is authorized.[2]
[edit] Security
FTP was not designed to be a secure protocolespecially by today's standardsand
has many security weaknesses.[10] In May 1999, the authors of RFC 2577 enumerated
the following flaws:[11]
Bounce attacks
Spoof attacks
Brute force attacks
Packet capture (sniffing)
Username protection
Port stealing
FTP was not designed to encrypt its traffic; all transmissions are in clear text, and user
names, passwords, commands and data can be easily read by anyone able to perform
packet capture (sniffing) on the network.[2][10] This problem is common to many
Internet Protocol specifications (such as SMTP, Telnet, POP and IMAP) designed
prior to the creation of encryption mechanisms such as TLS or SSL.[4] A common
solution to this problem is use of the "secure", TLS-protected versions of the insecure
protocols (e.g. FTPS for FTP, TelnetS for Telnet, etc.) or selection of a different, more
secure protocol that can handle the job, such as the SFTP/SCP tools included with
most implementations of the Secure Shell protocol.
directories interactively or to modify commands, and there can also be problems with
large file attachments in the response not getting through mail servers. The service
was used when some users' only internet access was via email through gateways such
as a BBS or online service. As most internet users these days have ready access to
FTP, this procedure is no longer in everyday use.
or:
ftp://user001:secretpassword@private.ftpservers.example.com/mydirectory/myfile.txt
More details on specifying a user name and password may be found in the browsers'
documentation, such as, for example, Firefox [15] and Internet Explorer[16].
By default, most web browsers use passive (PASV) mode, which more easily
traverses end-user firewalls.
[edit] SFTP
SFTP, the "SSH File Transfer Protocol," is not related to FTP except that it also
transfers files and has a similar command set for users.
SFTP, or secure FTP, is a program that uses SSH to transfer files. Unlike standard
FTP, it encrypts both commands and data, preventing passwords and sensitive
information from being transmitted in the clear over the network. It is functionally
similar to FTP, but because it uses a different protocol, you can't use a standard FTP
client to talk to an SFTP server, nor can you connect to an FTP server with a client
that supports only SFTP.
transferring files using SSH that are not related to FTP include SFTP and SCP; in
each of these, the entire conversation (credentials and data) is always protected by the
SSH protocol.
RFC
RFC
2228
ALLO
APPE
AUTH
CCC
RFC
2228
RFC
2228
EPRT
EPSV
FEAT
LANG
LPSV
MDTM
MIC
RFC
2228
RFC
2428
RFC
2428
RFC
2389
RFC
2640
LIST
LPRT
Authentication/Security Mechanism
CWD
DELE
ENC
Authentication/Security Data
Allocate sufficient disk space to receive a file.
Append.
CDUP
CONF
Description
Abort an active file transfer.
Account information.
RFC
1639
RFC
1639
RFC
3659
RFC
2228
MKD
MLSD
MLST
Make directory.
RFC
3659
RFC
3659
MODE
NLST
NOOP
OPTS
RFC
2389
PASS
PASV
PBSZ
RFC
2228
RFC
2228
QUIT
REIN
REST
RETR
RMD
RNFR
RNTO
SITE
SMNT
STAT
STOR
STOU
STRU
SYST
TYPE
USER
PWD
SIZE
Authentication password.
Enter passive mode.
PORT
PROT
RFC
3659
The first digit of the reply code is used to indicate one of three possible outcomes, 1)
success, 2) failure, and 3) error or incomplete:
The third digit of the reply code is used to provide additional detail for each of the
categories defined by the second digit.