Firefox To Remove Support For the FTP Protocol (zdnet.com) 146
Mozilla has announced plans to remove support for the FTP protocol from Firefox. Going forward, users won't be able to download files via the FTP protocol and view the content of FTP links/folders inside the Firefox browser. From a report: "We're doing this for security reasons," said Michal Novotny, a software engineer at the Mozilla Corporation, the company behind the Firefox browser. "FTP is an insecure protocol and there are no reasons to prefer it over HTTPS for downloading resources," he said. "Also, a part of the FTP code is very old, unsafe and hard to maintain and we found a lot of security bugs in it in the past." Novotny says Mozilla plans to disable support for the FTP protocol with the release of Firefox 77, scheduled for release in June this year.
Centralizing the Internet around HTTP (Score:3)
Re:Centralizing the Internet around HTTP (Score:5, Insightful)
HTTP for transferring files? Yeah what a damn edge case that is. /sarcasm.
Re: (Score:3)
Pollute the Internet with HTTP everywhere.
s/(HTTP)/$1S/
Re: (Score:2)
Oh, the freakin' IRONY ... (Score:2)
The thing that makes this decision particularly excruciating is that, for many software depositories, the only way you can even access them is via ftp.
Say you want to download a particular version of ... oh, I dunno ... DD-WRT, for example. The only way to do so with any level of confidence that you'll be able to find the release you need is via ftp. (Yes, I know you can use their web interface to find a version that's compatible with your router - except that page is full of bad information and outdated li
Re: (Score:3)
but the fact that older releases of their own browser were only available via ftp (they're no longer accessible at all, now) makes the irony so ripe you could cut it with a spoon ...
Not accessible at all? Have a look here pal:
https://ftp.mozilla.org/pub/fi... [mozilla.org]
Re:Oh, the freakin' IRONY ... (Score:5, Interesting)
So, use ftp. Or WS_FTP, if you want a WinGUI.
But, I agree with the general sentiment - I have stuff old LAN stuff which was secure at the time, so uses https to manage it. Personally, I don't even need that - it's on my home LAN and I'm not snooping on myself. But, more and more, the browser nannies are doing things like not accepting self-signed certs, or no longer supporting older encryption. So, that forces me to dig out some old browser version. Eventually, even that's going to stop working because compatibility with newer OSs will break.
I don't mind them changing defaults and disabling things for grandma, but please please please, leave the functionality there and allow it to be re-enabled through some sort of power users setting. I'll take ownership for any security issues, of which there aren't any if used appropriately, because not everything a browser accesses is on the public Internet.
Browser developers need to fire their Information Prevention Departments.
Re: (Score:2)
What's particularly galling is Mozilla's announcement that it will not permit Firefox even to list the contents of ftp URLs.
How is this a surprise for you? You need to implement basically the FTP protocol to get the contents and they said they are removing that.
Use an FTP client like a normal person for your archaic edge case.
Re: (Score:2)
As long as they're recognising the FTP:// url and handing it off to my FTP client of choice, I'm fine with this.
If they don't, it's an unnecessary pain in the arse. I go a website to find the latest downloads for things.
Re: (Score:3, Insightful)
Why do you need one interface to rule them all? Why not use a specialized client for FTP and a specialized client for HTTP? Do one thing and do it well.... IMO adding FTP to an HTTP renderer was scope creep in the first place.
Do it like EU browser choice (Score:2)
Why not use a specialized client for FTP and a specialized client for HTTP?
That'd be fine if clicking without an FTP client installed opened an FTP client choice screen, which would show brief descriptions of six clients distributed as free software and links to download each.
Re: (Score:2)
Fuck it. Use HTTP for everything. Pollute the Internet with HTTP everywhere.
Or just go with the notion that a browser is an HTTP(S) client?
For (s)ftp and SCP there are more focused GUI clients such a FileZilla, Transmit and Cyberduck, for example.
HTTP isn't encrypted and old too. (Score:2)
No reason you can't put a layer of TLS between the TCP socket and any other protocol too.
Frankly, I thing this should be the OS's job, and should be a standard part in the OSI layers, a long time ago.
Hmm, it's easy enough to get my OS to do it. A bash script and a TUN device attached to a pair of fifos or something like that could do it. Add the right routing/gateway and firewal rules, and your side is done.
As long as the other side uses the same setup, no problem.
Monkies (Score:5, Insightful)
"FTP is an insecure protocol"
That's nonsense, the protocol is not insecure, it's a protocol. Maybe you mean the connection isn't secure, that's fine, FTP can be tunneled like pretty much any other protocol.
Also, a part of the FTP code is very old, unsafe and hard to maintain
I assume you mean 'Mozilla's FTP code is old'. Sure, possible, and nothing wrong with old code. New code is not more secure than old code as if by magic. It's more the other way around. Maybe it's not rewritten in Rust yet and you all consider that an issue.
Long story short.. Mozilla is loosing a lot of karma points with this attitude. It once was the browser for developers. Then feature creep came along to please the masses. Now features are getting removed to please the masses because 99% don't use FTP on a daily base. Meanwhile, the people that backed Mozilla once are pulling their hairs.
Mozilla, here's what you should do. If you seriously think the FTP code has security issues, then perform an audit and fix the issues. If you are unhappy with the code base, start working on a new FTP implementation if that pleases you more. You can even do that in Rust, if it pleases you. But don't just drop FTP like you dropped IRC just because most users don't use it frequently, because that's a skewed statistic.
And don't complain about manpower, you had plenty manpower to roll out totally useless crap like sending big files, syncing bookmarks and more features that i never used. I kept my mouth shut when you revamped the addon system because, well, you claimed it's safer. But the one feature i do use, every so often, you plan to remove. I could insert some insults here, i won't. I could threaten you to use another browser if you do but i won't. But you are leaving me flabbergasted about your decisions and not for the first time, and you still wonder why Firefox is loosing market share?
Re: (Score:3)
Yes you can tunnel any port. But that doesn't really make it a secure protocol, as the data the FTP Application received is unencrypted and you can't trust the traffic in a tunnel will be encrypted until it hits the end system. Means it is insure, and a port sniffer will be able to get the information.
FTP is an old protocol that really hasn't been up with the times.
EXACTLY like HTTP. (Score:2)
Wrap TLS layer around it and you're done.
Aka HTTPS and FTPS.
Re:Monkies (Score:5, Insightful)
Do we remove all support of the HTTP protocol also because it's not encrypted? TCP is a protocol and it's not encrypted, do we dump it too? I agree, that for sensitive data FTP may not be the best protocol to use, but to unilaterally abandon it because of that is silly. There are plenty of files you can get by FTP that do not need to be encrypted. FTP is an essential part of the internet infrastructure, and it's still widely used even if not by the average user. FTP was an integral part web browsers when they were new, and if it had not been there then the browsers would not have become popular at the start.
Re:Monkies (Score:4, Interesting)
Do we remove all support of the HTTP protocol also because it's not encrypted?
Yes. Expect this to actually happen. The reason it hasn't happened yet is due to how wide spread its use still is. FTP doesn't have that protection. TLS 1.0 didn't have this protection.
TCP is a protocol and it's not encrypted, do we dump it too?
Get back on the right layer.
There are plenty of files you can get by FTP that do not need to be encrypted.
What needs to be encrypted is up to the person being persecuted for accessing the data and not up to you.
FTP is an essential part of the internet infrastructure
Yes it is. So why the hell would you use it in a web browser, something which barely implements even 1/4 of the protocol and its capabilities? Where FTP is in use it is used by an FTP client.
FTP was an integral part web browsers when they were new
FTP was never integral. It was a partial abortion providing minimum capabilities to download a single file from a sever at very reduced capability. It never should have been there in the first place, but had its place as people served files on FTP for sensible clients as web browser downloads were a shitshow (that is web browsers regardless of whether they were accessing a file over FTP or HTTP). That situation changed, FTP is now well and truly obsolete for serving single files to a web browser.
Re: (Score:2)
FTP was never integral. It was a partial abortion providing minimum capabilities to download a single file from a sever at very reduced capability. It never should have been there in the first place,
It was there because the concept of following URLs in the early hypertext browsers was not restricted to just HTTP. The browser would link to multiple services, and importantly the presence of Gopher and FTP were essential to make the browsers useful in the early days. If the intent had been to allow only allow HTTP URLs then the URL syntax would have had no need to specify the protocol.
Re: (Score:2)
URLs were never universal, the browser was never singularly meant to handle all protocols. FTP was essential but for the reason stated. Downloads were not functional over HTTP. If FTP were truly essential from a "browser must adopt other protocols" point of view then the browser wouldn't have implemented only a tiny subset of FTP's functionality, specifically the singular ability to download a single file.
Re:Monkies (Score:5, Interesting)
FTP can be tunneled
But it's not. I can with some certainty say that I have never been offered the ability to securely transfer a file via FTP from a webpage in a browser.
And that's the point isn't it. You want to use FTP for the purposes FTP serves then use a proper FTP client.
I assume you mean 'Mozilla's FTP code is old'. Sure, possible, and nothing wrong with old code. New code is not more secure than old code as if by magic. It's more the other way around. Maybe it's not rewritten in Rust yet and you all consider that an issue.
Don't assume, just read, specifically they cold out the code being unsafe and hard to maintain. i.e. it needs a ground up re-write. But for FTP why bother?
Mozilla, here's what you should do. If you seriously think the FTP code has security issues, then perform an audit and fix the issues.
Why? It's not like Firefox includes a torrent client either. Why not let a dedicated program serve the purposes of a few odd cases that are rarely stumbled upon rather than duplicating code in multiple applications. You may not like it but for all intents and purposes FTP in the browser is completely and utterly obsolete. And if you have an edge case, then Mozilla has an option for you: https://filezilla-project.org/ [filezilla-project.org]
And don't complain about manpower, you had plenty manpower to roll out totally useless crap like sending big files
The irony of that statement is so thick you could cut it with a knife.
syncing bookmarks and more features that i never used
Oh thank god you don't dictate the path Mozilla take. "Firefox: The browser for none of us.... except xonen who doesn't realise he should have an FTP client"
But the one feature i do use, every so often, you plan to remove.
The difference between you and Mozilla is that you are a datapoint, whereas they collect actual usage stats on their browser. You did opt in to that didn't you? If you didn't then I don't know why you're complaining now.
Re: (Score:2)
I've used (and implemented) FTP more recently, but it was kind of a hack.
Banks still use FTP (unencrypted) to transfer payments with NACHA files, but they should certainly switch to SFTP or similar.
Re: (Score:2)
When was the last time you downloaded something over FTP through a browser? I can't remember any time when I did that in the last decade.
Precisely. I can't remember the last time I used FTP through a browser, I think it was in the IE6 days. That said the last time I used FTP was 2 weeks ago to synchronise an entire folder of files to a remote server. FTP where it still has use needs a client. I recommend Filezilla.
Re: (Score:2)
When was the last time you downloaded something over FTP through a browser?
Yesterday. For looking at text files on an ftp site, a browser works well and it is easy enough to copy a ftp files URL and feed it to wget.
Re: (Score:3)
Re: (Score:2)
FTP can be tunneled like pretty much any other protocol.
Not easily though because FTP uses multiple connections, so you can't just wrap it in SSH. There is FTPS but hardly anything supports either of those. Anyone who needs those things probably won't be using Firefox as their client anyway.
This is a good move. It's part of a general move away from anything that doesn't offer encryption as standard. In a post-Snowden world that's the only sane thing to do. It's no longer a case of assuming that if something isn't secure it's been spied on and malware injected in
Re: (Score:2)
Whether all protocols should be encrypted is a difficult question. For a lot of my uses encryption is just annoying baggage. When I *do* want things encrypted, I don't want my ISP to be able to snoop. And then there's routing...
OTOH, it's been a long time since I've used ftp. And I trust the ftp applications are still available. So I'm not up in arms about their action.
Re: (Score:2, Offtopic)
The most important thing we leaned from Snowden is that all data is valuable. Metadata is often worse than the actual data. Everything should be encrypted all the time seamlessly. It all matters.
Re: (Score:2)
Oh well, my internet is fast now, so I guess that's not my problem any more.
HTTP byte range requests ended up paywalled (Score:2)
I really wish we had a protocol that would "continue download after disconnect" instead of starting from the beginning again.
HTTP supports this using byte range requests. However, download managers abused this to download one file with several connections in parallel. This caused several popular file hosting services to honor byte range requests only for premium subscribers.
Re: (Score:2)
Not everything needs encryption. Autnetication is probably much more important than encryption anyway for people concerned with security. Ie, you want to know that the news you get from the BBC is authentic, that you weren't be duped by having a man-in-the-middle inject fake stories, but you don't need it encrypted because the content is common knowledge.
Re: (Score:2)
Well FTP doesn't authenticate either.
authentication (Score:2)
Re: (Score:2)
Not authenticate the user, authenticate the server. How do you know it's the real server?
Re: (Score:2)
Yes you can. Just use the -D [bind_addr:]port option to SSH when connecting.
This turns on the SOCKS proxy server support in SSH and basically any application that supports SOCKS proxies can create their own tunnels. It's actually a bit too easy at times since practically all modern apps supports SOCKS proxies.
Alternatively get creative and tunnel PPP over SSH, though you will need a little support at the remote end to
Re: (Score:3)
Chrome will soon remove FTP too. https://www.ghacks.net/2019/08... [ghacks.net]
Re: (Score:2)
Re: (Score:2)
Isn't IAX a successor to SIP? Maybe I am wrong...
I agree with you about FTP though.... and there certainly is no good reason that I can think of why a web browser should even have anything to do with FTP. It should just hand off that protocol to a specialized app that can deal with it.
Re: (Score:2)
FTP needs five ports: one control and four data (Score:2)
Passive FTP means the server has to allow traffic in additional ports.
I read how PASV works. If the client is making more than one transfer at once, more than one server-side port appears necessary because the server needs to identify to which request a particular connection belongs through a (client IP, server port) pair. But the server doesn't really need to open more than about two to four additional ports for data connections.
Re: (Score:2)
OK. How do I specify in my browser it should tunnel ftp through an encrypted channel? How does the server handle that?
The way to do this is *not in the protocol*, therefore it's an *insecure protocol*. That doesn't mean you can't contrive ways to protect it, but they're not standardized.
Who is this supposed to help? (Score:3)
"FTP is an insecure protocol and there are no reasons to prefer it over HTTPS for downloading resources," he said.
I would think the main reason is that the file you're trying to download is being served by FTP. How is the browser user supposed to have any control over that?
Is Mozilla about to start selling an FTP client or something?
Not invented here (Score:5, Informative)
The Not Invented Here syndrome is running rampant with the current generation of coders. They didn't invent it and they don't understand it, therefore it is bad. FTP is a dead simple protocol. How much effort would it really take to audit that code?
Re: (Score:2)
Even if the code was 100% error free FTP offers no encryption. Not only can people see what you are doing, they can easily spoof the FTP server or modify the data in transit. That's a popular technique for distributing malware these days.
Re: (Score:2)
You're telling me people are going to the trouble of modifying binaries in transit? Are there any instances of this happening? When you say "people" can see you mean someone with router level access.
Re: (Score:2)
Authenticating the data is more important than encryption. A lot of people seem to confuse the two concepts. Authentication is often simpler, especially in a modern browser where the certificates have already been exchanged. Granted, FTP doesn't have that either, but a lot of FTP sites do have MD5 or SHA files to make sure you're getting the right stuff.
Re: (Score:2)
You want to authenticate the download with an MD5 file from the same site?
They are only there to let you check if the download was corrupted, they do nothing for authentication.
Re: (Score:2)
It validates that what you downloaded was what was on the site. If others are forbidden from uploading files, then it should be ok. Also, some files are signed files; such as firmware downloads and such (I know some cellular modems that get their upgrades from an ftp site, with the signature checked after reception).
Re: (Score:2)
Unless you got hit with a MITM attack or the FTP site was spoofed with bad DNS.
Re: (Score:2)
a lot of FTP sites do have MD5 or SHA files to make sure you're getting the right stuff.
Yeah, they're right there in the same FTP-accessible directory as the binary files. A lot of help that is.
There have been cases in the past where I've had to resort to Googling a checksum value just to get a hint of whether it might actually be legitimate.
Re: (Score:2)
FTP is a dead simple protocol. How much effort would it really take to audit that code?
Question: Why audit code no one uses, for a protocol that was only ever quarter baked into a browser to begin with, and is effectively obsolete for linking and downloading within a web browser?
I get it. The most recently Linux kernel just had a big cleanup and rehash of the floppy disk driver, but not everyone is quite that bored. FTP is a dead simple and very useful protocol. But for transferring single files which is all the web browser ever did with it, it is the single worst way to do the transfer and i
FileZilla != Mozilla (Score:2)
Mozilla already maintain an FTP client. Filezilla.
Since when did Tim Kosse, the only person named in FileZilla's trademark page [filezilla-project.org], get hired by Mozilla Corp?
Re: (Score:3)
Do do you really mean "scp"? Not everyone runs windows you know. SCP is a part of SSH. It's like telling people they have to use WinZip to process a zip file.
Just recently I was following directions to use WinSCP for something, so I was halfway through downloading it, reading instructions, then realizing all that the instructions wanted me to do was copy a file. So I went back to Linux and OSX and just used scp from the command line.
Re: (Score:2)
How is the browser user supposed to have any control over that?
I remember a time where we used to castrate web designers for doing old incompatible shit and making horrible websites. By your reasoning Firefox should have 100% compatibility with sites which "Works best in Internet Explorer 6" because of the poor end user.
The reality is FTP is a rare edge case, and the only reason to use it these days would be for purposes which are best served with an actual client as well, and not a 1/4 baked solution that doesn't even support a small portion of protocol baked into a w
Who uses the Web Browser for FTP anyways? (Score:4, Insightful)
I would use normally use the Command Line FTP Tool, or a more customized GUI tool such as FileZilla. I wouldn't use the browser for FTP or SFTP
Re: (Score:2)
Dedicated file transfer tools (scp, sftp, etc. implementations) will use standard DNS rather than DoH. Particularly when I need to upload to a server, I don't need the local content distribution network providers to get between me and the actual service I want.
Re: (Score:2)
Dedicated file transfer tools will use whatever the OS tells them to. If you're worried, change it at the OS level, or VPN, or better still, if DNS is such a concern for you what the hell are you doing using an insecure protocol like FTP in a browser in the first place!
Re: (Score:2)
I have not used a plain FTP client for most FTP uses in the last couple of decades, primarily because most of those FTP sites exist as URLs that I can click on and the browser was vastly more convenient. For the same reason that I use HTTP/S to get files most of the time rather than using wget.
Why not leave it and then force disable (Score:2)
Why not leave it and then force disable and if someone needs it they can go to about:config and turn it back on? That first day would be annoying for people who use FTP, but they can turn it back on and everyone can go on with their lives.
Or another option is just give a warning message like whenever TLS isn't just right? Hey FTP is bad we're requiring an extra click just to make sure you are sure.
Re:Why not leave it and then force disable (Score:4, Insightful)
I don't know the specifics of this case, but in general the issue often boils down to maintenance costs. Usually, the biggest catalyst is that there is code in the infrastructure that is used by a common use case and an uncommon use case. When that code needs to be refactored or tweaked for security or performance reasons, it will often also break the uncommon use case which will require finding and fixing all of the bugs. At a certain point, you just have to re-evaluate the utility of the uncommon use case and sometimes the best path forward is to kill off the feature and leave it to other applications that are written specifically for that purpose.
I'm still not sure how I feel about this yet. I can't remember the last time I was browsing the web and a link sent me to an FTP site but I have a feeling the next time it happens I'll be a little upset (although I'll probably get over it pretty quickly).
Re: (Score:2)
I'm still not sure how I feel about this yet. I can't remember the last time I was browsing the web and a link sent me to an FTP site but I have a feeling the next time it happens I'll be a little upset (although I'll probably get over it pretty quickly).
In which case, Firefox will open the clicked link in the app you select to handle that protocol....
Re: (Score:2)
Firefox will open the clicked link in the app you select to handle that protocol
Provided that an app capable of handling that protocol is installed. Will Firefox suggest downloading and installing FileZIlla (unrelated despite the name) if no desktop-integrated FTP client is installed?
Re: (Score:2)
Why not leave it and then force disable and if someone needs it they can go to about:config and turn it back on?
Do you like shit bloated code? Because that's how you get shit bloated code.
There are no reasons to prefer Firefox over... (Score:3)
no reasons to prefer FTP over HTTPS
I would fix that to "There are no reasons to prefer Firefox over... pretty much anything at this point".
HTTPS is not required for EVERYTHING, FTP is a protocol that serves a good purpose and if needed it can be over a secure connection, although that's a less common usage for it, for good reason.
I stuck with Firefox over the years as it became bloated, slow, etc. Then it removed the old addon system which was what made it useful to me - all the important (to me) extensions stopped working and could not be rebuilt. I reluctantly switched to Chrome even though I hate most things Google is doing to the internet (ironically, imposing HTTPS everywhere being one of them, although not as bad as AMP etc), and seldom use Firefox. But, yeah, go ahead remove more core browser functions to alienate the minority that keeps using Firefox. I don't use FTP nearly as often as I used to, but I still do from time to time and expect a browser to support it.
Re: (Score:2)
Among the browsers that I have tried, there have been two that were acceptable in their handling of bookmarks. Mozilla clones is one batch and the other is Konqueror. And Konqueror was lousy (last year, or perhaps the one before) at downloading files.
Among the Mozilla clones, Firefox was the least annoying to use. Every once in awhile I check things over again, usually because Firefox has made a really stupid change...but so far the others haven't been better.
Re: (Score:2)
FTP is a protocol that serves a good purpose and if needed it can be over a secure connection
Indeed FTP serves a purpose. However it does not serve a good purpose in a browser, and no it can't be served over a secure connection to Firefox. It has been obsolete for many years.
But, yeah, go ahead remove more core browser functions to alienate the minority that keeps using Firefox.
FTP is not a core browser function. It was a limited workaround in the 90s to build incredibly basic download only functionality as files were frequently served over FTP due to HTTP's inherent unreliability in serving large files. This problem was solved 20 years ago, and FTP should be relegated to a proper FTP client that can
It's a browser, not a protocol droid (Score:4, Insightful)
Keep it simple, speedy and secure. Anything not REQUIRED to browse the web should be left to extensions or other apps.
Re: (Score:2)
So all URLs in a web page must be http? By your reasoning we should dump javascript too, in which case I am all for that!
Re: (Score:2)
So all URLs in a web page must be http? By your reasoning we should dump javascript too, in which case I am all for that!
Actually, he said:
Anything not REQUIRED to browse the web
Javascript and HTTPS really are required, unless you mean sometimes browse some minor parts of the web, which isn't what he said.
Re: (Score:2)
So all URLs in a web page must be http? By your reasoning we should dump javascript too, in which case I am all for that!
Given how ...
a) https is just a secure layer over the http protocol,
b) javascript isn't a protocol at all, and
c) both are REQUIRED to browse the web,
I have to ask, Amsterdam's coffee shops are closed due to COVID-19, where are you getting your weed from?
Re: (Score:2)
Then why on earth all the browsers now feature a fully fledged developer console which surely bloats the browser, while only a minority of users are developers?
There are still tons of old resources on the Internet which are only accessible via FTP -- for instance in academic institutions. There are legitimate uses of non-encrypted protocols, e.g. for debugging/education/speed and one can ensure integrity of files using other means, even better than HTTPS (e.g. Debian repositories). It is a stupid move by Mozilla. They should just show a warning about using unencrypted protocol, change the address bar to red, or something along the lines, if they really insist on security.
I agree that we don't need the dev console built in. They should strip out all kinds of things from Firefox IMHO, but I'm not one their clueless developers or managers, so they wouldn't listen to me anyway.
FTP should go too. Use lynx/links or whatever if you must for that kind of thing.
I'd like to kill HTTP though. (Score:2)
I'd much rather have a protocol that allows easy semantic structuring of resources and access thereof.
Something like 9P. With something like XPath for access.
I mean HTTP has become nothing but a kind of sockets anyway. With lots of inner-platform effect.
We could replace browsers by virtual machines and make HTML5 an actual OS for that architecture, see web apps as just another app format, and then port both HTML5 to other architectures and have browsers offer suspended snapshots of other OSes depending on w
Have it launch Filezilla then (Score:2)
Re: (Score:3)
Fuck! (Score:3)
First Gopher, Veronica and now FTP?
If the boomer-remover-virus doesn't get us, Firefox will kill us off.
REST in peace (Score:2)
I've long maintained FTP directories on my file server of installation binaries and terribly non-sensitive guck like that, only accessible on my LAN. Most of these files have checksums which I can (and should) validate immediately before installation. It doesn't matter what happens in between. I either get a pile of valid bits, or I don't.
If I really cared, my entire LAN would be IPSEC by default. And then FTP really would be just another protocol on a secure network.
But I get it. Not even 5% of hardened IT
Re: (Score:2)
Yes, there is. On my file server, some borked patch Tuesday melted my Apache service and SSH is telling me there are no matching encryption methods—OpenSSL, is that you?—and I'm trying frantically trying to locate a repair on the Internet, and while I'm in pursuit of this repair, I discover I need to install some piece of software from my file server, but I can't presently get their
FTP should just go away (Score:2)
FTP (the protocol) is so full of technical debt it's not funny. It should die.
PORT h1,h2,h3,h4,p1,p2
Really????
Just use HTTP or HTTPS to download, and sftp or scp or rsync-over-ssh to upload.
Mistake! (Score:2)
This is a bad idea. I look forward to the fork which will preserve FTP.
Re:there are no reasons to prefer FTP over HTTPS? (Score:4, Insightful)
Re: (Score:2)
would you still recommend HTTPS over FTP?
Not at all, unless you cared about the integrity of your download.
Re: (Score:2)
You can easily handle that with a checksum. It's one of the things md5sum is good at. That it's possible to create hash collisions isn't a problem in most circumstances. If it is, just use multiple checksum methods.
Re: (Score:2)
No, you cannot easily handle that with a checksum, because
3.5. ERROR RECOVERY AND RESTART
There is no provision for detecting bits lost or scrambled in data transfer; this level of error control is handled by the TCP.
So, no, it isn't "easily" handled, unless it is a very sloppy and buggy handling. Which is
Re: (Score:2)
Well, the site has to support it by providing the checksums.
OTOH, your point "c" seems to mean that we are thinking of very different use cases.
Re: (Score:2)
Re:there are no reasons to prefer FTP over HTTPS? (Score:5, Insightful)
If I am downloading a large amount of public data from public source and it is public information that I am downloading it, and I have very slow connection that is charged per downloaded bytes and the server and I have limited amount of CPU power, would you still recommend HTTPS over FTP?
Yes. Definitely in that case I'd recommend HTTPS. FTP is a horribly inefficient protocol and if you're charged per the byte you'd be absolutely insane to use it over HTTPS.
Re: (Score:2)
If I am downloading a large amount of public data from public source and it is public information that I am downloading it, and I have very slow connection that is charged per downloaded bytes
ftp is not significantly more efficient bandwidth wise than https. Sure, there's some overhead in the larger header, but that's just a few percent at most.
That said, the http protocol (not a part of TLS/SSL, but a part of https, so ...) does include the ability to do compression where ftp generally does not ("mode z" is not well supported), so that could easily more than make up for the increased header size.
(Of course, you'll then counter that your public data source already has the data compressed, and t
HTTP compression leads to a BREACH (Score:2)
That said, the http protocol (not a part of TLS/SSL, but a part of https, so ...) does include the ability to do compression where ftp generally does not
Unless the server has turned off HTTP compression to mitigate BREACH [wikipedia.org].
As long as the data isn't sensitive -- and it probably isn't if it's up for anonymous ftp -- there's nothing wrong with downloading it this way
Other than that FTP lacks any way to detect tampering with the connection, be it accidental or malicious. There's nothing in the protocol to provide even an error-detection hash, let alone evidence that the hash originates with the rightful owner of the domain name.
Re: (Score:2)
> FTP is an insecure protocol and there are no reasons to prefer it over HTTPS for downloading resources
in the above scenario I would just use some standalone FTP client
Exactly. It doesn't need to be built into the browser anymore. That's their point.
Would everyone please just let FTP die already?
A web browser for browsing the web. Raw sockets fr (Score:4, Informative)
Some people think a web browser should be for browsing the web, it shouldn't hide a whole operating system in there.
*Allowing* JavaScript to make raw socket connections, using random protocols, seems like the kind of thing that the old Microsoft WOULD have done in IE. The kind of thing that made IE a security shit hole.
It's even worse: (Score:2)
webSockets aren't even conpatible with real raw sockets. (Apparently to prevent what you hinted at. At least in theory.)
But instead I'm now reminded of Embrace, Extend, Extinguish here.
Right, websockets don't make SSH connections (Score:2)
Right, websockets don't do anything that couldn't be done with setTimeout( xmlHttpRequest). They just make it more convenient and efficient to do what you could already do without them.
They are definitely not raw sockets, rather it's an application protocol for message passing, very similar to xmlHttpRequest + json.
Re: (Score:2)
[WebSockets] are definitely not raw sockets, rather it's an application protocol for message passing
And thus they require the server side of a web application to act as a proxy to any service whose normal protocol is something other than WebSockets. This can prove costly for some applications and impractical on an air-gapped LAN.
Re: (Score:2)
Which SFTP?
There are two popular versions that I know about.
One is using the SSH Protocol (Port 22)
The other uses the standard FTP (Port 21) Protocol but encrypts the data channel.
Re:Now add SFTP (Score:5, Informative)
SFTP is an SCP variation over SSH that pretends to look like FTP.
FTPS is SSL/TLS tacked on to FTP.
Re: (Score:2)
No, SCP depends on being able to execute shell commands on the remote side to do the copy. SFTP uses a plugin thing that the protocol supports (called "subsystems" or something). You can't use SCP if the login shell for the account is set to nologin for example, but SFTP will still work because it's not using shell functionality.
Re: (Score:2)
Isn't that FTPS?
Re: (Score:2)
Re: (Score:2)
Archie was utter tosh.
I mean, it was better than nothing, but only barely.
Re: (Score:2)
The Internet as we knew it might have been able to survive... but then, a few months later, came Eternal September.