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

← Back to Stories (view on slashdot.org)

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

Posted by msmash on Thursday September 14, 2017 @02:00AM from the tightening-bolts dept.

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.

103 of 152 comments (clear)

Min score:

Reason:

Sort:

As someone who has to administer firewalls... by Alioth · 2017-09-14 02:15 · Score: 4, Insightful

...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.

--
Oolite: Elite-like game. For Mac, Linux and Windows
1. Re:As someone who has to administer firewalls... by RightwingNutjob · 2017-09-14 02:26 · Score: 3, Interesting
  
  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.
2. Re: As someone who has to administer firewalls... by dougdonovan · 2017-09-14 02:35 · Score: 1
  
  someone got a promotion and had to make some kind of menial change to impress corporate to keep that promotion. hopefully they got a window view.
3. Re:As someone who has to administer firewalls... by TheRaven64 · 2017-09-14 02:39 · Score: 1
  
  Yes, FTP isn't secure by itself, but it's simple.
  
  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.
  
  --
  I am TheRaven on Soylent News
4. Re:As someone who has to administer firewalls... by JohnFen · 2017-09-14 03:25 · Score: 1
  
  A million times this.
  FTP (and Telnet) are antique protocols that cannot be made adequately secure and have long since had more secure alternatives available.
  They just need to go away now.
5. Re:As someone who has to administer firewalls... by bigfinger76 · 2017-09-14 03:36 · Score: 1
  
  Sftp and ftp are two different beasts.
6. Re:As someone who has to administer firewalls... by Chris+Mattern · 2017-09-14 03:48 · Score: 1
  
  Sftp is scp with its interface reworked to look like an ftp client. It really has no relation to ftp.
7. Re:As someone who has to administer firewalls... by green1 · 2017-09-14 03:54 · Score: 2
  
  If you're giving a file away for free to everyone, how secure do you need the transport protocol to be?
8. Re: As someone who has to administer firewalls... by Anonymous Coward · 2017-09-14 04:00 · Score: 1
  
  Yeah, that's why the AC asked if SFTP would have these problems. You see, the knowledge that they are different is inherent in the question. If they were not different the answer would automatically be "yes".
  Reading comprehension is truly on the decline around here.
9. Re:As someone who has to administer firewalls... by SigmundFloyd · 2017-09-14 04:04 · Score: 1
  
  HTTP is far simpler to implement than FTP
  Not for uploads. You'll need a server-side script for those.
  
  --
  Knowledge is power; knowledge shared is power lost.
10. Re:As someone who has to administer firewalls... by JohnFen · 2017-09-14 04:05 · Score: 1
  
  As secure as possible. You don't want MITM attackers modifying the file, and you don't want your server to be compromised.
11. Re:As someone who has to administer firewalls... by thegarbz · 2017-09-14 04:31 · Score: 1
  
  Yes, FTP isn't secure by itself, but it's simple.
  Go to bed, you're drunk. The only thing "simple" about FTP is the minds that came up with a system that requires multiple ports with connections established in different directions that is the bane of the modern internet NAT'd routing.
  Just because it's plain text and in english, doesn't make it "simple".
12. Re:As someone who has to administer firewalls... by RightwingNutjob · 2017-09-14 04:31 · Score: 2
  
  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.
13. Re:As someone who has to administer firewalls... by DogDude · 2017-09-14 04:36 · Score: 1
  
  FTP (and Telnet) are antique protocols that cannot be made adequately secure and have long since had more secure alternatives available.
  
  You're right! The only thing is that the Internet was never designed to be "secure", and likely never will be. FTP works just fine for moving files around. Not everybody needs security on the Internet. If you want to pretend that you can slap some software on top of an inherently insecure network to try to make it "secure", then go right ahead. I'll happily continue to use the Internet the way it was meant to be used.
  
  --
  I don't respond to AC's.
14. Re:As someone who has to administer firewalls... by JohnFen · 2017-09-14 04:48 · Score: 1
  
  Ahh, the old "if it can't be perfectly secure, then there's no point" argument! Personally, I'll take "as secure as possible" as preferable over "not secured at all".
