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?
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
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
n00b.
RIP wsmr-simtel20.army.mil
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.
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.
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.
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.
Yes please any good tips here guys? I'm a CLI n00b but I need to connect to servers a lot doing web design. There must be a better wayyyyy.
Yes please any good tips here guys? I'm a CLI n00b but I need to connect to servers a lot doing web design. There must be a better wayyyyy.
There's no reason why you *have* to use a CLI to use FTP. Try Filezilla - it will do FTP, SFTP and FTPS.
What happend when a geek gets drunk???? http://raulitoelfriki.netne.net/modules/comic/comic.php?content_id=72&mode=flat&order=1 Hahaha XD
sendfile forever!
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
good
http://WWW.DOGAMES.NET Dont't Stop Gaming
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.
Thanks for the reply, I wasn't very clear in my post sorry - I use FTP clients already, but was wondering - given all the negative comments about FTP here - if there are better solutions for managing website files I could look into. The CLI thing was alluding to SSHing to the server in mac terminal - which has some nice advantages through linux shell access (e.g. wget-ing big files from the web directly to the server), but which I suck at using in terms of productivity. Anyway, this question would be much better asked in a thread about managing websites, my bad!
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?
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
I'll second that.
The most popular alternative to FTP is WebDAV which is supported by most popular operating systems and web design software. WebDAV is designed to be an alternative to FTP which uses HTTP, so it's interface is pretty similar and just as easy to use (depending on the GUI WebDAV client you use of course).
I have previously used SMB (Windows file sharing) or AppleTalk shares which are incredibly easy to manage. The shares can be mounted as local drives on Windows or MacOS and used just like any other disk on the client system. The main concern of course is that you don't want to expose Windows or AppleTalk shares to the entire internet..but you can easily filter the IP's which can access them via TCP Wrappers (on Linux), Windows Firewall (on Windows Server) or your network firewall.
I'd also like to add that FTP seems to be the best at managing UGO style permissions (short of logging into a shell via SSH), which can also be a big problem when managing web sites...
There are quite a few ways to get files to the server, but most of them have really poor GUI clients or are just really expensive (ie. SharePoint).
The clash of honour calls, to stand when others fall.
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