5 ms·

Even more interesting: In the current Firefox nightly inputs with `type="password"` on insecure origins are being marked explicitly as insecure. This also inclu

by K0nserv 11y ago

Even more interesting: In the current Firefox nightly inputs with `type="password"` on insecure origins are being marked explicitly as insecure. This also includes common anti patterns such as loading an iframe from a secure origin on an insecure page. There's a screenshot of this on my latest blog post[1] and another article[2] on this topic. I am very happy to see browser vendors pushing for HTTPS adoption and forcing the hands of developers. Further highlighting poor security like this also means that users are made aware and can opt out of using websites with poor security practices. 1: https://hugotunius.se/2016/01/24/how-browser-vendors-are-pushing-for-https-adoption.html https://hugotunius.se/2016/01/24/how-browser-vendors-are-pus... 2: https://www.fxsitecompat.com/en-CA/docs/2015/non-https-sites-containing-login-form-will-be-marked-insecure/ https://www.fxsitecompat.com/en-CA/docs/2015/non-https-sites...

mikegerwitz 11y ago
This is a good, important feature. Do you know what the plans are for enabling this in all editions of Firefox?
- dao- 11y ago
  AFAIK and contrary to what others have said, there's no plan to enable this in a release version of Firefox anytime soon. There are too many affected sites and most average users would probably just start ignoring the crossed out lock or get scared and use some other browser.
  - K0nserv 11y ago
    Hmm I was under the impression that since it's currently in Aurora it's likely to be in the end release? Do you have a source on this?
    - dao- 11y ago
      It's in dev edition / aurora because those aren't "release" builds, and the security.insecure_password.ui.enabled default value depends on a RELEASE_BUILD ifdef. So no, it won't automatically be enabled when current aurora moves to beta.
      - K0nserv 11y ago
        I was under the impression that it worked like an Alpha and the intention is for features in it to eventually end up in stable unless critical problems are found in them?
        dao- 11y ago
        This is usually true but not in this case. Or if you want to put it this way, the anticipated critical problem is that this UI would confuse average end users and thus we won't enable it for them.
        K0nserv 11y ago
        Interesting, is there any public discussion on this? I didn't find anything like it when I was researching the blog post.
        dao- 11y ago
        https://bugzilla.mozilla.org/show_bug.cgi?id=1188121 https://bugzilla.mozilla.org/show_bug.cgi?id=1188121 appears to be the main tracking bug for this feature. It says "... for developers" in its summary.
- DCoder 11y ago
  The old plan was to enable it in Fx 44 (the one that was just released). But a couple of bugs caused a delay and it was pushed back. It was just enabled in nightly/dev builds [0], so Fx 46 will probably have it. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10 https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10
  - K0nserv 11y ago
    Fx 46 is scheduled to be released on the 19th of April FYI https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar
