Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

Happy 50th Birthday FTP (filestash.app) 97

Posted by EditorDavid from the Nixon-administration dept.
FTP (file transfer protocol) celebrated its 50th anniversary this week. Long-time Slashdot reader sandbagger shares an article commemorating a half-century of FTP: Over the years, the FTP protocol got refined with 16 different revisions(*1) adding support with TCP/IP, a secure extension also known as FTPS which is leveraging the same tech as HTTPS and more recent addition like IPv6 support.

Fifty years after its inception, FTP is still going very strong with millions of FTP server still being exposed on the internet which is fairly amazing considering the bad press it gets...
This discussion has been archived. No new comments can be posted.

Happy 50th Birthday FTP More

Happy 50th Birthday FTP

Comments Filter:

  • Wow (Score:4, Funny)

    by Carewolf ( 581105 ) on Saturday April 17, 2021 @04:48PM (#61284828) Homepage

    I thought you were dead old man. Happy Birthday

    • But just in time [appleinsider.com]!

    • Re: (Score:3)

      by Z00L00K ( 682162 )

      For some reason the FTP protocol is there because it's supported on almost every platform out there.

      It's often a "last resort" when no other alternative works.

      • As is TFTP for firmware upgrades. If all else fails and you can't get to the web interface, or there isn't one to begin with, TFTP will let you recover your bricked device.

        • Think of these protocols as the Serial port of networking. Sure you have all these fast and fancy interconnect these days but almost every single device has a JTAG port that speaks serial

      • Re: (Score:2)

        by rduke15 ( 721841 )

        It's not only because it works on every platform. It's also sometimes the best solution, particularly for huge files or directories. If you need to transfer a 150 GB. file over an unreliable link, FTP is the only protocol that will work. Even if the link breaks at 99% in the transfer, you can resume the transfer.

      • Or the first resort.

  • Miss the days of running WAR Ftp on my 1.5mbit adsl ine and sharing music with others and having others upload music to your server you never heard of :)

  • Firefox (Score:5, Informative)

    by geantvert ( 996616 ) on Saturday April 17, 2021 @05:06PM (#61284876)

    FTP support was recently removed from Firefox nightly and it will soon be officially removed in Firefox 90.
    https://blog.mozilla.org/addon... [mozilla.org]

    • Re: (Score:1)

      by Anonymous Coward
      Firefox is considerably younger than the FTP protocol.

    • No surprise there. Chrome did it already and Firefox always has to copy Chrome.

    • Did they drop FTPS, which is _not_ the same thing as SFTP ?

    • Thank god. FTP in the browser was a kludge, never properly implemented, didn't support most of what the protocol offered, and nothing more than a workaround for poor HTTP reliability.

      • It's relatively irrelevant now, because it's rarely used along with HTTP any more; the primary use case for FTP seems to be to support downloads to or from antiquated and/or limited hardware. But I still feel something is lost when your browser can't embed an IMG from a FTP site...

        • But I still feel something is lost when your browser can't embed an IMG from a FTP site...

          *shudders* some things are worth losing.

        • "Enter username and password"
          "Enter username and password"
          "Enter username and password"...

          Images on websites should be http~ and nothing else.

  • Anyone who misses FTP can just use SIP (Score:4, Insightful)

    by Arnonyrnous Covvard ( 7286638 ) on Saturday April 17, 2021 @05:15PM (#61284894)
    Same stupid protocol design with in-band addresses and port numbers. It was an understandable mistake in the early days of the Internet, when firewalls seemed unnecessary. In 1996, it was just crazy.

    • Same stupid protocol design with in-band addresses and port numbers. It was an understandable mistake in the early days of the Internet, when firewalls seemed unnecessary. In 1996, it was just crazy.

      There is some legitimate value in separate signaling and data paths in communications protocols.

      The best example I have of this is decoupled signaling useful in prime data paths between peers sitting behind a NAT/SPI so that they can directly communicate. This improves latency and massively reduces operating costs. For example imagine a WebRTC rendezvous site that facilitate say a few hundred thousand concurrent video conferencing sessions. Such a site could easily be operated from a single server with m

      • Re: Anyone who misses FTP can just use SIP (Score:4, Interesting)

        by Z00L00K ( 682162 ) on Saturday April 17, 2021 @09:59PM (#61285352) Homepage Journal

        In the case of SIP then you also have the random assignment of data channels that really makes it miserable. Open a range of UDP ports in case one or two will be used.

        • Re: (Score:2)

          by Zarhan ( 415465 )

          Yes, but that range can be very small. Actually, you technically only need 2 ports per concurrent call for each client (one for RTP, other for RTCP). However, typical systems use a range of 10-20 ports in case you have multiple sessions going or different types of media (e.g. one stream for audio, another for video, third for screen sharing). E.g. MS Teams uses ports 50000-50019.

          Of course, some legacy systems use insane ranges like 16384-32767...

        • The amount of ports open does not really matter.
          A firewall basically only makes sense of it blocks ports that are actually in use from outside access.
          As long as no (buggy) software is listening on a port: there is no way to attack the machine.

          The only slight different (use) case is: your machine is already compromised, some illicit software is listening on a port, and you want your router in front of it not to forward to such a potential malware.

          • As long as no (buggy) software is listening on a port: there is no way to attack the machine.

            Unless there's a hole in the network stack itself.

            This is relatively rare, but you might as well protect against it anyway.

            • This is relatively rare, but you might as well protect against it anyway.
              Which means you have to trust the network stack of the firewall computer/router.
              But that obviously makes it extremely hard to attack the machine behind it (considering your example of a vulnerable network stack).

    • Same stupid protocol design with in-band addresses and port numbers. It was an understandable mistake in the early days of the Internet, when firewalls seemed unnecessary. In 1996, it was just crazy.

      "Misses" FTP? Approximately every hosting company still provides it.

    • Re:Anyone who misses FTP can just use SIP (Score:4, Informative)

      by Zarhan ( 415465 ) on Sunday April 18, 2021 @02:20AM (#61285622)

      The difference is that with FTP, the use case where you transferred files completely remotely (from one FTP server to another, without the file coming to the client at all) is remotely rare.

      With SIP, it's very common occurrence.

      Trivial example: Alice calls Bob. Alice is logged onto server 1. Bob is logged onto server 2. Servers have lookup tables for each other. Signaling path goes A -> 1 -> 2 -> B. If possible, the media path should take direct path A B, istead of flooding the servers.

      Anyway, with SIP, this is more or less solved problem with STUN/TURN/ICE. If a direct path exists, they use it. If and only if both Alice and Bob are behind firewall/NAT, they will connect via a proxy server that may or may not be co-located with the registration servers.

      This was just a trivial example. You can get lots of different scenarios for media paths. Consider call forwardings. Conference calls where external bridge resource is needed. Roaming to another network (new IP address) during call. Different kinds of service center systems where your call might go via several queues before reaching an agent.

      Anyway, the problem is more or less solved, especially if you encrypt the traffic (both signaling and media). That pretty much ensures that the aforementioned STUN/TURN/ICE mechanisms do actually *work* instead of some fancy ALG in the middle starting to alter the signaling content.

      • some fancy ALG

        Would you like to know why those terrible ALGs were invented? Because of FTP. Stupid, stupid, stupid. I would stop hating on those protocols if they handled inbound connections and the lack thereof gracefully and automatically on the protocol level, but they behave like CGNAT and firewalls don't exist and all ports can be expected to be reachable from anywhere. Can you imagine the world today if SIP had been designed for the internet as it exists, not for the academic all-open internet of bygone years? The

        • Re: (Score:2)

          by Zarhan ( 415465 )

          The POTS would be ancient history, we wouldn't be paying for phone calls, no matter how far, and everyone could talk to anyone, not just Whatsapp to Whatsapp, Skype to Skype, Facetime to Facetime. Try to convince someone to set up SIP telephony instead of those.

          Two of your examples already use SIP.

          Skype for Business uses SIP (as does MS Teams). Don't know about regular Skype these days (the historical P2P Skype did not). Heck, you can even get the debug logs from the client.

          Facetime uses SIP.

          Whatsapp I thin

          • That's not the point. You can write a SIP client that does the dirty work and deals with the protocol shortcomings under the hood. The protocol still lets you do it the way the protocol was designed to work, and then it won't work in a great many cases. SIP is a stupidly designed protocol like PHP is a language that puts the wrong way in front of you and hides the right way. The unnecessary complexity and constant pitfalls around firewalls and NAT have created a market for those walled garden systems. If SI
  • As we take a moment to celebrate this birthday, let's also remember fondly and/or in sheer terror that the US financial system is literally just banks FTPing text files to each other. https://engineering.gusto.com/... [gusto.com]

    • So they have stopped shipping punched cards now?

      • Clearing cheques between Australia and the USA takes about six week either way. I assumed that was because the bank just kept the money, but no. I sent a cheque from my US account to my Australian account and the money arrived before it left the USA.

        So I have visions of poor bank tellers rowing boat loads of cheques across the pacific. Of course it probably is not that bad, they probably just use shipping containers...

    • Re: (Score:2)

      by cusco ( 717999 )

      In 1999 I was tasked with moving my employer's data transfers from 9-track tape to some other method before the drive failed. We ended up with a variety of methods, encrypted email, modem transfers, even mailing a burned CD for that "enormous" 40 mb file to headquarters. American Express was, well, unique.

      They had us send an unencrypted text file to their FTP site. Logged in as Anonymous with no password. Drop the file in a folder labeled with our account number. The first time I logged in I found that

      • We ended up mailing them a CD as well for our monthly 2 mb file, since there was no way we were going to put our customers at that sort of risk.

        Which they probably copied into the same FTP directory tree to simplify processing.

  • Umm, I hope nobody is actually using straight ftp. It should be sftp or that would be nuts. Itâ(TM)s like using telnet instead of ssh.

    • Umm, I hope nobody is actually using straight ftp. It should be sftp or that would be nuts. Itâ(TM)s like using telnet instead of ssh.

      There is a version of FTP (FTP/S) that does some encryption. SFTP is a completely different "animal"

      I always made people using SCP or SFTP have passwords on their keys. if they shared the keys and passwords, they would have to
      fill out a form and re-request them.

      I trust users a little more with a dedicated server that uses 2FA with a web interface, a little more.

      • I use straight FTP for some things I want to make available for download, where security isnâ(TM)t a concern, such as large ISO images for software or OS installs. I could care less if the traffic is encrypted. Iâ(TM)m allowing anonymous FTP, so unlike your telnet comparison, I donâ(TM)t even care about a password.

        • If itâ(TM)s an ISO file transferred unencrypted do you realize people can modify/inject stuff into it as it traverses the network. Are you at least checking the sha256 hash (obtained securely)

          • While possible, has anyone actually carried out such an attack? Seems like way more effort than its worth.

            • You would need to be on the route of the packages.
              Modify them, fake the orgin IP address.
              Actually you would need to know what the content is. Makes no sense to change random bytes in a text file.

              In other words: if you do some nasty FTP, it is unlikely the packages go via my computer (actually the likelihood is ZERO). Supposed it would go via my computer, I would need to know the filename and more precisely: what the file is about. Otherwise "injecting mallicious code" into a text file, pdf or image, or movi

          • Checking the hashes of whatever you download is a problem for the downloader, not for the person who is providing the data.

        • Just a reminder:

          Iâ(TM)m allowing anonymous FTP, so unlike your telnet comparison, I donâ(TM)t even care about a password.

          It's 2021 and Slashdot *still* can't do unicode.

    • I’m still using UUCP!

    • Sftp is basically netcat over ssh, can't compare!

    • One thing that really sucks is their is no good standard for file sharing. Normal FTP was the closest thing we got. But FTP/s is a mess. SFTP for some reason Microsoft never really embraced. Http/Https does the job. But we really need a PC to PC file share without a server in the middle.

      • This is why some people are pushing for IPv6, which has enough numbers such that every device can have its own routable address and not rely on a NAT router.

        On the other hand, the need to avoid NAT has largely gone.

      • "PC to PC file share without a server in the middle" - Netcat works fine for me.

      • There is SSHfs, NFS via SSH.

      • we really need a PC to PC file share without a server in the middle

        These days a web server is a triviality, you can run one with acceptable performance for personal use on a cellphone if you don't make many writes. I don't see any reason why it's a problem to just run your own file upload service on your device. It's very slightly easier on Linux than on Windows because all you have to do is run one command and you get all the server stack installed, but it's not horribly difficult on Windows either — or at least it wasn't last time I looked :)

    • Not doing the key exchanges for SFTP or FTPS saves some startup time. Not using encryption for bulky data also saves some resources.

    • You would be surprised. In previous jobs, I have had to deal with "naked" FTP via a number of solutions, depending on the application and endpoints:

      1: Use FTPS. This isn't SFTP, but SSL/TLS enabled FTP, and using client certificates, so an unauthorized connection gets the middle finger before the SSL/TLS handshake is completed.

      2: Move to sftp or scp. This is the best in general, because with ed25519 keys, and firewalling to only allow certain IPs to connect, it has quite good security.

      3: Due to some a

  • FTP is da bomb for embedded devices (Score:5, Insightful)

    by localroger ( 258128 ) on Saturday April 17, 2021 @05:36PM (#61284940) Homepage
    Sometimes you just need to update a file on a microcontroller with a small flash filesystem. You're on a private hookup so security is not an issue, and you need to do directory listing and read and write files. FTP will be the tool for that for a long time. And the more secure extensions are both unnecessary and impractical in a lot of cases. To a certain extent it's not the fault of the transfer protocol that the receiving device is a yarn ball of vulnerabilities. FTP just does what it needs to do, and quite well. I expect we will have another article for its 100th birthday.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      Most embedded code uses HTTP for that kind of thing. Lower overhead, simpler protocol. Some microcontrollers have a crypto module built in to support HTTPS too.

      • Re: (Score:2)

        by xonen ( 774419 )

        Not only lightweight micro-controllers needing firmware. Engineers, scientists, programmers, computers, legacy systems, they just need to get the job done. And FTP suits a couple of tasks very well.

        Yes, there are alternatives. Yes, having a publicly facing FTP server may lead to issues. Yes, these days we do not consider the protocol elegant - partly because we standardized on a byte/word size of 8 bit, partly because we think separate data and control channels are a redundant unnecessity. But at the end of

      • Http doesn't handle file upload very well, unlike ftp or tftp. You need a web page with a file picker button and all. On a microcontroller FTP still has uses.

    • Re: (Score:2)

      by zekica ( 1953180 )
      Some devices use TFTP in some cases. TFTP is slow (only one packet per RTT), but it is extremely simple to implement - no need for TCP at all.

    • Why is it da bomb? It sounds like a needlessly complex solution for something which could be better done with one of the existing services no doubt already running on the device.

      • Well, the bigger picture. FTP is in a big part a module of the original TCP/IP downstream. So it was designed to fix a problem of session connectivity and scaling before it was a problem? Even named pipes were developed along side FTP and either was considered to be the product of the other. Anyone remember Microprocess discussions at Microsoft? Session (microkernel?) networking on a process/IPC level with a proposed version of C++ to write modules with? I guess they went with Cloud communications instead..

        • You're missing my point. If a device has network communication to a user it likely already has one of many other interfaces / protocols for doing so, what do you gain from FTP?

  • I'm ahead by a year. Half a century is an eternity.

    And an eye blink.

    Play accordingly.

  • Finally The People
    Feel Truly 'Preciative
    For Toil Produced.

  • Friends, Slashdotters, Countrymen - lend me your ears.

    I come to bury FTP, not to praise it.
    The evil that protocols do lives after them;
    The good is oft interred with their bits;
    So let it be with FTP
    .

  • Happy birthday ftp! ... Your a huge security risk

  • Anyone remember FSP, the connectionless failed competitor to FTP?

  • I mean, if it works.... (ignoring the vulns, just like SS7)

  • Thanks for making me feel even older than usual.

    Now get off my lawn, I have to go watch Matlock...

  • You're always OK in my book, no matter what all the HTTP kids say.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close