Firefox 88.0 and 78.10 ESR

[Posted April 19, 2021 by ris]

Firefox 88 has been released. New features include support for PDF forms with embedded JavaScript and smooth pinch-zooming using a touchpad, and better protection against cross-site privacy leaks. See this article for more information on how Firefox 88 combats window.name privacy abuses.

Firefox 78.10 ESR contains various fixes for stability, functionality, and security.

Removing FTP support too

Posted Apr 19, 2021 18:01 UTC (Mon) by Duncan (guest, #6647) [Link] (21 responses)

From the Mozilla announcement:

"FTP support has been disabled, and its full removal is planned for an upcoming release. Addressing this security risk reduces the likelihood of an attack while also removing support for a non-encrypted protocol."

I'd have really expected that to make the chosen quote on a technically-oriented site such as LWN.

I realize and support the move to encrypted protocols in general, but is FTP really that far gone? In the interest of security I might have expected (and would definitely support), say, the same sort of "Insecure!" warning hoops they do for instance with my router's self-signed https cert, which is to say a somewhat higher level of pain than the simple "unencrypted" warning I get now with plain http sites, since I have the https-only option turned on (and was in fact defaulting to https via extension for a couple years before the functionality was built-in), but disabling FTP support by default in preparation for removal in I suppose a couple releases is still, IMO, arguably a bit strong.

Removing FTP support too

Posted Apr 19, 2021 20:55 UTC (Mon) by iabervon (subscriber, #722) [Link] (7 responses)

I think the security aspect is that there's a risk of bugs in the protocol implementation, due to it being a lot more complicated than the HTTP protocol and a lot less used.

Removing FTP support too

Posted Apr 19, 2021 21:40 UTC (Mon) by hummassa (subscriber, #307) [Link] (5 responses)

In the FTP protocol, IIRC, the password transits in the clear.

Removing FTP support too

Posted Apr 19, 2021 22:19 UTC (Mon) by james (subscriber, #1325) [Link] (4 responses)

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.

Removing FTP support too

Posted Apr 20, 2021 0:09 UTC (Tue) by interalia (subscriber, #26615) [Link]

I don't use browsers as FTP clients very often, but I find this a bit disappointing myself. I don't think FTP as a protocol is more complex than what HTTP has evolved to be, what with content negotiation, caching, pipelining and so on. Objectively it won't hurt me that much because I only use it rarely, but it feels to me that it's long-standing code that would probably have been exploited already if that was likely.

Removing FTP support too

Posted Apr 19, 2021 23:51 UTC (Mon) by flussence (guest, #85566) [Link] (3 responses)

It's probably better right now to just use gvfsd-fuse; it works transparently in every program, you also get a dozen other network protocols for free, and it's maintained by people who actually want those features. If that's insufficient then Chrome's upcoming raw socket API will cater to the need (and presumably a day one extension for FTP, no doubt there'll be ones for gopher and gemini too.)

Removing FTP support too

Posted Apr 20, 2021 0:34 UTC (Tue) by pabs (subscriber, #43278) [Link] (2 responses)

A raw socket API sounds like a security problem, wouldn't that let you bypass HTTP origin restrictions?

Removing FTP support too

Posted Apr 20, 2021 4:22 UTC (Tue) by calumapplepie (guest, #143655) [Link] (1 responses)

That certainly seems to be Mozilla's position:

https://github.com/mozilla/standards-positions/issues/431

It's not really an upcoming feature, just a proposed spec. We'll see how it winds up.

https://www.chromestatus.com/feature/6398297361088512

Removing FTP support too

Posted Apr 20, 2021 21:40 UTC (Tue) by flussence (guest, #85566) [Link]

I assume it'd be a thing that carries heavy warnings and opt-in consent interstitials, in the same way downloading a random .exe on windows and running it does.

Removing FTP support too

Posted Apr 20, 2021 1:25 UTC (Tue) by rra (subscriber, #99804) [Link] (1 responses)

FTP is kind of a dire protocol. Apart from the lack of transport security, there's the separate control and data channels leading to the whole PASV/PORT mess, which is challenging to firewall or support in a reasonable way. But, for the client, presumably they're worried about an active in-path attacker serving you malware down an FTP link, which is fairly trivial to do given the lack of integrity protection.

I'm not sure if it's worse than HTTP (it may be because of the PASV/PORT stuff, but it may not be), but unlike HTTP it's also become extremely rare, so it's easier to justify cutting off the attack surface.

Removing FTP support too

Posted Apr 20, 2021 2:54 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

It's definitely a worse *trade* than HTTP. You get lots of really nice features you (or someone like you) wanted in exchange for all that complexity in HTTP. In FTP you get a... pretty mediocre file transfer protocol which enables some weird things nobody has wanted to do for decades (like a separate mode for text files in case your operating system treats them differently or the ability for one party to transfer data from a second party to a third party) but it has lots of complexity that somebody has to implement.

If you actually have the FTP use case then HTTP is very obviously what you wanted since the 1990s. If you have a bunch of named files available, HTTP can serve them up. If now that you think about it, integrity, or confidentiality are worth something to you, then HTTPS is barely any extra effort on top of that.

Removing FTP support too

Posted Apr 20, 2021 7:04 UTC (Tue) by taladar (subscriber, #68407) [Link]

FTP is a 50 year old protocol that

* transmits passwords, commands and data in the clear
* is a pain to get through firewalls (pretty much requires a stateful firewall with connection tracking to work at all)
* is underspecified (e.g. format of ls output)
* does not support name-based virtual hosting

It is time to turn its undead shambling corpse and let it rest in peace.

Removing FTP support too

Posted Apr 20, 2021 8:17 UTC (Tue) by epa (subscriber, #39769) [Link] (5 responses)

It's amazing that HTTP doesn't have a standard way to get a directory listing. That would replace 99% of the uses of FTP.

Removing FTP support too

Posted Apr 20, 2021 9:11 UTC (Tue) by joib (subscriber, #8541) [Link] (2 responses)

My understanding is that FTP doesn't specify the output format of the ls command either. It's not structured data, it's just a string the server sends to the client. I guess the original implementation was to just pipe the output of ls on the server side over the wire. Later implementation presumably do their best to emulate ls output on whatever ancient unix was first used.

So in practice it's as much of a defacto standard as HTTP servers autogenerating a directory listing. In practice this works well enough, e.g. lftp can provide a "ftp-like" command-line experience even though the underlying protocol is HTTP(S) rather than FTP. Try for instance "lftp http://kernel.org/pub"

Removing FTP support too

Posted Apr 20, 2021 10:17 UTC (Tue) by grawity (subscriber, #80596) [Link]

The original LIST indeed doesn't. Many FTP servers however now support MLSD which is structured in a standard way.

Removing FTP support too

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

Today I learn that this exists!

Removing FTP support too

Posted Apr 20, 2021 18:37 UTC (Tue) by mss (subscriber, #138799) [Link]

There is PROPFIND in WebDAV, although this technically isn't raw HTTP.

Removing FTP support too

Posted Apr 20, 2021 21:58 UTC (Tue) by flussence (guest, #85566) [Link]

I remember scrolling through the MIME type list in KDE 3 out of boredom and seeing references to directory and inode types there. Of course they're only internal pseudo-types for the file browser to use, but wishful thinking...