Slashdot Mirror
FTP Is 40 Years Old
An anonymous reader writes "FTP celebrates its 40th birthday tomorrow. Originally launched as the RFC 114 specification, which was published on 16 April 1971, FTP is arguably even more important today than when it was born. Frank Kenney, vice president of global strategy for US managed file transfer company Ipswitch, said that the protocol we know as FTP today is 'a far cry from when Abhay Bushan, a student at MIT, wrote the original specifications for FTP.' According to Kenney, the standard has grown from 'a simple protocol to copy files over a TCP-based network [to] a sophisticated, integrated model that provides control, visibility, compliance and security in a variety of environments, including the cloud.'"
FTP is a hideous protocol. The client connects to the server with one TCP connection, and then when a file (or directory listing) is requested, the server opens up another TCP connection back to the client. This is a nightmare for firewalls. There is also passive mode where the client initiates the second connection to the server, but it is only slightly less hideous.
As awful as HTTP is, it is infinitely better than FTP. Sadly HTTP is mostly one way, but these days for anything that isn't being broadcast to the public (the web), you are betterm off using ssh/scp.
Let FTP die already.
Do we really need to bring buzzwords like the cloud into this? It's a file transfer protocol, aptly named, for transferring data to another system. It could be in a cloud or in a cave for all I care, as long as it has port 21 open.
I'd instead say "and in internet years, that's about 400 years, and it shows. retire the poor thing already!" It's a royal pain for firewalls and it sends text in the clear. Move into the 21st century and use scp...
The correct name is Abhay Bhushan (not Bushan).
Unless the TFA is talking about SFTP (which it isn't), there is no reason to laud anything positive about FTP. Other than it was a straightforward protocol and it served us well, back in the day.
Now die!
When software gets to be around 40 years of age, wrinkles that were once minor are more and more apparent, what was once new and exciting isn't so much anymore, and it gets rather set in its ways and resistant to change. Decisions made in its youth often become a cause of later regret, and there's a certain amount of jealously of those who are now doing the same job it once did but in a snazzier way.
But at the same time, it's likely to be far more established and dependable than its younger counterparts. You can count on it getting the job done, one way or another. It won't be flashy, but it will work.
I am officially gone from
Asking the vice president of global strategy of a company built around its FTP client to comment on the relevance of FTP is a bit like asking an Adobe marketing executive about the importance of Flash, no?
FTP stood for freaking tricky protocol because it did so much 'wonderful' stuff for me downloading pron.
that the grand FTP sites like Walnut Creek didn't last this long. RIP cdrom.com, RIP gamehead, RIP happypuppy, RIP filefactory, RIP gamesdomain, and RIP sunet.se (they closed off their games sections)
If only there had been archiving attempts on FTP sites like those... not cheap port 80 http copies!
According to Kenney, the standard has grown from 'a simple protocol to copy files over a TCP-based network [to] a sophisticated, integrated model that provides control, visibility, compliance and security in a variety of environments, including the cloud.
Actually, FTP predates TCP by 10 years and 679 RFCs. Hint: TCP is defined in RFC 793.
Ask Slashdot: Where bad ideas meet poor googling skills.
Kermit is the way to go.
ftp was great in it's day. But it's insecure and outdated now and better protocols exist. For system administrators it is a pain to manage with plain text passwords etc. It should be consigned to the history books for better replacements like scp or sftp etc
Not Intented To Be A Factual Statement
IHFTP
Not everything needs to be secure; every OS has an FTP client built-in, and FTP works with minimal overhead. It's just one tool to do a job.
There was a very small number of systems on the ARPA netwok, we were trying to build simple and workable connections between different architectures (8,12,16,32,36 bit hardware). Also many differnent operating systems. FTP, Telnet, RJE, Mail etc were all buit with a very differnt trust model than today. As mentioned it was NCP as the basic transport protocal not TCP/IP. FTP as used was from RFC 542, the RFC mentioned here predated and was first attempt to discuss it. 542 was work of a committee that had folks from many sites with different architectures (system and hardware). There was an assumption of trust and an end to end connection model. The concept of 'internet' was much later. TCP/IP was much later. In many ways a much nicer/simpler world.
I wonder when the first technical breach of copyright happened over FTP... How many hours/days after the prototype application(s) was born do you think more than fair use passed over the first FTP connections?
I'd say we've probably got the 40th birthday of Internet Piracy some time this year, anyhow. =)
FTP died in 1993, murdered by httpd and the Mosaic browser. I watched it die. I shed no tears.
command line FTP is my favorite now that I am out of IT.
but I need to say SFTP is the only option in today's world of HIPAA and net neutrality. FTP-SSL, still, is just another layer over the already ubiquitous FTP.
Yes, SFTP is yet another wrapper against FTP, but it is much more secure compared to FTP over SSL. SSL only offers limited encryption options. SFTP, on the other hand, can encrypt data flowing over public keys with encryption streams 1024-bit or higher.
The FTP we know today originated in RFC 765, published June 1980, and was designed to work over TCP. RFC 114 defines a completely different protocol for file transfer that has nothing to do with FTP.
The only nonsucky thing about FTP is that you can use FXP to transfer files between two remote servers without piping it through your client. For example, suppose you have FTP logins on two servers and each has a nice, fast Internet connection. You are on dialup and need to copy database backups from one server to the other. You can use FTP to tell the first to upload to the second's IP address, and tell the second to recv a file from the first's IP address. Nothing but the status messages go through your poor local modem.
You can do the same with by ssh'ing to the first server and scp'ing a file from it to the second, but that requires generating keypairs and copying the public keys around. If you're nitpicky about having separate keypairs on each SSH client machines (and you really should be!), and you have 20 hosts, then you'd have to copy 19 public keys to each machine. With FTP+FXP, you need an FTP login on each of the hosts. That's especially nice if the sending server is a public repository where you don't have anything but anonymous FTP access.
This isn't exactly a killer feature for most people, but it's kind of slick if you ever actually need it.
Dewey, what part of this looks like authorities should be involved?
As recently as 5 years ago, I set up an FTP server for use by a number of financial firms to send orders into a specialized stock trading system
$100M worth of orders were FTPed into that system using PGP encrypted text files (with public key fingerprints verified via telephone to make sure that all of the keys were valid). IP filtering was used to give a small additional layer of security.
This system was set up in a short period of time (3 weeks from inception including writing the file spec and setting up the servers) and FTP was the one thing that all parties could count on having (client operating systems included Windows, various flavors of Unix, IBM VM, and I think one customer had Tandem Nonstop). Pushing files via HTTP PUT is possible, but it's a lot easier to script an FTP file transfer.
What are some alternatives to FTP that are fast and non CPU-intenstive (i.e. no encryption)?
After 40 years the protocol is known well enough that developers can make it work on just about any system that needs file transfer. Its not exactly the fastest method, but I can transfer media from my PC to my PS3. I wouldnt be surprised if a few of the file transfer software packages for media players use some implementation of FTP.
Get a life, STFU. FTP just works. Do you hate that? If you have something truly better, it will replace FTP. Otherwise...
Slow new day?
With ftp I can download whole folders with boatloads of files and more folders, and the rest my network stay up just fine. Transfer speeds are top notch. It lets other traffic through.. Bittorrent? I might put it on when I crash for the night.
ftp through a nice private tunnel.. hasn't failed me yet..
For justice, we must go to Don Corleone
FTP ... provides ... security ...
I viewed the conversation on this topic mostly to see the revulsion at that series of words. There isn't enough. I would be pissed to see that statement anywhere, and probably mention something about fact-checking. It's on the front page of slashdot. There's no way timothy didn't look at it, recognize that it is a bald faced lie and that everyone here would know it, and endorse it anyway. What the hell?
FTP hasn't evolved. It's been replaced. As others have pointed out, there's https for the masses, and sftp for the ssh-inclined. There's bit torrent for efficiently distributing load. If you want to talk about history, great. If you want to claim that FTP is a good protocol today, I disagree. If you want to tell me that it's secure, you can just get fucked.
Here's a little more background on the various generations of the FTP protocol.
First Generation (1971-1980)
The original specification for FTP (RFC 114) was published in 1971 by Abhay Bhushan of MIT. This standard introduced down many concepts and conventions that survive to this day including: ASCII vs. "binary" transfers, Username authentication (passwords were "elaborate" and "not suggested" at this stage) , "Retrieve", "Store", "Append", "Delete" and "Rename" commands, Partial and resumable file transfer , A protocol "designed to be extendable", Two separate channels: one for "control information", the other for "data", and Unresolved character translation and blocking factor issues
Second Generation (1980-1997)
The second generation of FTP (RFC 765) was rolled out in 1980 by Jon Postel of ITI. This standard retired RFC 114 and introduced more concepts and conventions that survive to this day, including: A formal architecture for separate client/server functions and two separate channels, Site-to-site transfers, Passive (a.k.a. "firewall friendly") transfer mode and The 3-digits-followed-by-text command response convention. ...and RFC 765 was replaced by RFC 959 (which formalized directory navigation) in 1985.
Third Generation (1997-current)
The third and current generation of FTP was a reaction to two technologies that RFC 959 did not address: SSL/TLS and IPv6.
Most FTP software now conforms to RFC 2228 for FTPS. Oddly enough, there are still a LOT of file transfer packages that still don't have IPv6 or EPSV support. The RFCs beyond IPv6 and EPSV support are pretty well baked, so if you're still dealing with a vendor without those attributes, consider that a big red flag.
Also keep an eye on draft-ietf-ftpext2-hash and draft-peterson-streamlined-ftp-command-extensions - that's where the action is in FTP today.
Probably try to hook up with some younger protocol - FTP over IPv6 anyone?
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam.
One thing about ftp that's not mentioned is that back in the old days, before the WWW, ftp was used by warezers to trade warez by ftp'ing into legitimate businesses ftp sites, looking for a world-writable folder, and then hiding their stuff by using folder names with weird characters. Sometimes /pub would be writable so there would be a folder ".. " or something even more obscure, ".. / /warez/appz/". There was even a special client called WarezFTP that made this easier to change directory into these folders. This would usually be done in weekends, and the addresses given out in IRC chat channels. I guess the business would get an unpleasant surprise if they had to pay for their traffic.
What happend when a geek gets drunk???? http://raulitoelfriki.netne.net/modules/comic/comic.php?content_id=72&mode=flat&order=1 Hahaha XD
sftp is also generally a lot slower than ftp/ftps..recently there've been some patches to openssh to fix this but it breaks unpatched clients/servers last I heard.
sendfile forever!
Also keep an eye on draft-ietf-ftpext2-hash and draft-peterson-streamlined-ftp-command-extensions - that's where the action is in FTP today.jordan shoes,air max 90,air max 95,nike shox nz,nike shox r4,wholesale world brand shoes
I saw a new Y2K bug in a released and shipped commercial product in 2008 (Macrovision Flexlm) - now so long as programmers are that incredibly stupid you can't trust that their software is robust enough to handle odd stuff from outside.
People were saying what you were twenty years ago but we still have these incredibly fragile systems that need adult supervision between them and the internet.
I still need to toss files from a bunch of servers down to an ancient, though quite functional Open VMS Alpha server... so long as legacy systems exist, legacy software will live on. Just keep the latest RFC handy.
Lurchicus - For Sig, see other side.
That just made me rofl
So there you whippersnappers!
good
http://WWW.DOGAMES.NET Dont't Stop Gaming
uucp, WAIS, gopher have absolutely nothing to do with FTP.
uucp is not a file transfer protocol. It is a point-to-point telephone network convention using straight tty connections over a modem.
WAIS was not a file transfer protocol either - It was/is a wide area information search protocol layered on a simple TCP connection.
gopher was the precursor to HTTP, but was not designed for file transfer, but short information retrieval. The only error recovery involved was that included in TCP. The origins of the gopher protocol was E-mail, simplified.
FTP was a file transfer protocol, designed to allow the user to have control over the data as the data was passed, hence, had a data channel and a command channel. This allows for asynchronous commands to be issued while the data is being transferred. Updates to the applications (client and server) allowed for restarts, multiple file transfer, compressed data transfer... The only updates to the protocol that I know of were the use of variable sized TCP fames, and stall recovery.
How appropriate
FTP providing compliance? To what end - not functioning correctly through firewalls, is ensuring compliance with preventing data leakage from internal networks?
I still use it daily to wirelessly move files between my computers at home, while my clueless friends (among them programmers and IT assistence guys) carry USB sticks around the house. Lamers.
Knowledge is power; knowledge shared is power lost.
ftps wraps up all the issues with firewalling FTP, and makes them 1000 times worse, by adding encryption. You still have two connections, you still have pseudo-random ports that are such a joy to firewall & load balancer admin's every where, and you pile the joy of encrypting the port number so that you have to terminate the SSL session at each intervening firewall. Pure, unadulterated joy if you sell cpus for routers. Take a 10 foot pole, and gingerly push FTPS away... It is a really bad idea. secsh ftp (what is more often called SFTP, but confusingly was the original name used for ftps) is the way to go. I don't get why they don't adopt the RFC already, it's been an expired draft for nearly five years!
ASCII was the correct decision at the time, and it is still occasionally useful today. For example, At work, we send and or post a lot of data, to a lot of different clients. The following has happenned twice now:
so yeah, it was corrupt.
Note that this would also corrupt text being sent to windows boxes, who would expect a <CR> before the <LF> on text files. It's happenned twice, because five years later when we went from Redhat 7 fo Debian Etch, the tweak got lost, had to figure it out again.
seems that with FTP servers being so fragmented and being able to search against them being almost impossible, ive come across a few sites that have attempted in collaborating ftp servers across the internet, couple worth noting are: www.filefrisk.com www.filewatcher.com
SFTP is fundamentally and intimately tied to the SSH protocol which is rather maddening if you do not trust your clients. You can offer SFTP access without SSH access to someone, but it involves getting all the settings right (make sure you do not allow port forwardings!). It is not so bad if you can throw an extra IP + an extra chroot'ed (or virtualized/jailed) SSH daemon at the problem, but without that, you need to get the settings right for each individual user.
Give me HTTPS WebDAV any day with its readable configuration files and fine-grained permissions.
Finally! A year of moderation! Ready for 2019?
Or just run sftp from your ftp server, instead of your ssh server.
Proftpd, for example, can do sftp, using exactly the same users and paths you set up for the FTP part of it. (Which you can, if you wish, turn off.) I suspect other ftp servers can do the same.
And you don't need another IP...what you do is you put file transfer on port 22, and then you move normal ssh to another IP.
If you're using virtual FTP users, like I use of the form user@example.com for FTP access which si used for websites, this is better for security anyway. Morons with dictionary attacks won't even come close.
Everyone who has actual ssh access will need to use port 122 or wherever you moved ssh to, but anyone who is granted command access to the server should know how to change the port in their client! And people who just have file copy access just click 'SFTP' and it works.
I'm not saying it's easier than WebDAV, just that using your existing ssh setup for sftp is not the best plan. Use your existing ftp setup instead.
If corporations are people, aren't stockholders guilty of slavery?
FTP was great, and 20 years ago it was the way to move things around. It's dead now, and this anonymous submission smells to me like ipswitch astroturfing to try to sell a copy or two of what I think is a pretty crappy FTP server.
Our billing mailer (as in third party company that prints and mails bills for us) decided to install the ipswitch FTP server and we discovered that we couldn't get our Linux secure FTP stuff to connect to it to send them big print jobs. The IT guy at the printer had no clue about key exchange or what public keys were, etc, and a few packet traces made it look like ipswitch server was misconfigured. In the course of trying to learn enough about it to tell them how to configure it, I downloaded and installed a demo of their FTP server. Yuck.
Instead of an executable that knew how to install itself, as one would expect with software intended for use in enterprise environments, this thing required .NET 2.0 and the ms install stuff, so I had to download and install that gunk first. Then it needed MySQL or PostGres to be installed. Why would an FTP server require an SQL database, you ask? Well, to store the usernames and passwords of your FTP users, to store the public keys of the secure FTP clients that would be connecting to it, and apparently to store its configuration and whatever other flotsam it needs while it's running. Why use a disk file or two, or even the Windows registry when you can go maximum bloat, requiring an SQL server and 60 local TCP connections before a single client has even connected? Finally, it required manual insertion of public keys before even attempting to negotiate a connection, since it was unable to record it from an initial key exchange. After getting the key configuration sorted out, packet captures of the connection attempts revealed a bug in their negotiation stuff that prevented them from accepting a connection, but I don't remember exactly what it was. There were posts on their support forums from other Linux shops that were having no joy with it. After that huge waste of time, the printer backed off Ipswitch and then a few months later, they must've gotten a fix from Ipswitch for the negotiation problem because they tried again and all we had to do was show them how to get our client's public key installed to transfer a file to them. In any event, if your PHB reads this slashdot article and gets all nostalgic and tells you to find a windows box and put the ipswitch server on it, it will hopefully take less than a few months to get it to work with your clients.
It has more clouds.
be sure to check out the new FTP Working Group at the IETF if you're involved in FTP implementations.
we're working on new and old extensions like a HASH and RANGe command, and HOST.
just join up on the mailing list!
http://tools.ietf.org/wg/ftpext2/
https://www.ietf.org/mailman/listinfo/ftpext
When I rebuilt our public access server, one of the changes was to remove FTP in lieu of SFTP (ssh) access only.
You can still sit in any public Wifi area and scoop up FTP passwords.
set login shell to /usr/lib/sftp-server.
or..
http://www.minstrel.org.uk/papers/sftp/builtin/
simpler than ftp...
I was a 14 year old working at UCLA part time writing code to transfer brain computer interface data from the Xerox 7929 to the Sigma 7 (Network Measurement Center arpa host #1) and then on to the CCN (UCLA Campus Computing Network 360 95's for FFA. In those early days I was just amazed about compiling a program in california and sending the object file to Virginia and the printout to Massachusetts. I was trying to tell my junior high school friends about the arpa network and what it could do, and I was thought weird because I was interested in such things. I guess that means that it is also the 40th birthday of the meditation on computer communication that has been going on in my brain ever since. I thought the net was the most amazing thing when it was comprise of leased line links at 2400 baud. Jon Postel was always hiding in his office implementing the latest NCP spec. MIT was trying hard to keep me from playing chess in the daytime. And FTP services were politely restricted to night-time, if you were polite. It is not important that it was a good protocol or not. It was a protocol, and got us thinking about writing services.
The only reason ftp is sill alive is that Microsoft for some reason refuses to ship anything else for file transfers across the Internet. I have repeatedly tried to use webdav og sftp but it is not possible when, especially Windows server, does not ship with any alternative to ftp "out-of-the-box". When working on a customers server its not always possible to install all kinds of software just to transfer some files. Webdav via https is great, but Microsoft has never been able (or has never been willing to) deliver a simple client for it, across all platforms. When using konquerer with kioslaves the only thing needed to connect to webdav is to write wedav(s):// in the adress bar. Compare that to the idiotically complicated wizard in windows make me laugh (eehh.. rage mostly :-) ). I don’t even know if it is possible to use webdav from winserver 2008, in w2k3 you had to install a lot of bullshit librarys from office, and still it was mostly broken.
Brian Simonsen