Removing FTP support too

Posted Apr 19, 2021 22:19 UTC (Mon) by james (subscriber, #1325)
In reply to: Removing FTP support too by hummassa
Parent article: Firefox 88.0 and 78.10 ESR

If there is a password: there wouldn't be for anonymous FTP.

On the other hand, FTPS (FTP over TLS) is a thing, but the browser probably isn't the best client for it. And SFTP (from the SSH suite) is normally a better choice.

Removing FTP support too

Posted Apr 19, 2021 22:32 UTC (Mon) by corbet (editor, #1) [Link] (1 responses)

Traditionally, in the Good Olde Days, anonymous FTP did indeed request a password; it was considered polite to provide your email address. But that was a different and rather more innocent time...

Removing FTP support too

Posted Apr 20, 2021 4:17 UTC (Tue) by rsidd (subscriber, #2582) [Link]

Those days are still around if you use the command line, eg for UCSC genome data. (But FTP is deprecated. And, of course, there's no check on the email address.)

$ ftp hgdownload.soe.ucsc.edu
Name: anonymous
Password: <your email address>
ftp> cd goldenPath
ftp> cd <assembly name> (e.g., hg19)
ftp> cd <data directory> (e.g., liftOver)

FTPS should die even quicker than FTP

Posted Apr 20, 2021 12:41 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (1 responses)

Minor rant. FTPS is really bad. Really, really bad.

As most of you know, FTP uses two TCP connections, one for the protocol itself and one for the data. Whenever a file is retrieved or sent the second connection is opened for that transfer. As most clients nowadays cannot be contacted by the server (which is what FTP's default "active" mode does), FTP clients connect to the server for the data connection, too (the "passive" mode, this is what all browsers implement).

The IP address[1] and port number to connect to are transmitted via the control channel. As the port numbers aren't fixed, any firewall or NAT device sitting in front of the server would have to parse the FTP control channel messages & temporarily open or forward ports for the connection to work.

Guess what doesn't work if the control channel is encrypted.

This means that either you'd have to open/forward quite a range of TCP ports on the FTP server's side (depending on how many concurrent transfers you wanted to support), or you simply couldn't run an FTPS server behind a NAT device. And all of that is a bitch to understand and debug even for experienced admins; now imagine how easy it was to support regular users with problems in their FTP transfer.

And the cherry on top? You could have fun configurations such as the control channel being encrypted but the data channel being cleartext, resulting in your password being protected but your "get credit_card_data.csv" being transmitted in the clear. Yay!

[1] You could initiate a three-way file transfer between two servers by connecting with a client to server A & B, then tell server A to listen & server B to connect to whatever port server A told you

FTPS should die even quicker than FTP

Posted Apr 21, 2021 12:39 UTC (Wed) by Lennie (subscriber, #49641) [Link]

I'm also not a fan of FTPS, but what seems to be the the solution these days, use the IANA port range for passive, which is also listed for example here:

http://proftpd.org/docs/directives/linked/config_ref_Pass...

That way no firewall support needed to look into the control protocol.