FTP Resources Will Be Marked Not Secure in Chrome Starting Later This Year (google.com)

Google engineer Mike West writes: As part of our ongoing effort to accurately communicate the transport security status of a given page, we're planning to label resources delivered over the FTP protocol as "Not secure", beginning in Chrome 63 (sometime around December, 2017). We didn't include FTP in our original plan, but unfortunately its security properties are actually marginally worse than HTTP (delivered in plaintext without the potential of an HSTS-like upgrade). Given that FTP's usage is hovering around 0.0026% of top-level navigations over the last month, and the real risk to users presented by non-secure transport, labeling it as such seems appropriate. We'd encourage developers to follow the example of the linux kernel archives by migrating public-facing downloads (especially executables!) from FTP to HTTPS.

Comments

As someone who has to administer firewalls...

[Alioth]

...FTP just needs to die. The two port requirement and worse still, people who don't get it still insisiting on 'active' FTP, is a pain in the backside for firewall admins (we had one vendor insist that passive mode was 'insecure' and active mode was somehow 'secure' but after some browbeating and the threat of the wire brush of enlightenment accepted they should use this new fangled "sftp" which didn't have any of the drawbacks of ftp, passive or active).

FTP's day was done over ten years ago.

Re:As someone who has to administer firewalls...

[RightwingNutjob]

See, it's IT-monkeys like you that make for most of the trouble in technical work. Yes, FTP isn't secure by itself, but it's simple. And in many contexts I can think of, simple and unlikely to break because someone forgot to update his certificate beats encrypted but way more fragile by a mile.

Re:As someone who has to administer firewalls...

[green1]

If you're giving a file away for free to everyone, how secure do you need the transport protocol to be?

Re:As someone who has to administer firewalls...

[RightwingNutjob]

It's a better use of just about anything I can think of to encrypt the file or make a secure hash of it or whatever ONCE, and transmit it in the clear with no computational or administrative (you updated your certs on time...right?) than it is to store it with nothing and encrypt/decrypt it each and every time it's accessed. May not matter if you think it's someone else's job to do that legwork or if designing for performance and limited computing power is something you think only dinosaurs care about, but guess what, stuff built my way will work and stuff built around a spider web of could services and certificates and trust models won't work as well and will break.

Well isn't security just good practice? you might ask. Yes. In many public-facing applications, but not everywhere. If you have physically secured lines internal to your facility, you don't care as much. If you have a hardware encryption layer between two facilities, you don't care as much. If all of the stuff we're talking about is a "network" of computers inside of one chassis (cars, facility control, etc) you don't care as much.

If the security were free, you'd do it in a heartbeat. But security isn't free. It costs compute cycles, administrative overhead, and introduces its own set of possible failure modes. So it's foolish to say "do it always" because those other costs count too and it's a matter of engineering judgment whether the risks of unsecured FTP outweigh the costs of securing it for any particular application.

Re:As someone who has to administer firewalls...

[tlhIngan]

Spoken like someone who has never looked at the FTP protocol or the code in a client or server. HTTP is far simpler to implement than FTP and, unlike FTP, is also trivial to add TLS support to, easier to scale up with CDNs, and so on. FTP hasn't been the right tool for any job for well over a decade.

1) FTP uploads are easier to support than HTTP uploads HTTP uploads require CGI scripts to handle, and if configured wrongly, can lead to security issues (see FCC website w.r.t. comment system)

2) FTP supports TLS -it's called FTPS (not to be confused with SFTP - the former uses FTP and initiates a TLS session, the latter uses SSH). Modern FTP clients and servers support STARTTLS as a command to initiate TLS, and they do it before the USER/PASS commands so the connection is encrypted from the get-go. Note that you need to use passive mode while doing this as most NAT gateways spy on FTP sessions to set up dynamic mappings, and TLS doesn't allow them to do it.

3) HTTP doesn't allow for easy downloading of multiple files other than picking and saving one at a time. Sure browser extensions may try to simplify this, but in general, you can't pick a list of files and transfer that. Triply so if you want to upload multiple files - either the web page and script has to implement support or you're having to upload files one at a time. Clever javscripting can help with that, but now you're relying on user side and server side scripts and not all websites that support uploads support multiple file transfers.

Granted, it's time for a modern upgrade to FTP that gets rid of the multiple port requirements, but HTTP is not a complete replacement for FTP. FTPS still has all the issues with FTP. SFTP is a lot better, but support is generally lacking across the board, including bypassing strict firewalls.

So how about FTPS

[guruevi]

FTP can be done using TLS and there is also SSH-FTP. FTPS is no more or less secure than HTTPS.

Have you ever downloaded large files over HTTP? It's not built for it, you practically need a download manager because the browsers will just choke or won't be able to continue unfinished downloads and there are hacks that make it work but many configurations aren't set up right to continue partial downloads.

Re:So how about FTPS

[guruevi]

Yes, yes it is, it is the same protocol. You obviously have no clue and attempting to argue with a 20+ year Linux/Unix veteran is only going to embarrass you further.

Re:So how about FTPS

[guruevi]

FTPS is relatively standard, I never have had an issue with it although you are right that there are various shoddy closed source FTP servers, the only "problem" is that most use self-signed certificates.

I'm currently trying to download 300GB via HTTP on a server that limits each user to a single connection of 128kbps (yay, academia). I know it supports range requests but as I said, they are particularly flaky on many non-Apache servers (looking at you IIS) and many admins misconfigure it, especially on nginx . Then there are session issues, which if your session expires, you can't continue your download.

  From a server end you can't just use pipes to push data from eg. a compression algorithm over HTTP unless you custom script something (eg. in PHP), with FTP the remote behaves just like a local disk drive, which means you can open remote pipes or devices even.

The answer is

[Anonymous Coward]

GOPHER!

Re: Wherdid the vaby go?

[bn-7bc]

Moderators: my comment above was made redundat by others, in the interest of keeoing things klean, pleace feel free to remove it

Bring Back ZMODEM

[Anonymous Coward]

Make file transfers great again. Trimp 2018!

Re:About time

[infolation]

Given that FTP's usage is hovering around 0.0026% of top-level navigations over the last month

or... the kind of people who use FTP are also the kind that disable telemetry.

(and... the kind that use sFTP are the kind that don't use a browser.)

Re:Typical

[Opportunist]

Now that would be a plugin! One where people can choose the (ad) cookies to share with the other users of the plugin, basically rendering any and all data collected absolutely worthless because nobody can ever know anymore who used what ad cookie to visit a page.