Firefox Follows Chrome and Blocks the Loading of Most FTP Resources (bleepingcomputer.com) 89
Mozilla says it will follow in the steps of Google Chrome and start blocking the loading of FTP subresources inside HTTP and HTTPS pages. From a report: By FTP subresources, we refer to files loaded via the FTP protocol inside img, script, or iframe tags that have a src="ftp://". FTP links placed inside normal angle bracket links or typed directly in the browser's address bar will continue to work. The reasoning is that FTP is an insecure protocol that doesn't support modern encryption techniques and will inherently break many other built-in browser security and privacy features, such as HSTS, CSP, XSA, or others. Furthermore, many malware distribution campaigns often rely on compromising FTP servers and redirecting or downloading malware on users' computers via FTP subresources. Mozilla engineers say FTP subresource blocking will ship with Firefox 61, currently scheduled for release on June 26.
Re: (Score:1)
You know what would help getting your message across? Writing correctly.
Why FTP? Why not an HTTPS CMS site? (Score:2)
Re: (Score:1)
Shh! Google said this is a good idea. Google can not be wrong. /s
Making money, tracking cookies. (Score:5, Interesting)
Google, Facebook, Amazon, Apple, Microsoft, and many others wish to end the hobbyist Internet.
FTP lacks cookies to track views. And FTP is hard for search engines to index with useful metadata for advertisers.
Re:Making money, tracking cookies. (Score:4, Insightful)
(Remembers Gopher. Feels old.)
Re: (Score:2)
Re: (Score:1)
You're thinking of Veronica, that was the search engine for Gopher.
Re: (Score:2)
Floodgap Gopher proxy [floodgap.com] is still alive and kicking. And even Veronica-2 [floodgap.com] is quite usable. There are a few folks who publish their blogs on Gopher (as well as HTTP). And in a weird way the structure of Gopher makes a lot of sense for blog/journal content. (I don't blog, but I'd like to if I could be motivated to write about something)
Re: (Score:2)
And FTP is hard for search engines to index with useful metadata for advertisers.
I think it is somewhat easier for a search engine to 'list -al' the directory to see which timestamps have changed compared to performing a HEAD on each request, parsing the content and spidering. If a robots.txt exists, great, is is accurate? Dunno, will have to index anyway and see.
Re: (Score:3)
Horseshit, more importantly there was no reason at all to serve live content in a HTTP page via FTP in the first place. All you effectively do is break the efforts to optimise HTTP by introducing a random and woefully slow and inefficient protocol into part of the page rendering.
Really this should have been blocked from the onset.
Re: (Score:3)
There are reasons, even if none of them apply to your own situations.
Re: (Score:1)
If you are loading FTP resources on an HTTPS site, you are doing it wrong.
Re:Why FTP? Why not an HTTPS CMS site? (Score:5, Interesting)
It's doesn't need to be easier or better -- it's just another attack surface that CAN be compromised, meaning that there are plenty of FTP servers out there which are misconfigured and can be used to serve malware. Due to the latency logging in and requesting a file via FTP, no webmaster should purposely configure a site to pull a page's resources from an FTP, so it makes sense to cut it off.
As for why it's easier or better, a badly configured FTP server is probably more likely to stay that way because the hackers hide the files and are only using disk space and bandwidth. Something like a CMS will tell you "please update me" every time you log in as admin to patch holes. Your FTP isn't going to tell you that you're a shitty admin.
Re: (Score:2)
One could argue that the FTP protocol is actually more secure because it doesn't serve up Cookies for scumbag companies like Apple, Facebook, Google and Microsoft to track your traffic.
If Mozilla and Google were serious about security they'd block Wordpress sites by default.
TIL (Score:3)
There are still ftp servers. /s
Seriously, why not move to block HTTP traffic? It's not secure, it can serve malicious pages, and spoof real sites...
Re: (Score:2)
Or block https not secured by DANE. Oh wait, implementing DANE in the browser was WONTFIXed by Mozilla. Yay for every single state-sponsored attacker controlling at least one CA.
Re: (Score:1)
That's coming. The same browsers that are removing support for FTP want to remove unencrypted HTTP too. HTTP/2 is not in wide use yet, but the browsers already refuse to accept HTTP/2 content if it's unencrypted.
Re: (Score:2)
HTTP/2 is not in wide use yet, but the browsers already refuse to accept HTTP/2 content if it's unencrypted.
Source? The Kestrel web server used for ASP.NET Core uses HTTP/2 by default and I've never seen a browser refuse to load output from it.
Re: (Score:2)
Seriously, why not move to block HTTP traffic? It's not secure, it can serve malicious pages, and spoof real sites...
Security is only a very small part of it. The point is also that there's a fundamentally different protocol, a woefully chatty and inefficient one at that serving content within pages. Note FTP isn't being blocked, just FTP content within HTTP.
Honestly whoever thought this was a good idea in the first place should have been taken out behind the shed and shown some 2nd amendment rights in action.
Re: (Score:2)
Seriously, why not move to block HTTP traffic?
It's happening. Chrome already flags HTTP sites as insecure, and won't load HTTP content on mixed HTTP/HTTPS pages.
Not that big a fan of ftp in html, but... (Score:2)
I'm not sure I grasp the logic of treating ftp distinct from http (no s) from a security perspective?
Re: (Score:3)
I don't think they are. This is just the same as blocking http: resources that are loaded from an https: page (mixed content blocking).
Re: (Score:2)
Ok, but it also says mixed content for http, and I would think in principle, http and ftp would be considered equivalent security....
The whole point of urls after all was to include protocols and have flexibility to have fit-for-purpose protocols. Nowadays the only protocol is http, and when it isn't, we must shoehorn it into http. This has been disappointing and pretty senseless (at this point, arbitrary TCP style protocols are possible to implement on top of http and this is somehow considered more sane
Re: (Score:2)
You can start with the three acronyms in the summary. None of them work with FTP.
Re: (Score:2)
HSTS means nothing to http (no s)
I *suppose* the other headers requesting browser behavior aren't part of ftp and that could matter. If embedded in an http(s) hosted html page,I would have thought that page should have had all those relevant security headers, and those security headers should already be blocking ftp content from loading as part of such pages if configured...
Re: (Score:3)
HSTS means nothing to http (no s)
HSTS means everything *specifically* to HTTP when there's no S. That's the fundamental point of HSTS to prevent protocol downgrade away from secure, and something that by nature does not work with FTP because there's no equivalent.
And before you dismiss this just remember that half of the attacks on encrypted connections via the internet in the past several years have been due to downgrade attacks, and every single protocol change and advancement has specifically attempted to mitigate this.
FTP wasn't mitiga
Re: (Score:3, Informative)
Re: (Score:1)
Doesn't appear to be blocking <a href= tags, but rather things such as iframes that automatically load content.
Regardless, Firefox isn't qualified to decide which of those things to load. I have several extensions loaded which handle that, because they are.
Re: (Score:1)
The are not blocking you from links. Read again.
Re: (Score:2)
You don't need to turn anything off. Links to FTP not only will continue to work but they are actively improving FTP functionality within Firefox.
What is being blocked is just somet stupid idea that the occasional web designer who can't spell their own name thought may be a good idea when creating a page. Although really I prefer functionality that instead of blocking this, uses Facebook's data trove to identify them, and then call the men in white coats to put that developer in a room with pillows for wall
Good. Kids should stay in their cribs. (Score:3)
Re: (Score:2)
Re: Good. Kids should stay in their cribs. (Score:2)
Ever tried to do a tenex setting from a web browser for a ftp session?
Re:Good. Kids should stay in their cribs. (Score:4, Informative)
Every time you log in to your FTP server remotely you pass your login credentials in the clear. FTP is ancient and unsecure and should be abandoned.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
FTP *is* broken.
I've already had the "pleasure" to open a firewall to allow FTP traffic, it's a nightmare.
Between the passive mode, the active mode and the guy on the other end that doesn't know how it really works, it's always a hassle to get it working right.
I sincerly hope that FTP dies... fast.
Re: (Score:2)
FTP isn't being fixed.
The use of FTP to serve content inside HTML pages however is a horribly frigging broken concept that should have been aborted at birth. It deserves to be "fixed" in that regard.
Nothing isn't being broken that wasn't a broken idea in the first place.
I've been blocking port 21 for over 10 years (Score:2)
Oy (Score:1)
Seriously...why do these people think it's their business to control the form of content displayed in their browsers? If it's valid HTML, served over a valid protocol, it should display. Otherwise the browser is broken.
Re: (Score:2)
Seriously...why do these people think it's their business to control the form of content displayed in their browsers?
Because the use of the protocol is inefficient, a stupid idea from the onset, and breaks compatibility with many security processes introduced in browsers over the past few years.
Even if it wasn't a security issue it shouldn't be allowed because it would be a stupid fucking idea like embedding the remainder of this post within a magnet link or some crap like that.
Re: (Score:3)
Re: (Score:3)
And that is precisely the point. The HTTP standard says nothing about using FTP to fetch content mid page. That entire functionality is the curious quirk that started with a browser becoming an FTP client so that it could download files that were presented as links rather than having to open a separate app. It is not and was never meant to be in any way shape or form a way of delivery content within a page.
The standards don't allow for it.
The standards don't forbid it.
That doesn't mean we should just blindl
Only FTP? (Score:4, Insightful)
This makes no sense to me whatsoever. I fear there is a greater quantity of exploited HTTP(S) servers out there than FTP. Is this not akin to removing telnet from Windows? The loss of functionality does not match the gain in security (is there any?). Surely the first step should be to prevent malicious content, not prevent a protocol.
Are Mozilla thinking to block FTPS too? What about sftp (if it were ever to be introduced), would that count too?
If the argument is that the protocol is plaintext, then HTTP should be dropped.
Re: (Score:1)
Is this not akin to removing telnet from Windows?
No. Why? Because it is not removing ftp - this is stopping the ability to load resources from an ftp resource when loading a http/https page.
Do you think that there are many decent web designers that are loading their images/pages from an ftp site?
Re: (Score:2)
I don't think there are many descent web designers.
Re: (Score:2)
The loss of functionality
What loss in functionality? You do realise Firefox will continue to support FTP right, and if you post a link to an FTP site it will work just fine right? The only "fuctionali", and I use that term very losely, that is lost is the ability to embed an FTP based resource in a webpage, which is a horrible frigging idea. What do you think is faster:
GET this image.
200 OK here is this image.
Or
Hello
Hi, I'm your FTP server.
Hi I'm anonymous.
Hi anonymous do you have a password for me?
No I'm anonymous.
Ok my bad, what
Re: (Score:2)
Anybody web designer who considers this "functionality" for serving mid page content should have all their fingers broken so they feel some proper pain when they type.
Really? There was a time when it was not as simple to have HTTP servers everywhere. There could still be situations where FTP could be faster. Many HTTP servers require more memory than FTP, and, all things being equal there could be real situations where an FTP may be faster than an HTTP, badly written mod_perl/mod_php that sits at the header processing stage could make HTTP perform worse than FTP. Maybe just to take load away from the HTTP you might decide to put that traffic through FTP if its static. Th
Re: (Score:2)
Sorry but I don't see a single use case for any of your points. Let's go through them:
- It was not simple to have HTTP everywhere. It was not. It is now. We are talking about a change that is happening in 2018.
- HTTP needs more memory. - We'll ignore the fact you can run a HTTP server on an ESP8622 with it's whole 80KB of RAM for the moment. Instead let's focus on the fact that this is talking about FTP delivered within HTTP so there is no saving to be had, if you want to save RAM dump the superfluous FTP s
Re: (Score:2)
You seem to have spent a lot of energy confusing best solution with possible solution.
Re: (Score:2)
Not at all. FTP to serve up HTTP content should never be considered a solution at all under any circumstances. There is quite literally no use case for it other than embedding content in a site from a foreign source that was never meant to be embedded in the first place, and that is horrible link breaking practice regardless of what protocol is used.
I'm not spending energy, just using a few braincells and typing really quickly, and if I can convince even one person to not consider going down this incredibly
Re: (Score:2)
Again, you have totally missed the point. There are use cases but you refuse to look at other needs. Go back and read my original post, HTTP isn't the only way to transfer content.
Re: (Score:2)
There are use cases but you refuse to look at other needs. Go back and read my original post, HTTP isn't the only way to transfer content.
I think you may not have read my reply if you think for a moment that your post contained a "use case". No your post contained a clunky way of doing something that was never intended to do without any benefit and a load of downsides. That does not a use case make, and you have yet to come up with an actual use case for serving inline HTTP content via FTP.
Not only is there no need for it, EVER, it also is a stupid idea if you sadistically have a *want* for it.
Re: (Score:2)
I think you may not have read my reply if you think for a moment that your post contained a "use case". No your post contained a clunky way of doing something that was never intended to do without any benefit and a load of downsides. That does not a use case make, and you have yet to come up with an actual use case for serving inline HTTP content via FTP.
Not only is there no need for it, EVER, it also is a stupid idea if you sadistically have a *want* for it.
The use case is that someone has a need to deliver content over FTP. That's the long and short of it. Just because you don't want to do that doesn't remove the fact that someone may wish to deliver that way. You may choose to not do that if you wish, once the browsers include a way to do that they should continue to include that otherwise they have removed functionality that may leave some users surprised. Regardless of you choice delivery protocol preferences.
Re: (Score:2)
The use case is that someone has a need to deliver content over FTP.
Your logical fallacy is: Circular Argument! Now try to come up with a use case for delivering content over FTP within a HTTP site without that use case being "But someone may need to!!!"
doesn't remove the fact that someone may wish to deliver that way
I thought you were talking about a use case. If someone "may wish to" without a use case, all the while delivering a poor solution, then I will continue to call them out for the morons they are.
once the browsers include a way to do that they should continue to
Cars can be used for gassing yourself. Therefore cars should keep having an internal combustion case because someone may wish to gas
Re: (Score:2)
The use case is that someone has a need to deliver content over FTP.
Your logical fallacy is: Circular Argument! Now try to come up with a use case for delivering content over FTP within a HTTP site without that use case being "But someone may need to!!!"
You're misusing the logical fallacy argument, we're talking established protocols here, not adding something that wasn't there already. The use case is, as said already, FTP server is likely to have less overheads. Take a look at RHEL Apache installs as an example, they're the kitchen sink, unlike that vsftp. Take this to an extreme with a dynamic site that handles all associated mod_* hooks and you will very likely have much slower delivery than a skinny vsftp.
doesn't remove the fact that someone may wish to deliver that way
I thought you were talking about a use case. If someone "may wish to" without a use case, all the while delivering a poor solution, then I will continue to call them out for the morons they are.
No browsers should not continue to appease people who misuse their features stupidly.
The only misuse you came up with was marginal
Re: (Score:2)
You're misusing the logical fallacy argument, we're talking established protocols here, not adding something that wasn't there already.
No we're talking about using established protocols in way that were unintended. You said there was a use case. I'm still waiting to hear that use case without you coming up with a circular argument for that use case.
The use case is, as said already, FTP server is likely to have less overheads.
No it doesn't because we're talking about serving FTP within HTTP which means you either have a HTTP server or a HTTP server AND and FTP server. So the FTP server adds needless overheads when you already require a HTTP server to serve a page. No one anywhere in this thread, in any Slashdot reply
What is XSA? (Score:2)
browser security and privacy features, such as HSTS, CSP, XSA
I know HSTS and CSP, but what is XSA? Wikipedia says "Cross-Server Attack", but that is not a security feature.