back to article Get the FTP outta here, says Firefox

Mozilla developers have decided to block requests for File Transfer Protocol (FTP) subresources inside web pages. A bug report and Intent to implement notice suggest the change will land in Firefox 61. The browser’s currently at version 59, with 61 due in May 2018. The change will permit access to FTP resources in hyperlinks …

  1. Anonymous Coward
    Anonymous Coward

    pardon, me ignorant

    I use FTP all the time to upload/download from my server, android. What I am supposed to be using instead?

    1. Hstubbe

      Re: pardon, me ignorant

      Scp or sftp, i'm sure there's android clients for those. But you can continue to use the legacy and insecure (your password is sent over the wire unencrypted, as are sll your files) ftp, this article only says that websites that pull, let's say, their images in over ftp (instead of http/https which is used by 99.9999999999999999999999999% of the sites) are going to break. This is independent of whether those images have been uploaded over ftp or not.

      1. Anonymous Coward
        Anonymous Coward

        Re: pardon, me ignorant

        You can use TLS with FTP as well, with no need to use SSH.

        Anyway, pulling a file via FTP or HTTP (without an S) has the same security.

      2. Anonymous Coward
        Anonymous Coward

        Re: pardon, me ignorant

        There is both FTP/S and FTP-TLS, which perfectly secures FTP. vsftpd supports both.

    2. Akko

      Re: pardon, me ignorant

      "The change will permit access to FTP resources in hyperlinks or when an FTP server’s address is entered into Firefox’s address bar, but the browser will no longer allow FTP resources to be summoned using the HTML src attribute."

      Do you use the HTML src attribute for that? If not, nothing changes for you. If yes, why the hell?

      1. bombastic bob Silver badge
        Devil

        Re: pardon, me ignorant

        "Do you use the HTML src attribute for that? If not, nothing changes for you. If yes, why the hell?"

        well, if you're a MALWARE author, and you ftp'd your malware crap onto someone's server (after cracking it) and NOW have an FTP URL to it in an HTML element, then MAYBE your malware load will break.

        Yeah, TOO! BAD!!!

    3. JohnFen

      Re: pardon, me ignorant

      You can continue to use FTP (although you really should shift to something better when you can). Firefox is not blocking your use of FTP at all -- you can still use it as an FTP client. It's blocking the ability for web pages to load resources themselves via FTP.

    4. katrinab Silver badge

      Re: pardon, me ignorant

      I use webdav, scp or rsync over ssh.

      1. Astara

        Re: pardon, me ignorant

        I prefer SMB or CIFS myself...

        :-| (str8-face)

  2. really_adf

    Reasons?

    Refusing to load http subresources from an https page makes sense, and it is logical to apply that rule to ftp subresources from an https page. Apparently this is already the case.

    But I don't see the reason or benefit to block ftp subresources in general. Following links from the article, removing FTP support is mentioned as a possible eventual goal, and I don't have a problem with that, but I don't see this change being a step in that direction.

    1. Anonymous Coward Silver badge

      Re: Reasons?

      A possible reason is speed.

      With all resources loaded over HTTP(s), the browser can use keep-alive to re-load multiple resources over the same connection. If there's a mix of HTTP and FTP, it will have to establish more connections.

      1. Dan 55 Silver badge

        Re: Reasons?

        So what?

        Presumably an agile Web 3.0 node jquery Frankenstein-like monstrosity of a website won't be serving stuff from ftp, but there are sites that do.

        The point of the web was to make data accessible, not try to heroically re-create desktop software, fail, and prompt browser manufacturers to throw out everything to achieve that dubious aim. As long as a page served with an 's' protocol doesn't pull in stuff with non-'s' protocols and a remote page doesn't pull in stuff from local hard drive, what's the problem?

        1. JohnFen

          Re: Reasons?

          "The point of the web was to make data accessible, not try to heroically re-create desktop software"

          This.

          Unfortunately, the major browser manufacturers (and the HTML5 standard) disagrees with us.

        2. Anonymous Coward
          Anonymous Coward

          Re: Reasons?

          And by the Web 3.0 jquery Frankenstein-like monstrosity of a website already has to download 20MB of crap just to display basic HTML, so the speed delay caused by using FTP is already blown anyways!

  3. Dan 55 Silver badge

    "FTP sends data as plaintext and just wasn’t designed for the modern web"

    1. Of course it does binary.

    2. It doesn't matter where you pull files in from or what protocol it uses (cross-origin and non-secure/secure protocol policies not withstanding). That was the point of the web in the first place.

    Can we file this one on the "Oh FFS Mozilla" pile.

    1. Anonymous Coward
      Anonymous Coward

      Re: "That was the point of the web in the first place."

      Precisely. And the WWW was built using HTTP, not FTP nor Gopher. Allowing its use in such a way was arguably a design flaw in the first place.

      1. W.O.Frobozz

        Re: "That was the point of the web in the first place."

        Uh you realize what the "U" in URL means right? Universal. The web was designed to pull all these protocols together. It was not a "design flaw" at all.

    2. Steve the Cynic

      Re: "FTP sends data as plaintext and just wasn’t designed for the modern web"

      1. Of course it does binary.

      "Plaintext" means "NOT encrypted", as opposed to ciphertext, which means "encrypted". It has nothing to do with the text/binary switch in FTP.

      1. Dan 55 Silver badge
        WTF?

        Re: "FTP sends data as plaintext and just wasn’t designed for the modern web"

        @AC: No, HTML didn't and arguably still shouldn't favour any protocol. If you're saying HTML should favour HTTP(S), what happens when the next great protocol comes along?

        @Steve: So a non-encrypted http page can't pull in stuff from non-encrypted ftp sites because security?

        1. Steve the Cynic

          Re: "FTP sends data as plaintext and just wasn’t designed for the modern web"

          @Steve: So a non-encrypted http page can't pull in stuff from non-encrypted ftp sites because security?

          I said nothing one way or the other about that. I wouldn't cite, as such, security as a reason to avoid that, since the browser will normally use "anonymous" FTP (username = "anonymous" OR "ftp", password = email address) if it has to transfer anything over FTP.

          However, there is a performance issue - if the "cited" item comes from the same server *by HTTP* as the non-encrypted citing page that was also fetched by HTTP, then the browser can (if using HTTP/1.1) reuse a connection, but if the cited item is FTP, it can't.

          1. Dan 55 Silver badge

            Re: "FTP sends data as plaintext and just wasn’t designed for the modern web"

            Well you did talk about encryption and I answered...

            If performance is an argument for not allowing pages to pull in stuff from FTP, we might as well shut down HTTP/1.0 because it's too slow too.

            The important thing is to make the data accessible, but it seems lately that's deemed unimportant.

          2. Anonymous Coward
            Anonymous Coward

            Re: "FTP sends data as plaintext and just wasn’t designed for the modern web"

            Even still, most browsers support up to 10 connections at once anyways, so the performance penalty for using FTP is fairly minimal, except for possibly the multiple CWD commands..

  4. simmondp

    TFTP is better

    If you need to FTP files, then TFTP is much better!

    At least then you know and are aware that there is no security and no user-name/password and thus (hopefully) need to put a security wrapper around anything you transfer.

    So for example: and AES-256 Password encoded ZIP file - sent over TFTP.

    1. Anonymous Coward
      Anonymous Coward

      Re: TFTP is better

      TFTP was designed with small networks in mind for cheap devices on the same LAN to load what they needed at boot time. A student project I supervised found a previously unpublished buffer overflow vulnerability in a popular TFTP server. I'm glad to say the student published it as a Metasploit module so it's not a zero day any longer, but it could just as easily have become one. FTP was designed for wide area networks so has been subject to much more thorough code review. Also TFTP is likely to live inside many embedded devices which don't get automatically updated when the developer who probably no longer cares learns about a vulnerability. So a hacker who has compromised a host inside the LAN and wants to compromise other hosts there is likely to be looking for unpatched TFTP hosts as these deliver software to other hosts on the LAN, as well as being likely to offer other LAN services useful to them.

      1. Mike 16

        Re: TFTP is better

        I suspect that an installation that does not have a chrooted TFTP server probably has bigger problems.

        Not to mention that having an intruder on my LAN is probably of higher priority than protecting against someone who wants to _read_ a copy of the firmware for bespoke lab instruments.

      2. Jove Bronze badge

        Re: TFTP is better

        Or sftp if you are still doing it by hand.

  5. sawatts

    Still waiting for the gopher revival...

    1. Jove Bronze badge

      Don't wait, join in; there is even rumour of a Gopher interface for Docker in the pipeline.

  6. teknopaul

    More firefox news , more things that dont work.

    Probably wont affect many users but disabling ftp is not going to win them any users is it?

    1. Anonymous Coward
      Anonymous Coward

      I don't think you read the article properly... I'll summarise for you:

      - EMBEDDED <src="ftp://foo.bar.com/xxxx.jpg"> references to FTP:// resources is going to be disallowed, as this is not only a shoddy way of linking to images but also INSECURE (And rightly so).

      - Typing ftp://username:password@foo.bar.com/ will continue to work perfectly, as it always has.

      1. Anonymous Coward
        Anonymous Coward

        Yes, it's INSECURE and the page it's called from is INSECURE too as only http pages can pull in ftp resources. So disallowing on the grounds of it being INSECURE it is stupid.

  7. jms222

    Gopher

    Does Gopher still work ?

    1. JohnFen

      Re: Gopher

      Yes.

  8. Muscleguy

    Fetch

    As an oldie I can confirm that FTP preceded the web. Time was FTP site addresses were shared on email Lists and Usenet. On the Mac we had Fetch, an FTP browser and agent, you pointed it at a site and the files available were listed for your perusal and download.

    That was how shareware was distributed back in the day. I'm pretty sure I got Exile 1 via FTP (now it's Avernum of course.

    1. Anonymous Coward
      Anonymous Coward

      Re: Fetch

      I first became aware of the existence of the Internet sometime in the mid eighties I looked at the /etc/hosts file on a Unix box we were using on our yellow coax Ethernet LAN and saw the pre-DNS mappings of a couple of thousand hostnames to IP4 addresses. We were using telnet and FTP software over local TCP/IP then nearly a decade or so before the first webserver and http clients were available.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like