15. Re:As someone who has to administer firewalls... by JohnFen · 2017-09-14 04:55 · Score: 1
  
  I generally agree with you. I actually laughed when I read your comment because I can't tell you the number of times people have berated me here for making very similar arguments.
  Maximum security is not the right answer for all circumstances. However, as much security as you can reasonably implement is a good idea. Multilayered security is always desirable.
  Case in point: in my home network, almost everybody behind my firewall still talks using encrypted channels. Why not, when the machinery supports this without a noticeable performance hit? Should an attacker breach my outer defenses, they still won't have free reign over my systems.
  However, I do have small devices on my network that can't realistically support encrypted communications. So, they don't use encryption (instead, they're segregated on a different subnet).
16. Re:As someone who has to administer firewalls... by tepples · 2017-09-14 05:20 · Score: 1
  
  FTP works just fine for moving files around.
  But what works fine for ensuring that the file the receiver receives is identical to the file the sender sent?
17. Re:As someone who has to administer firewalls... by tlhIngan · 2017-09-14 05:30 · Score: 4, Informative
  
  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.
18. Re:As someone who has to administer firewalls... by eth1 · 2017-09-14 06:06 · Score: 1
  
  ...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.
  what? As someone else who administers firewalls, I have to ask, what the hell kind of ancient packet filter are you using?
  Any modern stateful firewall for almost the last two decades has been able to inspect unencrypted FTP control channels, and dynamically open the appropriate data channel ports. Both active and passive usually work just fine. As a security person, I hate FTP for its lack of encryption and clear text password transmission, but technically, it's one of the easiest.
  SFTP will often end up with users complaining of slowness, because SSH has it's own (smaller) window size sitting on top of the normal TCP windowing, so FTP will often be faster without doing some tweaking on the server side for SFTP.
  The most irritating file transfer protocol from a firewall perspective is FTPS - it works the same was as FTP (control + data connections), but the control channel is encrypted and unreadable to the firewall, so you actually do have to manually open high port ranges, and pay attention to active vs. passive.
19. Re:As someone who has to administer firewalls... by Sigma+7 · 2017-09-14 08:14 · Score: 1
  HTTP is far simpler to implement than FTP
  HTTP Compared to FTP:
  
  While HTTP has the specification in one document, you still need to read more than one if you want modern browsers to work as expected. FTP works find with just one specification (and if an FTP client craps out, that's usually because it doesn't know how to operate.)
  FTP makes it easier to determine which state the server/client is at. HTTP plops headers into one block that's sent, and hopes the other side doesn't get confused. (A minor technical difference for those iteratively creating an FTP/HTTP client/server).
  FTP generally has one encoding in common use. HTTP has multiple encodings in common use, including chunked mode, gzip compression, and a few others. There's also other tricks, such as pipelining, which are optional, but help speed things up.
  HTTP may be easier to implement in the most basic format since you only have one task to worry about. However, modern browsers expect things like Access-Control-Allow-Origin, which you won't know about until you stumble upon it by accident.
20. Re:As someone who has to administer firewalls... by flink · 2017-09-14 08:29 · Score: 1
  
  Or you can use WebDAV. It's about 5 lines of httpd configuration and you can tie it in to use whatever auth module you are already using.
21. Re:As someone who has to administer firewalls... by Aighearach · 2017-09-14 11:30 · Score: 1
  
  Actually, no, when somebody explains that there are use cases with different considerations, you can't just disagree and have any chance to be right. Disagreeing just shows you don't comprehend the words he used. And they were simple words. But you thought you had a magical brain that can see other people's use cases better than they can see them, even if all you know is that it involved FTP! Durrrrrrrrrrrr
22. Re:As someone who has to administer firewalls... by SQLGuru · 2017-09-14 12:02 · Score: 1
  
  No kidding. I just used FileZilla to download 250GB of weather data samples from the NOAA web site (ftp://ftp.ncdc.noaa.gov). It's spread over close to 100,000 files. I just drug the folders I wanted over to my drive and all of the files got queued up. Left it downloading over night and came back to a completed transfer.
  I don't see using any sort of HTTP based solution as being able to do that.
  It's public data (and very likely not going to be MITM'ed), so unencrypted FTP was the perfect solution for this.
23. Re:As someone who has to administer firewalls... by TheRaven64 · 2017-09-14 20:28 · Score: 1
  
  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)
  Nope, HTTP supports several verbs including PUT and POST. PUT doesn't require any scripting and can be configured in most servers to allow uploads based on the current authentication (which can be a client-side SSL certificate, a password, or a couple of other things).
  
  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.
  Needing to support passive mode isn't too much of a problem, because active mode is pretty broken with a lot of NATs anyway. Unfortunately, the STARTTLS mode is trivial to attack with downgrade attacks and most FTP clients don't complain. In contrast, HTTPS will simply fail if you don't have a valid certificate.
  
  3) HTTP doesn't allow for easy downloading of multiple files other than picking and saving one at a time.
  HTTP has much less protocol overhead than FTP and so requiring a new connection to download each file is not a problem, but you are correct that HTTP lacks a mechanism for listing files. Fortunately, WebDAV extends HTTP to provide this (plus the ability to remotely copy and move files, get metadata and lock them) and all major operating systems support it out of the box. Windows and macOS can mount WebDAV directories directly from their graphical file browser, Linux / *BSD have FUSE implementations, at which point you can list and copy / move your files using whatever your preferred method for accessing the local filesystem is (including the command line and via scripts, if you're that-way inclined).
  
  --
  I am TheRaven on Soylent News
24. Re:As someone who has to administer firewalls... by ebvwfbw · 2017-09-15 12:46 · Score: 1
  
  As someone that administers firewalls and bulk data servers, FTP is indispensable. How else can you download a bunch of arbitrary files? Mget works great. I've heard people say - well zip it up. Yea, try zipping up 70 gigs of data, which we serve up regularly. FTP has its place like (most) everything else.
  Your comment on sftp is funny. Requires an account. So anonymous downloads don't work. You also can't download trees like you can with ftp, you also can't restart. Wrong tool. I haven't looked lately, however I bet where I work we have over 1T of files available for download and they are regularly downloaded by people. That machine is always very busy.
  Back to the article - in fact, it's not secure. I was thinking - captain obvious moment, isn't it?
25. Re:As someone who has to administer firewalls... by MercTech · 2017-09-17 06:56 · Score: 1
  
  Why should a simple, convenient, protocol die because it doesn't require secure coding to operate? Why should you need hypertext to grab a file off a server or upload one to a server?
  
  --
  NRRPT/RCT
Wherdid the vaby go? by bn-7bc · 2017-09-14 02:16 · Score: 1

Donâ(TM)t throw the baby out with the bathwater, you can use ftp over tls ( goes by many names) . I dobâ(TM)r see any reson to kill of ftp (well the unencryptet version needs to go) it works perfectly eell for what it is intended to do
1. Re: Wherdid the vaby go? by bn-7bc · 2017-09-14 02:22 · Score: 2
  
  Moderators: my comment above was made redundat by others, in the interest of keeoing things klean, pleace feel free to remove it
2. Re:Wherdid the vaby go? by Anonymous Coward · 2017-09-14 02:26 · Score: 1
  
  On the other hand, whatever you are using to type needs to go.
3. Re:Wherdid the vaby go? by sexconker · 2017-09-14 05:52 · Score: 1
  
  I don't think I've ever actually seen FTPS in use.
  FTP and checksums or SFTP.
So how about FTPS by guruevi · 2017-09-14 02:16 · Score: 5, Interesting

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.

--
Custom electronics and digital signage for your business: www.evcircuits.com
1. Re:So how about FTPS by pr0fessor · 2017-09-14 02:34 · Score: 1
  
  I've noticed a lot of https or torrent as download options for large files.
2. Re:So how about FTPS by guruevi · 2017-09-14 02:43 · Score: 2
  
  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.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
3. Re:So how about FTPS by TheRaven64 · 2017-09-14 02:46 · Score: 1
  
  FTP can be done using TLS and there is also SSH-FTP. FTPS is no more or less secure than HTTPS.
  FTP over TLS is a pain, because you still end up needing multiple connections and the protocol is a nightmare. It's also implemented in a variety of different and incompatible ways by different people and so there's basically no good way of supporting it. SFTP is an entirely different protocol that shares some initials with FTP but is otherwise unrelated.
  
  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.
  I don't think I've downloaded anything over about 50GB via HTTP, but I've had no problems doing so. The protocol supports range requests and both command-line tools and vaguely modern (last 10-15 years) web browsers will happily use that to resume interrupted downloads. Oh, and the range-based part of the protocol also means that you can easily download parts of the file in parallel if you're on a high-bandwidth, high-latency connection and TCP is fighting you.
  Your entire comment here makes no sense, because you're saying that it's possible to write a client for HTTP (a download manager) that does everything that you want and therefore the protocol is bad.
  
  --
  I am TheRaven on Soylent News
4. Re:So how about FTPS by guruevi · 2017-09-14 03:06 · Score: 2
  
  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.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
5. Re:So how about FTPS by that+this+is+not+und · 2017-09-14 03:17 · Score: 1
  
  I download large files over HTTP using wget. You can even configure wget to ignore robots.txt.
6. Re:So how about FTPS by Leroy+Brown · 2017-09-14 03:24 · Score: 1
  
  FTPS is WORSE. The problem with FTP in general is with stateful firewalls and NAT/PAT.
  FTP is a ridiculous protocol. For FTP to work at all these days, firewalls actually need to go out of their way to snoop in on the control channel and watch for the data channel IP & port, and then use that to pre-populate the state table with an entry for the data session.
  This breaks down on a lot of firewalls if you change the control port, or if you use FTPS where the control session is encrypted and the firewall can't snoop in on the session to make it work. Instead, a common solution is to configure a large static range of ephemeral ports for the data connections that just need to be always allowed through the firewall.
  Using FTP these days makes zero sense when there are better alternatives, or as OP stated, FTP just needs to die!!
  SFTP on the other hand at least works over a single port (SSH), but has its own problems with SSH flow control fighting TCP flow control, multiplexed sessions over a single blocking TCP stream, etc.
7. Re:So how about FTPS by that+this+is+not+und · 2017-09-14 03:25 · Score: 1
  
  Google won't hire you if you're that old.
8. Re:So how about FTPS by JohnFen · 2017-09-14 03:29 · Score: 1
  
  FTP can be done using TLS and there is also SSH-FTP. FTPS is no more or less secure than HTTPS.
  True, but that doesn't fix the rest of the things that make FTP suck.
  
  Have you ever downloaded large files over HTTP?
  Who said to use HTTP? That's not the only (or even a good) alternative.
9. Re:So how about FTPS by tepples · 2017-09-14 05:24 · Score: 1
  
  Usually "academia" has loads of bandwidth including Internet2 availability. Many of my Linux distro's mirrors are .edu domains. I get a lot more than 128kbps on those downloads (usually more like 5-10 MB/s) despite having no affiliation with the university at all. How are you possibly constrained to such a low speed?
  Just a guess, but perhaps the high speeds are available only to people who have an affiliation with some university, even if not the same university. Transfers between one university and the other are fast; transfers to or from the "public" are slow.
10. Re:So how about FTPS by toejam13 · 2017-09-14 05:30 · Score: 1
  
  FTP can be encapsulated with TLS, but it is neither easy nor pretty. And the claim that it is just as secure as HTTPS depends on how you invoke FTPS.
  The most secure method is to use implicit FTPS, which uses TCP ports 989 and 990. The FTPS server immediately expects the client to negotiate TLS (ClientHello) and to stay in TLS mode. The slightly less secure method is to use explicit FTPS, which uses the traditional TCP ports 20 and 21. For that method, the FTPS client has the ability to step in (AUTH TLS, PROT) and out (CDC) of TLS mode as its likes. It is up to the server to enforce if a resource is available outside of TLS mode.
  In either method, an encrypted control channel prevents firewalls and load-balancers from eavesdropping on PORT and PASV commands, which prevents those devices from creating dynamic ACLs and NATs. Supporting Active FTPS on a firewall is ugly. Passive FTPS isn't as bad, but then you have to use source address affinity/persistence across ports to glue the control and data channels together for your load-balancer NATs/VIPs. If your client resides behind a source NAT or proxy cluster that doesn't keep their IP address locked, that persistence can break unless you use source mask larger than a /32. Even that can break if the client is load-balancing outbound connections across multiple ISPs (think mobile devices that use both WiFi and Cellular data simultaneously).
  The explicit FTPS method allows a client to revert to an unencrypted control channel after authentication, but it is only at the client's discretion. The FTPS server can't tell the client to issue a CDC command. So if your site requires it, you have to tell your users to configure their FTPS client that way.
  Lastly, SFTP is a subsystem of SSH. It is unrelated to FTPS. You're asking that browser designers and network admins add yet another protocol and port when an existing solution, HTTPS, already exists and is good enough. I have only seen SFTP used as a stand-alone product (read: not bundled with shell access) in a couple of very niche situations.
11. Re:So how about FTPS by tepples · 2017-09-14 06:35 · Score: 1
  
  The explicit FTPS method allows a client to revert to an unencrypted control channel after authentication, but it is only at the client's discretion. The FTPS server can't tell the client to issue a CDC command. So if your site requires it, you have to tell your users to configure their FTPS client that way.
  And that's a good thing. Otherwise, neither side can be sure that the file that is received is identical to the file that was sent.
12. Re:So how about FTPS by toejam13 · 2017-09-14 07:59 · Score: 1
  
  Correction: "...the FTPS server can't tell the client to issue a CCC (clear control) or a CDC (clear data) command. So if your site requires a clear control channel..."
  Stateful firewalls and load-balancers don't care if the data channel is encrypted. They only care about the control channel after authentication.
13. Re:So how about FTPS by ebvwfbw · 2017-09-15 12:49 · Score: 1
  
  Why propose ssh-ftp? You need an account. If you're doing this via chrome, you're going to be anonymous. Anyone using ftp with a real account/password needs to be made to walk through the parking lot naked. Just so they know what they're really doing... showing everything.
14. Re:So how about FTPS by guruevi · 2017-09-15 23:44 · Score: 1
  
  FTPS =/= SSH-FTP. Either way, even "anonymous" FTP is authenticated, you just authenticate with a bogus username/password.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
15. Re:So how about FTPS by guruevi · 2017-09-16 08:07 · Score: 1
  
  Some (most) people would say NAT is a ridiculous situation. The protocol isn't broken, NAT is.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
The answer is by Anonymous Coward · 2017-09-14 02:17 · Score: 2, Funny

GOPHER!
1. Re:The answer is by infolation · 2017-09-14 02:30 · Score: 1
  
  sGopher!
Could be worse by Anonymous Coward · 2017-09-14 02:22 · Score: 1

At least it's not providing a false sense of security, unlike several other protocols (those with an 's' on the end) that allow any fraudulent certificate authority to issue certificates for any domain they feel like.
1. Re:Could be worse by Seven+Spirals · 2017-09-14 02:54 · Score: 1
  
  Exactly. SSL seems to be one money grubbing corporate shill back-slapping another. It's web-of-trust requires trusting entities that nobody in their right mind could or should trust.
  
  As far as FTP goes, there is no analog to something like proftpd which has all kinds of cool options (like upload download ratios, advanced per-user chroot support, encryption, or RADIUS accounting support. You aren't going to find a WebDAV service that supports all that. It's not a valid replacement for FTP.
Bring Back ZMODEM by Anonymous Coward · 2017-09-14 02:24 · Score: 2, Funny

Make file transfers great again. Trimp 2018!
Re:About time by infolation · 2017-09-14 02:27 · Score: 2

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.)
Typical by Anonymous Coward · 2017-09-14 02:30 · Score: 1

This is typical of Google; always trying to gain CONTROL over our lives. Fortunately, I never use Chrome, and I am to the point where I am thinking of creating my own browser that enables the user to have FULL control.
Imagine...
Being able to block popups on one site but be able to enable them on another.
Blocking some sites but not others.
Enable cookies at one site, but not another.
False seeding cookies
etc. etc.
If somebody else comes up with one of these, and no not just another addon, then I will try it because I don't want to create a browser if I don't have to.
1. Re:Typical by Opportunist · 2017-09-14 02:40 · Score: 2
  
  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.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
2. Re:Typical by swillden · 2017-09-14 05:01 · Score: 1
  
  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.
  Interesting idea. It's not so certain that it would be a clear win for users, though. Inability to target ads means that ads are worth less, all else being equal. This leads advertisers to try to make their ads worth more by making them attention grabbing (bigger, brighter, blinkier, self-playing video, etc.), or to simply pay less for ad space. If they pay less for ad space, then site owners are incented to increase the amount of ad space on their sites, or else to stop depending on advertising revenue and just paywall.
  I understand the concern about online ad networks tracking users. There is a benefit to users as well as a cost, though, and you should consider how to replicate that benefit when thinking about how to eliminate the cost.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
3. Re:Typical by Opportunist · 2017-09-14 11:59 · Score: 1
  
  The benefit of more obnoxious ads is more people blocking them.
  And yes, people start doing that. "Normal" people. Not geeks. The same people that dutifully close 20 popups and error messages every time they launch a browser. The same people that do the same every time they start their machines. The same people that have a 5 by 4 inch browser window because the rest is occupied by "free" search bars.
  Can you imagine just how much you have to piss people like THAT off to make them install something? And they do! Provided the ads are bugging them enough.
  We need more obnoxious ads. To convince the hardcore error message close clickers. You and me, we won't be affected by them. We already use adblockers.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
4. Re:Typical by swillden · 2017-09-14 14:11 · Score: 1
  
  So... what's your strategy for funding the web, since you clearly want to remove all advertising from it?
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
5. Re:Typical by Opportunist · 2017-09-14 23:42 · Score: 1
  
  ISPs get money from their customers to connect them. Hosters get money from their customers to host content. What else do you need?
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
6. Re:Typical by swillden · 2017-09-15 01:22 · Score: 1
  
  ISPs get money from their customers to connect them. Hosters get money from their customers to host content. What else do you need?
  How do content producers get money to produce content? To take one specific example, who would pay for slashdot's hosting?
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
7. Re:Typical by Opportunist · 2017-09-15 11:55 · Score: 1
  
  Most likely the users. At least if the content is worth it.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
8. Re:Typical by swillden · 2017-09-15 12:22 · Score: 1
  
  Most likely the users. At least if the content is worth it.
  Which means that 90% of the content on the web will disappear, and the remainder will all be paywalled and inaccessible to many people. There's good reason to dislike advertising, but there are also extremely good reasons that it has been the primary mechanism for funding broadly-distributed content for centuries. No other approach has proven to work remotely as well.
  But, actually, none of that will happen. Instead, we'll just have an arms race between adblockers and adblocker-blockers, and the better-funded side will always be far enough ahead that most people will choose not to block, because it will prevent them from seeing much. Your proposal at the top of this thread, to randomize cookies to prevent effective tracking, would just spawn alternative tracking mechanisms. At the extreme, perhaps all sites will simply refuse visitors who aren't logged into one of their supported ad networks' tracking systems or who have an adblocker.
  Honestly, that last option may well be the best. It would make tracking opt-in rather than opt-out, and would make the value proposition clear.
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
9. Re:Typical by Opportunist · 2017-09-15 21:05 · Score: 1
  
  Then the login credentials to said ad networks will be shared. If they are tied to Facebook accounts, fake FB accounts will be generated by the dozen per nanosecond to fill the need. You build the better mouse trap and the better mouse will evolve.
  In the end, I can't say that seeing 90% of the gunk that clogs the internet vanish would be a bad thing. I do remember the internet before its commercialization. It was smaller. But the average IQ was at least double its current rate.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Why is it supported at all? by hackel · 2017-09-14 03:27 · Score: 1

Browsers should have stopped supporting FTP at least 10 years ago. We're never going to force the dinosaurs to upgrade until we stop enabling them! FTP has a proud place in the history of the internet, but it's time has long since passed, and it is time to retire the protocol, forever.
1. Re:Why is it supported at all? by belg4mit · 2017-09-15 11:23 · Score: 1
  
  Because it has its uses, especially with capable clients like ncftp. mget * is much easier and more reliable than building up a list of switches for wget.
  
  --
  Were that I say, pancakes?
Ah, publicly secure by holophrastic · 2017-09-14 03:50 · Score: 1

One day, someone will explain to me why a completely public piece of information, distributed freely to everyone everywhere, needs to be delivered securely.
In a world where FedEx drops packages at my front door, and leaves them there when I'm away.
In a world where the only thing stopping my speeding car from hitting an on-coming speeding car is a line of yellow paint.
In a world where my front door is locked with a deadbolt, right next to a glass window.
Can anyone say "overboard"? I don't need to encrypt something, and then give everyone the key.
And before someone says something technically valid like "man-in-the-middle", remember that https doesn't stop the man-in-the-middle, it only stops some of the men-in-the-middle, and not most of them.
1. Re:Ah, publicly secure by green1 · 2017-09-14 04:06 · Score: 1
  
  This has been the big thing with security all along. As long as you are fine with HTTP, why wouldn't you be fine with FTP?
  Not everything needs to be secure.
  Next time I drive by a billboard on the side of the highway it better be encrypted so I can't read the ad without some security certificates on my end!
  That said, browsers have always been positively HORRIBLE FTP clients, so if people decide to use FTP clients instead of browsers to use FTP sites, it's not really a huge loss.
2. Re:Ah, publicly secure by JesseMcDonald · 2017-09-14 04:18 · Score: 1
  
  One day, someone will explain to me why a completely public piece of information, distributed freely to everyone everywhere, needs to be delivered securely.
  Because, while the information is public, the fact that you requested it should be private. Even seemingly innocuous requests can reveal personal information which can be used against you, regardless of whether you are doing anything "wrong". Limiting how much strangers know about you is a powerful first line of defense: a form of social camouflage.
  Because you need to be able to trust that the information is from the expected source and hasn't been tampered with in transit. This is particularly true when the information may contain executable code—which is almost everything these days—but even theoretically non-executable data could be manipulated to exploit a bug in the receiver.
  
  --
  "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
3. Re:Ah, publicly secure by Todd+Knarr · 2017-09-14 06:14 · Score: 1
  
  Answer: third parties. Do you want anyone who can see the traffic to be able to insert themselves into the traffic flow and alter what you're receiving? Because that's what can happen with unencrypted traffic. And while it might not be easy to do that at the level of say the backbone routers, it's really easy for someone to hack the WiFi router at a coffee shop and install a transparent proxy to hijack downloads and replace them with malware. In fact, if you make regular use of public WiFi access, the hijacker may be the router's owner for all you know.
4. Re:Ah, publicly secure by JesseMcDonald · 2017-09-14 06:26 · Score: 1
  
  Who said anything about unsigned .deb packages? The web page you're reading contains executable code (JavaScript). If you browse the Web with JS enabled, like a normal person, then you need to be careful about provenance of the HTML and JS files which make up the pages. They run in a sandbox, true, but that doesn't prevent all issues (e.g. ad injection, tracking, cross-site attacks) and there is always the possibility of an exploit which can escape the sandbox. As a content provider, if you want people to be able to trust your site you'll deliver it over HTTPS.
  
  --
  "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
5. Re:Ah, publicly secure by Hognoxious · 2017-09-14 07:11 · Score: 1
  
  Obligatory car analogy.
  
  --
  Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Anonymous SSH by tepples · 2017-09-14 05:11 · Score: 1

To what extent do common clients and servers for SSH, the session protocol underlying SFTP, support sessions that do not require authenticating with a username and password or username and public key?
HTTP PUT by tepples · 2017-09-14 05:14 · Score: 1

Uploads through the POST method require a server-side script. But I thought a server could handle the PUT method by itself.
1. Re:HTTP PUT by corychristison · 2017-09-14 06:06 · Score: 1
  
  By default, no. You need DAV enabled. On Apache that's mod_dav, and on nginx it's HttpDavModule.
2. Re: HTTP PUT by tepples · 2017-09-14 06:27 · Score: 1
  
  And then every malware bother will use your HTTP server with a PUT enabled to distribute itself.
  401 Authorization Required
3. Re:HTTP PUT by tepples · 2017-09-15 00:47 · Score: 1
  
  A failed WebDAV PUT can be resumed with a second PUT specifying a Content-Range.
PASV by tepples · 2017-09-14 05:18 · Score: 1

a system that requires multiple ports with connections established in different directions
A data connection established with PORT does go in the opposite direction of the control connection. But I thought PASV, which runs both connections in the same direction and cooperates better with NAT, had become more common. The exception is so-called "FXP" transfers from one server to another, where the client opens control connections to two servers and sends PASV to one and PORT to the other in order not to have to bounce a file off a residential last mile.
1. Re:PASV by thegarbz · 2017-09-14 05:56 · Score: 1
  
  But I thought PASV, which runs both connections in the same direction and cooperates better with NAT, had become more common.
  It has, and brought it's own problems with it. But you highlighted my point well. Active, passive, one port, two ports, server to server FXP, and all of this is apparently "simple", where in reality its a damn complicated protocol with a lot of intricacies which has been extended and hacked about many times over the years.
2. Re:PASV by tepples · 2017-09-14 06:30 · Score: 1
  
  There still exists a subset of FTP that's simple to support if the server operator doesn't need FXP functionality, namely PASV-only. Or is FXP too important in practice to consider it expendable?
Wget is a download manager by tepples · 2017-09-14 05:26 · Score: 1

you practically need a download manager because the browsers will just choke
I download large files over HTTP using wget.
True, GNU Wget offers more robust resume support than a web browser. But it illustrates guruevi's point because it's a download manager, not a browser.
1. Re:Wget is a download manager by that+this+is+not+und · 2017-09-14 07:47 · Score: 1
  
  A 'download manager'? That sounds like one of those derpy graphical FTP clients. Wget is a mirroring utility.
2. Re:Wget is a download manager by tepples · 2017-09-14 10:02 · Score: 1
  
  What would the CLI counterpart to said derpy clients look like? I imagine not unlike Wget.
3. Re:Wget is a download manager by guruevi · 2017-09-15 00:10 · Score: 1
  
  The problem with HTTP is that range requests are a bit of a hack, there is a huge amount of protocol overhead and it does not work universally especially since there is no universal session state mechanism in HTTP, so when your session expires, often so does your download.
  
  --
  Custom electronics and digital signage for your business: www.evcircuits.com
MITM can alter the hash by tepples · 2017-09-14 05:39 · Score: 1

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
If you transmit the hash in the clear, a man in the middle can alter the hash in transit.
1. Re:MITM can alter the hash by RightwingNutjob · 2017-09-14 06:16 · Score: 1
  
  True. However:
  
  There are many use cases where the a security signature or certificate needs to be transmitted once and the data transmitted orders of magnitude more times. In which case, the computational overhead of establishing an encrypted channel needs to be accepted infrequently and for a relatively small payload instead of every time for a large payload.
  
  There are many use cases where the key distribution mechanism isn't over the internet at all.
  
  There are use cases where you really honestly don't care if the cat video you're getting to kill time is authentic or not.
  
  And lastly, there's a human factors dimension to this as well. People who see an encrypted channel will on occasion take that as a license to ignore good software engineering practices elsewhere. That's a problem.
2. Re:MITM can alter the hash by tepples · 2017-09-14 06:32 · Score: 1
  
  There are use cases where you really honestly don't care if the cat video you're getting to kill time is authentic or not.
  But you do care whether the operating system UI presented after the conclusion of the cat video is authentic and not a phishing attempt.
3. Re:MITM can alter the hash by RightwingNutjob · 2017-09-14 06:50 · Score: 1
  
  That's a failure on the part of the browser/website/OS designer if it's possible to spoof a UI image convincingly in a video.. You can just as easily spoof a UI image over an encrypted channel as you can over a cleartext channel.
4. Re:MITM can alter the hash by Strider- · 2017-09-14 07:53 · Score: 1
  
  There are many use cases where the a security signature or certificate needs to be transmitted once and the data transmitted orders of magnitude more times. In which case, the computational overhead of establishing an encrypted channel needs to be accepted infrequently and for a relatively small payload instead of every time for a large payload.
  A prime example of this is software updates. From Microsoft, from Apple, from whomever. Everyone should be keeping their systems as up to date as possible. That said, the downloads for these updates are huge, so leaving them in the clear allows transparent caching infrastructure to work properly. What about a MITM attack on the binaries? Well, you can resolve that by making the control link from update service to the update client HTTPS, and including sha256 checksums in the system to verify the cleartext download.
  Yes, it's an edge case, but I run a network with about 100 users at a remote site, on the far end of a satellite link. For our corporate machines, we run our own internal WSUS, but for personal computers, they still need to update. Because Microsoft sends the body of the updates in cleartext, my WAAS system actually does a really good job of caching the updates, even for our non-domain users. If Microsoft were to go to SSL only, every patch Tuesday would wind up taking 2 weeks to complete and render the network virtually useless.
  
  --
  ...si hoc legere nimium eruditionis habes...
Re:what about HTTP by tepples · 2017-09-14 05:40 · Score: 1

Marking cleartext HTTP as "not secure" is actually the eventual plan, as I understand blog posts by Google, Mozilla, and DigiCert. First documents delivered over HTTP containing a password form was marked not secure. Then documents delivered over HTTP containing any forms. Then documents delivered over HTTP containing scripts. And finally, all documents delivered over HTTP other than from localhost.
Re:Google recording the URLs you visit by tepples · 2017-09-14 05:43 · Score: 1

Why does Google know the number of visits to FTP servers from Chrome ?
Because Chrome users have opted into sending anonymous coverage data to Google in exchange for Google developers not deprecating and removing features that the users use on grounds that nobody uses them.
Re:Mozilla or Chrome by tepples · 2017-09-14 05:44 · Score: 1

It would seem that the only unsecure bit of an ftp download would be some asshole manipulating packets at a router somewhere down the line. That should be illegal anyway, imagine if they did that with TV.
Cable TV operators already replace a small number of commercials per hour per their retransmission contracts with the networks. You can tell this is happening on (say) The Weather Channel because the crawl at the bottom disappears.
Re: what about HTTP by Anonymous Coward · 2017-09-14 05:59 · Score: 1

It's also ass-backwards. Do I need to watch cat videos over SSL? No. But it insists on SSL and cuts the battery life down by doing so. Not to mention destroys caching and consumes more power on the server too.
Forcing SSL everywhere also screws up the trust model of looking for the SSL indicator, since shitty phishers just register paypal-fraud.cn and give it a ssl cert or push it over cloudflare.
STARTTLS stripping by tepples · 2017-09-14 06:22 · Score: 1

Modern FTP clients and servers support STARTTLS as a command to initiate TLS
Unless the ISP intercepts the STARTTLS command sent by the client and turns it into a garbage command that produces a 502 Method Not Supported response, fooling the client into thinking the server doesn't support TLS. This has happened, Ars Technica has reported on it, and there's even a proof of concept in PyPI. What's FTP's counterpart to HSTS?
1. Re:STARTTLS stripping by tepples · 2017-09-14 10:00 · Score: 1
  
  Unless the server sincerely doesn't support STARTTLS. Without some counterpart to HSTS, how is a client supposed to distinguish a server that doesn't support TLS from one that does but is behind a proxy that changes "Send a STARTTLS command first" to "Send a XXXXXXXX command first"?
What follows the cat video? by tepples · 2017-09-14 06:25 · Score: 1

Do I need to watch cat videos over SSL?
TLS ensures that you're watching only the cat video, not the cat video followed by an ad inserted by a man in the middle, nor the cat video followed by a full-screen phishing form inserted by a man in the middle.
1. Re:What follows the cat video? by K.+S.+Kyosuke · 2017-09-14 09:20 · Score: 1
  
  not the cat video followed by an ad inserted by a man in the middle
  And how do you know it's not a cat in the middle?
  
  --
  Ezekiel 23:20
Enjoy looking at paywall notices by tepples · 2017-09-14 06:38 · Score: 1

The biggest benefit I can think of would be for all of the advertisers to join all of the lawyers at the bottom of the ocean.
That won't work in practice for one simple reason. Publishers will sw...
To read the rest of this comment, log in to your comments by tepples account or subscribe to comments by tepples.
1. Re:Enjoy looking at paywall notices by Opportunist · 2017-09-14 12:01 · Score: 1
  
  (close window)
  (choose next result in google)
  (add the page to my "-site:..." search string list)
  Another addon I'd like: Something that automatically adds "-site:..." to every google search string to weed out clickbaiters.
  
  --
  We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Know your sender by tepples · 2017-09-14 06:59 · Score: 1

You can just as easily spoof a UI image over an encrypted channel as you can over a cleartext channel.
With an encrypted channel, the browser has a fully qualified domain name with which to associate all images transmitted over that channel. With an unencrypted channel, the browser can't tell what domain has injected the images.
1. Re:Know your sender by RightwingNutjob · 2017-09-14 10:09 · Score: 1
  
  Except we aren't talking about performing secure transactions inside a browser window. We're talking about transferring files with FTP.
2. Re:Know your sender by tepples · 2017-09-14 10:20 · Score: 1
  
  The MITM could insert malicious code into files transferred through FTP. Even if the file looks like a video, several video containers such as WMV have contained functionality to download DRM code to obtain a license needed to decrypt the video in the WMV file. This functionality can be and has been used for dropping trojans.
3. Re:Know your sender by RightwingNutjob · 2017-09-14 11:01 · Score: 1
  
  You're running away with your examples. Streaming video (as in the raw bits and bytes that turn into pixels on the screen) does not need to be encrypted unless it's video of something you don't want to send in the clear. If you're executing any of those bits and bytes, that's on you for having a fundamentally insecure media player.
4. Re:Know your sender by tepples · 2017-09-14 11:13 · Score: 1
  
  Or unless it's a video whose publisher doesn't want it sent in the clear to be viewed by other people who haven't paid for it.
Re:Bullshit by JesseMcDonald · 2017-09-14 09:52 · Score: 1

The way to do this is with digital signatures. You have no idea if the source server has been compromised.
Digital signatures (HMAC) are part of HTTPS. They're automatically generated on demand, so not quite as good as a manual signature generated offline after careful examination of the content and verified after every download by the end user with a proper web of trust—but still better than nothing and no worse than any other signature generated on the server itself. They at least prove that the content did originate from a system authorized to sign it on behalf of the administrator. Whether or not you can trust the server to remain under the administrator's control is a separate matter.
From the server operator's point of view, you always want to use HTTPS because you will be blamed either way for any malware people receive while visiting your site. Even if you offer signatures, which isn't a very practical solution for most of the Web. You can police your own server; you can't control what others might inject into the traffic if the connection is unsecured.

--
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat