7 ms·

FTP Must die the technical explanation

46 points by aurelien 11y ago

Piskvorrr 11y ago
To be honest, I'm surprised that anyone still uses that thing in 2016 - we have rsync, bittorrent, and all the HTTP we can eat. What compels anyone to think "I know, let's use the most broken tool I could possibly find"?
- onion2k 11y ago
  remsync for the win. (http://www.fifi.org/cgi-bin/info2www?(remsync)Overview http://www.fifi.org/cgi-bin/info2www?(remsync)Overview)
- wimagguc 11y ago
  You would be even more surprised to know how many web development companies are still using FTP to upload content to websites. Every time I hire a company to do Wordpress development on Heroku, one of the first questions is always "yes, we understand that you want to use Heroku, but can you give us the FTP password please?"
- pluma 11y ago
  The main use of FTP these days seems to be cheap web hosting. I'm not sure why there aren't more hosts who support SCP/SFTP but the vast majority of web hosts seem to only offer FTP access and that's what less technical users (e.g. non-developer Wordpress admins) have come to expect.
- moontear 11y ago
  Hmm, the rant is just that - a rant. No solutions and many non-arguments such as outdated acronyms in the RFC. I am with you that there are other solutions, but they are not easy to use for enterprise customers and that is where FTP still thrives. Rsync? Sysadmins maybe know this, but your marketing guy? BitTorrent? That's for illegal stuff and it is blocked on our company network. You want to send a client (e.g. a newspaper) all your fancy videos and graphics (remember you are the marketing guy) to publish somewhere. The videos are of course 4GB per file. What is the easiest way to share these files you have sitting in your "Marketing Campaign 2016" folder? Ask your IT department (just going by your suggestions): - HTTP? Our server cannot handle file transfers larger than 2GB and times out after that. Also most clients don't have resuming capabilities. And don't even start with public file sharers our data is private. - BitTorrent? Is blocked on our network. Also the client told us it is blocked by their ISP - rsync? What is that? I'm a windows guy. Also I doubt that the newspaper will know what to do with some weird command line commands... Just set up a quick FTP server (or use the existing one) and send the link to the client. Everything works. Resuming. Large downloads. Easy to use. Reliable. "Known" interface as the client just sees folders and files. Many clients available or just the web browser. I am not surprised at all that FTP is not dying, I myself have often advised customers to "just use FTP" instead of whipping up a custom solution. It just works. The cost is low, the benefit high. Sadly there currently is no run of the mill solution to replace FTP that "just works" for the average joe.
  - kalleboo 11y ago
    You're transferring private data over an unencrypted protocol that sends passwords in plaintext? SFTP does everything FTP does, works in every FTP client I've seen this decade, and is even supported by some FTP servers if you need virtual users.
    - creshal 11y ago
      Virtually every current FTP client also supports FTPS, so security is good enough. Meanwhile, SFTP does not work with browsers and file managers (unlike FTP[S]), so FTPS works "out of the box" unlike SFTP.
  - icebraining 11y ago
    As far as I know the web browser can't resume FTP downloads, and if you're going to install a dedicated downloader anyway, you might as well get one that supports HTTP. And if you can install an FTP server, you can probably drop Mongoose[1] into the directory that has the files (it's a single binary) and double-click it. There are no more steps, it's already serving those files on port 8080. [1] https://www.cesanta.com/developer/binary https://www.cesanta.com/developer/binary
  - Piskvorrr 11y ago
    "HTTP? Our server cannot handle file transfers larger than 2GB and times out after that." - So, the argument against a fundamentally broken protocol is that your instance of an implementation of some other protocol is broken? That's not a very strong argument. As for "FTP just works" - the same way IE6 used to "just work": there are a lot of hacks happening under the hood, along the whole network path, to keep FTP from breaking (don't get me started on FTP and firewalls). Command line? You mean "press Win, type cmd, Enter, type ftp, Enter." Right? Are you saying there are GUI tools to do that? This changes EEEVERYTHING! (What makes you think FTP is the only protocol with GUI tools? Is it 2000 yet?) In other words, user-friendly solutions exist. But (and this is the elephant in the room) they are not quite as convenient for your local IT guy as shrugging it off with "just dump it on this unsecured clunker like it's 1995".
- forgottenpass 11y ago
  What compels anyone to think "I know, let's use the most broken tool I could possibly find"? I need to publish a publicly available, read-only directory. Users can browse the directory structure, downloads shouldn't require exotic tools, client software ideally exists in a base system install, and recursive downloads should be easy. If you have a better idea, I'm all ears.
  - Chlorus 11y ago
    Honest question: Why wouldn't SFTP work for this use case? Most decent FTP clients I know also do SFTP. Is the encryption overhead non-trivial?
    - creshal 11y ago
      Most dedicated clients do, but not all. Critically, not the built-in FTP clients of major desktop OSes. Windows Explorer only supports FTP, not SFTP, and AFAIK it's the same with OSX' Finder.
      - rakoo 11y ago
        How exotic are tools like WinSCP (https://winscp.net/eng/index.php https://winscp.net/eng/index.php), Filezilla (https://filezilla-project.org/ https://filezilla-project.org/) or Cyberduck (https://cyberduck.io/?l=en https://cyberduck.io/?l=en) ?
        creshal 11y ago
        Exotic enough that I always have to tell users to install one, I can't rely on them having any installed. But literally everyone has an FTP(S)-enabled file manager and browser installed.
  - kefka 11y ago
    I've been working with a new set of software that does precisely that. 1. Publicly available, with the link. 2. Immutable data, by definition is read-only. 3. Users can easily view the root directory and every file enclosed 4. Uses nothing more than a web browser, with no addons. Right now, it does greatly speed up if you use the peer software. http://ipfs.io http://ipfs.io - Interplanetary File System. It does everything you asked for. The current way the network works well for people who don't run the client is that ipfs.io is running an IPFS->web gateway, where you go to http://ipfs.io/ipfs/[hash] http://ipfs.io/ipfs/[hash] For example, I'm preparing to go to a 3d printing convention where the bandwidth is very limited. So I'm hosting a slew of 3d printer files. If you are running the peer software, click the localhost link. http://127.0.0.1:8080/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTdacjkb6PSHsJ2X http://127.0.0.1:8080/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTd... http://ipfs.io/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTdacjkb6PSHsJ2X http://ipfs.io/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTdacjkb6P... So yes, there is a potential download of some software. What does that get you? It allows you to download at the full speed of the network (bittorrent based) and uses DHT for finding local peers. You can also add files in the network, and share by simply copy/pasting the link to whom you want to have the files. Interestingly, it indeed solves this: https://xkcd.com/949/ https://xkcd.com/949/ Ideally, the IPFS team is working on a javascript-only IPFS node, where the webpage itself is self-hosting the IPFS gateway. That would also free up phone clients and more exotic tyes of computers with only browser support.
- creshal 11y ago
  We're running FTP servers for two use cases: • Embedded. TFTP and regular FTP have reasonable high-quality libraries for all kinds of microcontrollers. HTTP doesn't have a standardized directory browsing mode, and rsync/bt/sftp/… aren't available for those µcs. • File uploading with easily set up sandboxing and virtual accounts. We could use something else here, but so far it was cheaper to keep FTP running than to set up SFTP that a) doesn't require system-wide accounts (couldn't do that because of username clashes), and b) is sandboxed out of the box without me having to double- and triple-check there's no weird corner case where you can get out. And not-(S)FTP solutions seem to lack good, reliable, easy to use desktop clients. We're dealing with tens of thousands of files and dozens of gigabytes here that need to be shared with non-technical users, and work outside VPNs, so CIFS and most hipster startup crap doesn't really cut it. I don't think the embedded situation is going to change any time soon, but I'd really appreciate a less painful SFTP solution for the latter case.
jamescun 11y ago
Is FTP that heavily used in 2016? The only use I can see for it now that hasn't been replaced by either a better protocol (i.e. BitTorrent) or a service (i.e. Dropbox) is shared web hosting, even then many now support SFTP (and git).
- swiley 11y ago
  Don't forget WebDAV.
  - vardump 11y ago
    Did WebDAV ever work reliably?
    - baldfat 11y ago
      If WebDAV worked as reliably as FTP more people would use it. Which is actually bad since the tech is rather weak in my opinion. :) So good for the internet that it never really "just worked."
- deleted 11y ago
  [deleted]
- nowprovision 11y ago
  Thanks to our friends at cPanel and the hundreds of thousands of web hosts that embrace and evangelize the platform old-school insecure FTP is still popular and strong and often the documented/default way clients are encourage to upload their files.
- SixSigma 11y ago
  Why would I use those on the LAN ?
  - icebraining 11y ago
    I don't know about you, but I don't trust my LAN and neither should most people. Between crappy routers and infected laptops, we are better off treating it like another branch of the Internet. Even Google has been backing off the "trusted firewalled LAN" model and relying more on edge security.
INTPenis 11y ago
I recently had a client order SFTP from me, I thought I had misread and asked if they meant FTPS (FTP with SSL) but they insisted that they wanted SFTP. This was a case where the client was quite informed and knew that they wanted encryption but that it would never work through a firewall so they ordered SFTP. I was pleased about this but then came other challenges, MITM protection. My solution was to use DNSSEC with SSHFP records. Unfortunately I can't guarantee that the client software supports it.
- masklinn 11y ago
  Wouldn't SFTP MITM protection just be regular SSH MITM protection?
  - INTPenis 11y ago
    Yes it's the same thing, but nobody ever rolls out protection for SSH. It's just a bad habit. When I look at the ecosystem around me I see mostly tech people using SSH, while the case I described was one where ordinary end users wanted to use SFTP as they had been using FTP in the past. So I suddenly felt a more urgent need for MITM protection. With techs I guess the responsibility is often shifted onto them to keep track of their known hosts.
- kba 11y ago
  Why would you assume they wanted FTPS? SFTP is both more common and very superior. Also, what MITM attacks are you afraid of with SFTP?
  - icebraining 11y ago
    You can use regular TLS CA-signed certificates with FTPS, but not with SFTP.
    - dozzie 11y ago
      Except yes, you can use CA-signed certificates with SFTP.
fenesiistvan 11y ago
Why we should kill all well know old technologies? FTP should remain forever and if somebody wish to use it lets allow it. I don't understand all these kind of hype for new technologies. Are you kidding about Dropbox? Drop an old, well know tech by a fancy new protocol with vendor lock-in? Most of the issues listed here are already fixed in modern clients. I am using FTP every day on local LAN and also on internet. Never had any issue with connectivity, or firewalls (this is why passive mode was added) or file corruption. Not to talk about the ascii mode problem (That was a problem only with ancient unix clients).
- Chlorus 11y ago
  Where is he/she suggesting replacing FTP with Dropbox? > (this is why passive mode was added) Did you not read their entire section on the problems with passive mode? I'm glad it works for your use cases, but for many of us, Rsync / SFTP is by far the better option.
  - barbs 11y ago
    I think he might've been referring to this sibling post: https://news.ycombinator.com/item?id=11252320 https://news.ycombinator.com/item?id=11252320
- SEMW 11y ago
  > Are you kidding about Dropbox? Drop an old, well know tech by a fancy new protocol with vendor lock-in? That a bit of a false dichotomy, isn't it? SFTP (for example) is also a well-known, well-established, and open protocol, and suffers from none of the problems the article lists. The choice is not 'FTP or proprietary'.
  - cm2187 11y ago
    But it suffers from other problems like compatibility. I never managed to get the filezilla ftp client to connect to a secure IIS ftp server. And visual studio for instance can't deploy to sftp.
jezfromfuture 11y ago
Ftp is still the fastest file transfer protocol , when you invent something better then you can moan otherwise plz go to fail.
- cm2187 11y ago
  ... for large files.
- kba 11y ago
  Everything unencrypted will always be faster than the encrypted counterpart. Do you also deliberately avoid HTTPS? And is that minuscule performance gain really worth the risk with FTP?
  - cm2187 11y ago
    Not convinced https is a simple substitute for ftp. Think of the new asp.net MVC framework. The http root directory is not the root directory of the MVC app, but a sub directory (which by the way is a good design decision, separating executable from static content). So with https you will only have access to a subdirectory of the application you need to deploy. Not sure you will be able to use https to deploy. ftpes sftp and ftps are alternative solutions but I found them to be extremely incompatible between softwares. I never managed to get filezilla ftp client to connect to a secure IIS ftp server. And Visual Studio can't deploy to secure ftp, etc.
    - kba 11y ago
      I did not mean to say that HTTPS was a substitute for FTP. You said that FTP was the fastest protocol, and the only reasonable explanation for why FTP could be faster than anything else would be due to the lack of encryption. Therefore, I asked if you also avoided HTTPS (and only used HTTP), since HTTP clearly is faster than HTTPS. But if you didn't mean to say that FTP is the fastest due to the lack of encryption, then why do you think FTP is the fastest?
- Zr40 11y ago
  What makes you think so? Nothing in the FTP protocol makes it faster than, say, HTTP, yet FTP requires more network round-trips to initiate each file transfer.
rwmj 11y ago
As the author of an FTP server called Net::FTPServer, I must say this article is full of crap. All modern clients request binary mode and passive connections by default. All modern servers can restrict the range of port numbers used on the server side. Clients support encrypted control and/or data connections. You can checksum files using de facto standard commands (it's better than unencrypted http in this regard). Now some benefits of FTP: - easy uploading of files - standardized file listings, delete, mkdir, etc - extensible protocol via "SITE" commands - wide availability of clients and servers It's better to compare FTP to WebDAV. After comparing it you may still think FTP should "die" (whatever that means in the open internet where any two people can run any service they want), but at least you'd be making a sound technical decision, which you're not doing by reading this article.
- masklinn 11y ago
  > - standardized file listings, delete, mkdir, etc Isn't one of the rant's point specifically that these are not standardised (in a de-jure sense)? > It's better to compare FTP to WebDAV. SFTP exists, has none of FTP or WebDAV's issues and (as far as I can tell) ticks all your boxes. Even extensions: http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-10 http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#sect...
  - rwmj 11y ago
    Those commands really are standardized. The problem is that the rant didn't bother to look at any of the more modern RFCs, nor at de facto standards supported across lots of servers and clients. SFTP is fine too, assuming you have support, which is not available on many embedded platforms, and even on Windows requires downloading extra tools. I'm hardly claiming that FTP is the pinnacle of human achievement. The original standards have many obvious flaws, but those have long been fixed. What we have now is maybe not elegant, but it works and the problems with it are not any of the things outlined in the article.
- cotillion 11y ago
  The FTP protocol designers understood the need for something like ASCII mode back in 1985. Something the SFTP people had to re-discover in 2005. Abhay Bhushan, Postel, Reynolds etc did an awesome job! edit: wrong rfc
nextweek2 11y ago
Standards documents are created by people with a need. They then implement the feature and seek feedback, hence the term RFC. Ideally rather than being negative, how about discussing how it could be improved in the form of an RFC document. Also the section on comparing an FTP session to a HTTP GET is just misleading. One is an authenticated long running session where as the other is just a fetch with a connection left hanging (resources on the server are tied up).
restalis 11y ago
"If security of your authentication credentials matters one iota to you, you'll use scp to transfer files, not FTP." If security maters then use a secure version of the FTP (SFTP or FTPS). FTP has a greater multi-platform support compared to SCP.
k__ 11y ago
I never had to use FTP at work in my career. Somehow I always got an SSH login. FTP always was more of a private thing for me, like BitTorrent.
Avernar 11y ago
I loved the active/passive mode feature of FTP back before getting broadband. I had an FTP client that would put one server in active mode and one server in passive mode and transfer files directly between them with only status messages going down my 9600 baud connection.

46 points by aurelien 11y ago

To be honest, I'm surprised that anyone still uses that thing in 2016 - we have rsync, bittorrent, and all the HTTP we can eat. What compels anyone to think "I know, let's use the most broken tool I could possibly find"?

onion2k 11y ago
remsync for the win. (http://www.fifi.org/cgi-bin/info2www?(remsync)Overview http://www.fifi.org/cgi-bin/info2www?(remsync)Overview)
wimagguc 11y ago
You would be even more surprised to know how many web development companies are still using FTP to upload content to websites. Every time I hire a company to do Wordpress development on Heroku, one of the first questions is always "yes, we understand that you want to use Heroku, but can you give us the FTP password please?"
pluma 11y ago
The main use of FTP these days seems to be cheap web hosting. I'm not sure why there aren't more hosts who support SCP/SFTP but the vast majority of web hosts seem to only offer FTP access and that's what less technical users (e.g. non-developer Wordpress admins) have come to expect.
moontear 11y ago
Hmm, the rant is just that - a rant. No solutions and many non-arguments such as outdated acronyms in the RFC. I am with you that there are other solutions, but they are not easy to use for enterprise customers and that is where FTP still thrives. Rsync? Sysadmins maybe know this, but your marketing guy? BitTorrent? That's for illegal stuff and it is blocked on our company network. You want to send a client (e.g. a newspaper) all your fancy videos and graphics (remember you are the marketing guy) to publish somewhere. The videos are of course 4GB per file. What is the easiest way to share these files you have sitting in your "Marketing Campaign 2016" folder? Ask your IT department (just going by your suggestions): - HTTP? Our server cannot handle file transfers larger than 2GB and times out after that. Also most clients don't have resuming capabilities. And don't even start with public file sharers our data is private. - BitTorrent? Is blocked on our network. Also the client told us it is blocked by their ISP - rsync? What is that? I'm a windows guy. Also I doubt that the newspaper will know what to do with some weird command line commands... Just set up a quick FTP server (or use the existing one) and send the link to the client. Everything works. Resuming. Large downloads. Easy to use. Reliable. "Known" interface as the client just sees folders and files. Many clients available or just the web browser. I am not surprised at all that FTP is not dying, I myself have often advised customers to "just use FTP" instead of whipping up a custom solution. It just works. The cost is low, the benefit high. Sadly there currently is no run of the mill solution to replace FTP that "just works" for the average joe.
- kalleboo 11y ago
  You're transferring private data over an unencrypted protocol that sends passwords in plaintext? SFTP does everything FTP does, works in every FTP client I've seen this decade, and is even supported by some FTP servers if you need virtual users.
  - creshal 11y ago
    Virtually every current FTP client also supports FTPS, so security is good enough. Meanwhile, SFTP does not work with browsers and file managers (unlike FTP[S]), so FTPS works "out of the box" unlike SFTP.
- icebraining 11y ago
  As far as I know the web browser can't resume FTP downloads, and if you're going to install a dedicated downloader anyway, you might as well get one that supports HTTP. And if you can install an FTP server, you can probably drop Mongoose[1] into the directory that has the files (it's a single binary) and double-click it. There are no more steps, it's already serving those files on port 8080. [1] https://www.cesanta.com/developer/binary https://www.cesanta.com/developer/binary
- Piskvorrr 11y ago
  "HTTP? Our server cannot handle file transfers larger than 2GB and times out after that." - So, the argument against a fundamentally broken protocol is that your instance of an implementation of some other protocol is broken? That's not a very strong argument. As for "FTP just works" - the same way IE6 used to "just work": there are a lot of hacks happening under the hood, along the whole network path, to keep FTP from breaking (don't get me started on FTP and firewalls). Command line? You mean "press Win, type cmd, Enter, type ftp, Enter." Right? Are you saying there are GUI tools to do that? This changes EEEVERYTHING! (What makes you think FTP is the only protocol with GUI tools? Is it 2000 yet?) In other words, user-friendly solutions exist. But (and this is the elephant in the room) they are not quite as convenient for your local IT guy as shrugging it off with "just dump it on this unsecured clunker like it's 1995".
forgottenpass 11y ago
What compels anyone to think "I know, let's use the most broken tool I could possibly find"? I need to publish a publicly available, read-only directory. Users can browse the directory structure, downloads shouldn't require exotic tools, client software ideally exists in a base system install, and recursive downloads should be easy. If you have a better idea, I'm all ears.
- Chlorus 11y ago
  Honest question: Why wouldn't SFTP work for this use case? Most decent FTP clients I know also do SFTP. Is the encryption overhead non-trivial?
  - creshal 11y ago
    Most dedicated clients do, but not all. Critically, not the built-in FTP clients of major desktop OSes. Windows Explorer only supports FTP, not SFTP, and AFAIK it's the same with OSX' Finder.
    - rakoo 11y ago
      How exotic are tools like WinSCP (https://winscp.net/eng/index.php https://winscp.net/eng/index.php), Filezilla (https://filezilla-project.org/ https://filezilla-project.org/) or Cyberduck (https://cyberduck.io/?l=en https://cyberduck.io/?l=en) ?
      - creshal 11y ago
        Exotic enough that I always have to tell users to install one, I can't rely on them having any installed. But literally everyone has an FTP(S)-enabled file manager and browser installed.
- kefka 11y ago
  I've been working with a new set of software that does precisely that. 1. Publicly available, with the link. 2. Immutable data, by definition is read-only. 3. Users can easily view the root directory and every file enclosed 4. Uses nothing more than a web browser, with no addons. Right now, it does greatly speed up if you use the peer software. http://ipfs.io http://ipfs.io - Interplanetary File System. It does everything you asked for. The current way the network works well for people who don't run the client is that ipfs.io is running an IPFS->web gateway, where you go to http://ipfs.io/ipfs/[hash] http://ipfs.io/ipfs/[hash] For example, I'm preparing to go to a 3d printing convention where the bandwidth is very limited. So I'm hosting a slew of 3d printer files. If you are running the peer software, click the localhost link. http://127.0.0.1:8080/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTdacjkb6PSHsJ2X http://127.0.0.1:8080/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTd... http://ipfs.io/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTdacjkb6PSHsJ2X http://ipfs.io/ipfs/QmRBWNHKvz4AmTGN4QyJ4bQMd4fb5vfTdacjkb6P... So yes, there is a potential download of some software. What does that get you? It allows you to download at the full speed of the network (bittorrent based) and uses DHT for finding local peers. You can also add files in the network, and share by simply copy/pasting the link to whom you want to have the files. Interestingly, it indeed solves this: https://xkcd.com/949/ https://xkcd.com/949/ Ideally, the IPFS team is working on a javascript-only IPFS node, where the webpage itself is self-hosting the IPFS gateway. That would also free up phone clients and more exotic tyes of computers with only browser support.
creshal 11y ago
We're running FTP servers for two use cases: • Embedded. TFTP and regular FTP have reasonable high-quality libraries for all kinds of microcontrollers. HTTP doesn't have a standardized directory browsing mode, and rsync/bt/sftp/… aren't available for those µcs. • File uploading with easily set up sandboxing and virtual accounts. We could use something else here, but so far it was cheaper to keep FTP running than to set up SFTP that a) doesn't require system-wide accounts (couldn't do that because of username clashes), and b) is sandboxed out of the box without me having to double- and triple-check there's no weird corner case where you can get out. And not-(S)FTP solutions seem to lack good, reliable, easy to use desktop clients. We're dealing with tens of thousands of files and dozens of gigabytes here that need to be shared with non-technical users, and work outside VPNs, so CIFS and most hipster startup crap doesn't really cut it. I don't think the embedded situation is going to change any time soon, but I'd really appreciate a less painful SFTP solution for the latter case.

jamescun 11y ago

Is FTP that heavily used in 2016? The only use I can see for it now that hasn't been replaced by either a better protocol (i.e. BitTorrent) or a service (i.e. Dropbox) is shared web hosting, even then many now support SFTP (and git).

swiley 11y ago
Don't forget WebDAV.
- vardump 11y ago
  Did WebDAV ever work reliably?
  - baldfat 11y ago
    If WebDAV worked as reliably as FTP more people would use it. Which is actually bad since the tech is rather weak in my opinion. :) So good for the internet that it never really "just worked."
deleted 11y ago
[deleted]
nowprovision 11y ago
Thanks to our friends at cPanel and the hundreds of thousands of web hosts that embrace and evangelize the platform old-school insecure FTP is still popular and strong and often the documented/default way clients are encourage to upload their files.
SixSigma 11y ago
Why would I use those on the LAN ?
- icebraining 11y ago
  I don't know about you, but I don't trust my LAN and neither should most people. Between crappy routers and infected laptops, we are better off treating it like another branch of the Internet. Even Google has been backing off the "trusted firewalled LAN" model and relying more on edge security.

INTPenis 11y ago

I recently had a client order SFTP from me, I thought I had misread and asked if they meant FTPS (FTP with SSL) but they insisted that they wanted SFTP. This was a case where the client was quite informed and knew that they wanted encryption but that it would never work through a firewall so they ordered SFTP. I was pleased about this but then came other challenges, MITM protection. My solution was to use DNSSEC with SSHFP records. Unfortunately I can't guarantee that the client software supports it.

masklinn 11y ago
Wouldn't SFTP MITM protection just be regular SSH MITM protection?
- INTPenis 11y ago
  Yes it's the same thing, but nobody ever rolls out protection for SSH. It's just a bad habit. When I look at the ecosystem around me I see mostly tech people using SSH, while the case I described was one where ordinary end users wanted to use SFTP as they had been using FTP in the past. So I suddenly felt a more urgent need for MITM protection. With techs I guess the responsibility is often shifted onto them to keep track of their known hosts.
kba 11y ago
Why would you assume they wanted FTPS? SFTP is both more common and very superior. Also, what MITM attacks are you afraid of with SFTP?
- icebraining 11y ago
  You can use regular TLS CA-signed certificates with FTPS, but not with SFTP.
  - dozzie 11y ago
    Except yes, you can use CA-signed certificates with SFTP.

fenesiistvan 11y ago

Why we should kill all well know old technologies? FTP should remain forever and if somebody wish to use it lets allow it. I don't understand all these kind of hype for new technologies. Are you kidding about Dropbox? Drop an old, well know tech by a fancy new protocol with vendor lock-in? Most of the issues listed here are already fixed in modern clients. I am using FTP every day on local LAN and also on internet. Never had any issue with connectivity, or firewalls (this is why passive mode was added) or file corruption. Not to talk about the ascii mode problem (That was a problem only with ancient unix clients).

Chlorus 11y ago
Where is he/she suggesting replacing FTP with Dropbox? > (this is why passive mode was added) Did you not read their entire section on the problems with passive mode? I'm glad it works for your use cases, but for many of us, Rsync / SFTP is by far the better option.
- barbs 11y ago
  I think he might've been referring to this sibling post: https://news.ycombinator.com/item?id=11252320 https://news.ycombinator.com/item?id=11252320
SEMW 11y ago
> Are you kidding about Dropbox? Drop an old, well know tech by a fancy new protocol with vendor lock-in? That a bit of a false dichotomy, isn't it? SFTP (for example) is also a well-known, well-established, and open protocol, and suffers from none of the problems the article lists. The choice is not 'FTP or proprietary'.
- cm2187 11y ago
  But it suffers from other problems like compatibility. I never managed to get the filezilla ftp client to connect to a secure IIS ftp server. And visual studio for instance can't deploy to sftp.

jezfromfuture 11y ago

Ftp is still the fastest file transfer protocol , when you invent something better then you can moan otherwise plz go to fail.

cm2187 11y ago
... for large files.
kba 11y ago
Everything unencrypted will always be faster than the encrypted counterpart. Do you also deliberately avoid HTTPS? And is that minuscule performance gain really worth the risk with FTP?
- cm2187 11y ago
  Not convinced https is a simple substitute for ftp. Think of the new asp.net MVC framework. The http root directory is not the root directory of the MVC app, but a sub directory (which by the way is a good design decision, separating executable from static content). So with https you will only have access to a subdirectory of the application you need to deploy. Not sure you will be able to use https to deploy. ftpes sftp and ftps are alternative solutions but I found them to be extremely incompatible between softwares. I never managed to get filezilla ftp client to connect to a secure IIS ftp server. And Visual Studio can't deploy to secure ftp, etc.
  - kba 11y ago
    I did not mean to say that HTTPS was a substitute for FTP. You said that FTP was the fastest protocol, and the only reasonable explanation for why FTP could be faster than anything else would be due to the lack of encryption. Therefore, I asked if you also avoided HTTPS (and only used HTTP), since HTTP clearly is faster than HTTPS. But if you didn't mean to say that FTP is the fastest due to the lack of encryption, then why do you think FTP is the fastest?
Zr40 11y ago
What makes you think so? Nothing in the FTP protocol makes it faster than, say, HTTP, yet FTP requires more network round-trips to initiate each file transfer.

rwmj 11y ago

As the author of an FTP server called Net::FTPServer, I must say this article is full of crap. All modern clients request binary mode and passive connections by default. All modern servers can restrict the range of port numbers used on the server side. Clients support encrypted control and/or data connections. You can checksum files using de facto standard commands (it's better than unencrypted http in this regard). Now some benefits of FTP: - easy uploading of files - standardized file listings, delete, mkdir, etc - extensible protocol via "SITE" commands - wide availability of clients and servers It's better to compare FTP to WebDAV. After comparing it you may still think FTP should "die" (whatever that means in the open internet where any two people can run any service they want), but at least you'd be making a sound technical decision, which you're not doing by reading this article.

masklinn 11y ago
> - standardized file listings, delete, mkdir, etc Isn't one of the rant's point specifically that these are not standardised (in a de-jure sense)? > It's better to compare FTP to WebDAV. SFTP exists, has none of FTP or WebDAV's issues and (as far as I can tell) ticks all your boxes. Even extensions: http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#section-10 http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#sect...
- rwmj 11y ago
  Those commands really are standardized. The problem is that the rant didn't bother to look at any of the more modern RFCs, nor at de facto standards supported across lots of servers and clients. SFTP is fine too, assuming you have support, which is not available on many embedded platforms, and even on Windows requires downloading extra tools. I'm hardly claiming that FTP is the pinnacle of human achievement. The original standards have many obvious flaws, but those have long been fixed. What we have now is maybe not elegant, but it works and the problems with it are not any of the things outlined in the article.
cotillion 11y ago
The FTP protocol designers understood the need for something like ASCII mode back in 1985. Something the SFTP people had to re-discover in 2005. Abhay Bhushan, Postel, Reynolds etc did an awesome job! edit: wrong rfc

nextweek2 11y ago

Standards documents are created by people with a need. They then implement the feature and seek feedback, hence the term RFC. Ideally rather than being negative, how about discussing how it could be improved in the form of an RFC document. Also the section on comparing an FTP session to a HTTP GET is just misleading. One is an authenticated long running session where as the other is just a fetch with a connection left hanging (resources on the server are tied up).

restalis 11y ago

"If security of your authentication credentials matters one iota to you, you'll use scp to transfer files, not FTP." If security maters then use a secure version of the FTP (SFTP or FTPS). FTP has a greater multi-platform support compared to SCP.

k__ 11y ago

I never had to use FTP at work in my career. Somehow I always got an SSH login. FTP always was more of a private thing for me, like BitTorrent.

Avernar 11y ago

I loved the active/passive mode feature of FTP back before getting broadband. I had an FTP client that would put one server in active mode and one server in passive mode and transfer files directly between them with only status messages going down my 9600 baud connection.