Slashdot Mirror


Mozilla Restricts All New Firefox Features To HTTPS Only (bleepingcomputer.com)

An anonymous reader shares a report: In a groundbreaking statement earlier this week, Mozilla announced that all web-based features that will ship with Firefox in the future must be served on over a secure HTTPS connection (a "secure context"). "Effective immediately, all new features that are web-exposed are to be restricted to secure contexts," said Anne van Kesteren, a Mozilla engineer and author of several open web standards. This means that if Firefox will add support for a new standard/feature starting tomorrow, if that standard/feature carries out communications between the browser and an external server, those communications must be carried out via HTTPS or the standard/feature will not work in Firefox. The decision does not affect already existing standards/features, but Mozilla hopes all Firefox features "will be considered on a case-by-case basis," and will slowly move to secure contexts (HTTPS) exclusively in the future.

23 of 243 comments (clear)

  1. Loyal Firefox user for over a decade now. by fishscene · · Score: 5, Insightful

    ...and this might be the one thing that gets me off the Firefox bandwagon as it is an incredibly backwards move. TONS of stuff does NOT need https and does not need the overhead HTTPS incurs both in processing time and certificate management. Also, do I really need HTTPS for stuff on my trusted LAN? No? So now I have to jump through hoops to enable developer mode? Just... what are they thinking? What is the recommended fork of Firefox these days? Pale Moon?

    1. Re:Loyal Firefox user for over a decade now. by QuietLagoon · · Score: 4, Interesting

      ...Just... what are they thinking?...

      Who knows if they are even thinking at all. The crowd that currently appears to be in charge at Mozilla seems to have a really strange perception of what the Firefox users want, and a strange perception of security. Yesterday I tried to log into the Mozilla site, but I was not allowed to because I would not let Mozilla persistently store tracking data on my PC. I allowed session cookies, but that wasn't good enough for them. Apparently they wanted access to offline web content storage.

    2. Re:Loyal Firefox user for over a decade now. by Eravnrekaree · · Score: 3, Interesting

      The LAN issue is an interesting one, maybe Firefox should make an exception for the private IP addresses ranges. That would be reasonable. On the other hand, I am all for HTTPS for everything else, even eventually dropping non-SSL support altogether.

    3. Re:Loyal Firefox user for over a decade now. by Obfuscant · · Score: 2, Insightful

      The LAN issue is an interesting one, maybe Firefox should make an exception for the private IP addresses ranges.

      You do realize, I hope, that "private IP address ranges" are in the eye of the beholder. Yes, there is a standard set, but if I want to treat 123.123.0.0/16 as "private" there is nothing you can do to stop me.

      On the other hand, I am all for HTTPS for everything else

      Then you are free to run all your websites using HTTPS only. I run several websites, and not a single one of them needs HTTPS for anything. One of those is for one of those awful universities that gets grant money to do research and then keeps the data secret -- by publishing it on an open website for anyone who wants to look at it. I don't get paid to do this, so I don't get paid to manage certificates because someone gets a bug about how insecure it is to come look at my public data using an unencrypted protocol. OMG, a MITM might substitute fake data! How awful!

    4. Re:Loyal Firefox user for over a decade now. by dryeo · · Score: 2

      Well Slashdot broke on my dial-up connection when it switched to HTTPS (pages hardly ever fully loaded) as well as a lot of pages suddenly needing reloaded. You depend on the cache a lot more with a 26.4 KBs connection.
      Then there is the issue of small timers who want to serve a web page from home, using an old computer and dynamic hostname. Seems like another move to make sure that only large companies can serve content on the internet.

      --
      https://en.wikipedia.org/wiki/Inverted_totalitarianism
    5. Re:Loyal Firefox user for over a decade now. by dremon · · Score: 2

      HTTPS is not enforced for browsing the normal web sites but for the browser features (like WebRTC for example). Just read the article before complaining.

    6. Re:Loyal Firefox user for over a decade now. by viperidaenz · · Score: 2

      if I want to treat 123.123.0.0/16 as "private" there is nothing you can do to stop me

      And when your routing table has a hiccup, there's nothing to stop your "private" request being sent to Chinese servers.
      123.112.0.0 - 123.127.255.255 is owned by China Unicom

  2. Re:Good by Anonymous Coward · · Score: 2, Insightful

    STOP POSTING WITH YOUR IPHONE

  3. Re:In a groundbreaking statement now by Rick+Schumann · · Score: 2

    As opposed to what, exactly? Chrome, which almost certainly has as much Google spyware baked into it as a Huiwei-made smartphone? Miscreant-o-soft 'Edge', and it's associated 'telemetry' (read as: spyware)? Any of the fringe browsers, which are likely to be garbage and full of malware, too? Firefox is just as likely to be the cleanest in that regard.

  4. Then is non-standard by williamyf · · Score: 3, Insightful

    If the Standard call for a feature to work on Both HTTP and HTTPS, and you implement only HTTPS, then is not an standards compliant implementation...

    Come on Mozilla Foundation! Those heavy-handed tactics could work when your market share was about 50%, but not anymore...

    JM2C, YMMV

    --
    *** Suerte a todos y Feliz dia!
  5. Re:Support DANE by WaffleMonster · · Score: 2

    Then we can talk.

    Rolling out DNSSEC without first addressing DNS amplification is dangerous and irresponsible.

  6. Encryption is the new fad by RightwingNutjob · · Score: 3, Insightful

    Last month bitcoin was the new fad. These silicon valley types must have been drinking too much Raw Water(TM) picked up some brain parasites.

    Very little needs to be encrypted or authenticated. Not everything that needs to be encrypted when going through the open internet needs to be encrypted or authenticated when happening on a closed LAN. Encryption isn't for free. SSL certificate management isn't for free. When stepping away from the half of web browser use that happens on the open internet and into the other half that happens on closed networks, it is wasted effort for no benefit.

    1. Re:Encryption is the new fad by Obfuscant · · Score: 2

      Then always use encryption so you don't have to think about whether you "need" it or not.

      I've already thought about it. For the websites I run, it isn't needed. It isn't worth my time managing certificates for them.

      It's not a huge pain in the ass anymore

      So it is still a pain in the ass, just not a huge one. See above.

      The problem I see here is my router and cable modem web interfaces don't support https.

      I connected to the embedded web server in my HP printer for the first time just last night. It did HTTP just fine. Then it demanded to switch to HTTPS because I was going to enter a password. The first thing Firefox did was bitch about the certificate and make me go through the "add exception" process, after puking up the warning about being a bad site. That was possible only because I have an old FF on my system.

  7. Re:In a groundbreaking statement now by RedK · · Score: 2

    Not all content requires people's information to be transmitted over the wire.

    --
    "Not to mention all the idiots who use words like boxen."
    Anonymous Coward on Monday August 04, @06:49PM
  8. Cleartext HTTP vulnerable to script injection by tepples · · Score: 4, Insightful

    I run several websites, and not a single one of them needs HTTPS for anything.

    How do you assure visitors of the several websites you run that the markup, stylesheets, images, fonts, and possibly scripts on your site have not been modified in transit by an intercepting proxy between your server and the viewer's machine? Comcast, for example, has been shown to inject advertisement scripts into HTML documents delivered through cleartext HTTP.

    OMG, a MITM might substitute fake data! How awful!

    Thus you answer your own question. It is awful.

    1. Re:Cleartext HTTP vulnerable to script injection by tlhIngan · · Score: 2

      Which is the greater danger, allowing web access in the clear (note that this does not preclude allowing secured access as well) or creating a single point of failure called "Let's Encrypt" such that if it does fail then suddenly the entire world has to start paying money for certificates or finds their sites no longer work properly?

      Not only that, but with Let's Encrypt issuing out certificates so sites can phish, it seems like a good way to avoid all the Paypal and other phishing is to block the Let's Encrypt certificate. (they issued like 14,000 phishing certificates)

      Of course, we don't do this because Let's Encrypt is sponsored "by the good guys" (Mozilla, EFF, etc). But if it was some other CA, we'd be blocking them ASAP.

      It's only a matter of time before they issue a new wave of certificates to phishing and other scammy sites. Not sure how long until people DO start manually blocking Let's Encrypt to get rid of a bunch of problem sites.

      The overhead for SSL is not the encryption. Not on a modern CPU it isn't. Any overhead is due to the extra communication steps to set up the connection. But HTTP 1.1 will do a single handshake and reuse the connection.

      No, the overhead in SSL has been the management. Especially inside a LAN context where you have to add your own to the trusted root, and maintain it all everywhere and even then you probably run into an odd device or two that won't allow you to install a certificate.

    2. Re:Cleartext HTTP vulnerable to script injection by tepples · · Score: 2

      with Let's Encrypt issuing out certificates so sites can phish, it seems like a good way to avoid all the Paypal and other phishing is to block the Let's Encrypt certificate. (they issued like 14,000 phishing certificates)

      Why not go a step further to block the domain registrars that issue out domains so sites can phish?

  9. Re:In a groundbreaking statement now by gnick · · Score: 2

    We need to know so we can all switch to it.

    Lynx's security is second to none.

    --
    He's getting rather old, but he's a good mouse.
  10. Re:Router, printer, NAS, and other FQDNless device by Octorian · · Score: 4, Informative

    Let's Encrypt has short-lived certificates, which are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts.

    Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?

    The "local network devices" problem is a real problem, and its never given proper attention in these HTTPS proclamations.

    I "solved" it for myself by setting up a local CA to make certs for my stuff. Unfortunately, getting the cert for that CA into all my browsers is annoying, and can introduce its own share of issues.

  11. Clients cache HTTPS by tepples · · Score: 2

    The web browser caches resources delivered through HTTPS the same way as resources delivered through cleartext HTTP. The only thing you lose is being able to cache on an intermediate proxy, but that is relevant if you're splitting one dial-up connection among multiple clients.

    Then there is the issue of small timers who want to serve a web page from home, using an old computer and dynamic hostname.

    File a support ticket with your dynamic DNS provider to request addition to the Public Suffix List. If a dynamic DNS provider is on the Public Suffix List, Let's Encrypt issues 20 certificates per customer per week instead of 20 per provider per week. The other benefit of being on the PSL is that sites on the same dynamic DNS provider can't see each others' cookies.

  12. DNS registries and registrars by tepples · · Score: 2

    If the functionality of your system depends on yet another third party, then it isn't free.

    DNS registries and registrars are third parties. What makes a CA any different from DNS in this respect?

  13. Re: In a groundbreaking statement now by gnick · · Score: 2

    Yes. It was originally Norwegian, but was sold to "Golden Brick Capital Private Equity Fund I Limited Partnership" for $600M at the end of 2016.

    --
    He's getting rather old, but he's a good mouse.
  14. Re:This press release is garbage by roca · · Score: 2

    Mozilla developers like Anne know more about browser development than you do.

    In Gecko, restricting new DOM APIs to secure contexts is simply a matter of adding an attribute to the WebIDL:
    https://github.com/mozilla/gec...

    Probably something similar will be added to the CSS property list.

    There is also a single method you can call on the internal interface of a 'window' object to determine if you're in a secure context.
    https://dxr.mozilla.org/mozill...

    Selective disabling of new features is already standard practice. New features are almost always guarded by hidden preferences so they can be safely disabled just before release if a showstopper bug turns up, or so that they can be incrementally worked on over multiple releases without being shipped in a half-done state.

    There's very little extra work required here.