On Thu, 4 Aug 2005 22:56:44 +0300, "Chad Z. Hower aka Kudzu"
<cp**@hower.org> wrote:
J. Peter Mugaas <om******@mail.wvnet.edu> wrote in news:MPG.1d5c27d02eb240b7989682
@msnews.microsoft.com: all. In fact, sometimes, I think that FTP is a good leason in how NOT
to write a protocol.
FTP isnt bad. If you want an example of a horrible protocol, look at IMAP4.
Note that I'm saying this not for your benefit but for the benefit of
our listening audience.
FTP does have it's own pitfalls that really bite.
1) There is no original directory listing format so parsing the output
is always going to be a problem that can never be solved. Even dates
are not as reliable as you think because you don't know what time zone
are dealing with.
2) There is a separate data channel. During transmissions, the
control channel is idle and unfortunately, a firewall might cut an
idle connection. I suspect that's what our original poster complained
about.
3) To establish a data channel, an IP address is specified along with
a port. That means that someone could use a FTP server to access an
internal network or transmit a specially crafted file as part of an
attack against someone else. Another problem is that some
workstations are in internal networks and those have special
designated addresses that don't make any sense on the Internet (in
fact, a lot of routers will drop packets with those internal network
IP addresses. Usually, NAT's can change those IP addresses but in FTP
with SSL, that's impossible. In IPv6, a special command had to be
introduced because the standard PORT and PASV commands can't
communicate an IPv6 address.
4) There is no standardized way to modify some attributes of a file
such as permissions, ownership, and time stamps. SITE commands have
been used but there's no standardized SITE commands at all.
Unfortunately, the MFF draft doesn't seem to be adopted widely and
attempts to solve that problem.
5) In PASV transfers the server listens on a specific port and the
client connects to that port. That makes it easy for someone else to
hijack that data connection.
6) During a data transfer, in order to abort, you have to a special
command and that's not always implemented correctly by FTP servers. To
implement the abort command correctly involves quite some complexity.
SFTP (SSH file transfer) is better because you send data in block
sizes and to abort, you simply stop requesting those blocks. 7) In FTP
PASV transfers, the server has to connect to the client from a port in
the reserved port range (1-1024). That makes it impossible for the
server to completely give up administrative privileges after the
initial bind.
I'm sure that I can go on quite bit about this stuff and I admit that
some of the problems are worked around to some extent. If anything,
FTP has probably provided a good lesson that the writers of FSP
(
http://fsp.sf.net) and the SSH file transfer subsystem have learned
from.