tombrossman 11y ago
There is (of course) a Tumblr site for sites that do this[0] I found a bunch of local websites including utilities and email providers that do this[1] and seem completely unaware of the risk. Emailing them to explain the problem didn't help much as the vast majority simply ignored me. Hopefully this will make it into all the mainstream browsers soon because not protecting sensitive data with HTTPS is really inexcusable in 2016. It's not like it costs a lot of money to do. [0]http://httpshaming.tumblr.com/ http://httpshaming.tumblr.com/ [1]http://insecure.org.je/ http://insecure.org.je/ And yes I see the irony in having an HTTP site for this, but at least Tumblr does a proper HTTPS form post action...
- K0nserv 11y ago
  That's great. I've been thinking about and even prototyping something like httpoffenders.com. Glad to hear it's already beeen done
  - tombrossman 11y ago
    Yeah, mine is a shameless copy of the Plaintext Offenders Tumblr (http://plaintextoffenders.com/ http://plaintextoffenders.com/) which I've known about for years, but I wish I had spotted the HTTP Shaming one earlier as I would have saved myself time and submitted the local sites there instead. Oh well.
    - Klathmon 11y ago
      I really love what plaintextoffenders is trying to do, but i've lost all confidence in it. Most of the sites on there are because of things like they will email you a temporary password forcing you to change it on first login. Digital ocean has a big red banner because if you don't provide a private key, they send you a randomly generated root password for new servers you make. FFS apple.com is on their list because someone SENT IN an email with their username and password for their phone on it, and they replied with a "work authorisation" letter that included the message they sent it... That's not what it's meant to stop...
lazyjones 11y ago
> I am very happy to see browser vendors pushing for HTTPS adoption Me too, but the fact that the update downloads automatically via plain HTTP ruined it a bit for me...
- khuey 11y ago
  Firefox's updater uses a cryptographic hash that is transmitted over HTTPS to verify the integrity of the update files downloaded over HTTP.
tomjen3 11y ago
Loading an iframe over http is at least not going to expose the users password to a passive attacker. I would really hate if we repeated the error whereby sites signed with non root ca keys got marked with a big scary error, because it wasn't as secure as it could be.

by K0nserv 11y ago

mikegerwitz 11y ago

This is a good, important feature. Do you know what the plans are for enabling this in all editions of Firefox?

dao- 11y ago
AFAIK and contrary to what others have said, there's no plan to enable this in a release version of Firefox anytime soon. There are too many affected sites and most average users would probably just start ignoring the crossed out lock or get scared and use some other browser.
- K0nserv 11y ago
  Hmm I was under the impression that since it's currently in Aurora it's likely to be in the end release? Do you have a source on this?
  - dao- 11y ago
    It's in dev edition / aurora because those aren't "release" builds, and the security.insecure_password.ui.enabled default value depends on a RELEASE_BUILD ifdef. So no, it won't automatically be enabled when current aurora moves to beta.
    - K0nserv 11y ago
      I was under the impression that it worked like an Alpha and the intention is for features in it to eventually end up in stable unless critical problems are found in them?
      - dao- 11y ago
        This is usually true but not in this case. Or if you want to put it this way, the anticipated critical problem is that this UI would confuse average end users and thus we won't enable it for them.
        K0nserv 11y ago
        Interesting, is there any public discussion on this? I didn't find anything like it when I was researching the blog post.
        dao- 11y ago
        https://bugzilla.mozilla.org/show_bug.cgi?id=1188121 https://bugzilla.mozilla.org/show_bug.cgi?id=1188121 appears to be the main tracking bug for this feature. It says "... for developers" in its summary.
DCoder 11y ago
The old plan was to enable it in Fx 44 (the one that was just released). But a couple of bugs caused a delay and it was pushed back. It was just enabled in nightly/dev builds [0], so Fx 46 will probably have it. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10 https://bugzilla.mozilla.org/show_bug.cgi?id=1221206#c10
- K0nserv 11y ago
  Fx 46 is scheduled to be released on the 19th of April FYI https://wiki.mozilla.org/RapidRelease/Calendar https://wiki.mozilla.org/RapidRelease/Calendar

tombrossman 11y ago

There is (of course) a Tumblr site for sites that do this[0] I found a bunch of local websites including utilities and email providers that do this[1] and seem completely unaware of the risk. Emailing them to explain the problem didn't help much as the vast majority simply ignored me. Hopefully this will make it into all the mainstream browsers soon because not protecting sensitive data with HTTPS is really inexcusable in 2016. It's not like it costs a lot of money to do. [0]http://httpshaming.tumblr.com/ http://httpshaming.tumblr.com/ [1]http://insecure.org.je/ http://insecure.org.je/ And yes I see the irony in having an HTTP site for this, but at least Tumblr does a proper HTTPS form post action...

K0nserv 11y ago
That's great. I've been thinking about and even prototyping something like httpoffenders.com. Glad to hear it's already beeen done
- tombrossman 11y ago
  Yeah, mine is a shameless copy of the Plaintext Offenders Tumblr (http://plaintextoffenders.com/ http://plaintextoffenders.com/) which I've known about for years, but I wish I had spotted the HTTP Shaming one earlier as I would have saved myself time and submitted the local sites there instead. Oh well.
  - Klathmon 11y ago
    I really love what plaintextoffenders is trying to do, but i've lost all confidence in it. Most of the sites on there are because of things like they will email you a temporary password forcing you to change it on first login. Digital ocean has a big red banner because if you don't provide a private key, they send you a randomly generated root password for new servers you make. FFS apple.com is on their list because someone SENT IN an email with their username and password for their phone on it, and they replied with a "work authorisation" letter that included the message they sent it... That's not what it's meant to stop...

lazyjones 11y ago

> I am very happy to see browser vendors pushing for HTTPS adoption Me too, but the fact that the update downloads automatically via plain HTTP ruined it a bit for me...

khuey 11y ago
Firefox's updater uses a cryptographic hash that is transmitted over HTTPS to verify the integrity of the update files downloaded over HTTP.

tomjen3 11y ago

Loading an iframe over http is at least not going to expose the users password to a passive attacker. I would really hate if we repeated the error whereby sites signed with non root ca keys got marked with a big scary error, because it wasn't as secure as it could be.