4 ms·

This was triggered by Tavis Ormandy and he says it's fine [1]. I honestly don't know enough to tell, is he correct when he says that it doesn't actually make an

This was triggered by Tavis Ormandy and he says it's fine [1]. I honestly don't know enough to tell, is he correct when he says that it doesn't actually make any difference? [1]: https://twitter.com/chort0/status/943933566596952065 https://twitter.com/chort0/status/943933566596952065

xg15 9y ago
I think the root problem is that apparently connections to http://localhost http://localhost from a https:// https:// site are considered mixed content and therefore blocked. I thought there was an exception for localhost, but apparently there isn't. [1] (I don't really understand the rationale for this) So with connections to http://localhost http://localhost not possible due to mixed content and connections to https://localhost https://localhost not possible because your cert will be blocked, there doesn't seem to be any obvious way left to connect from https to localhost at all. [1] https://security.stackexchange.com/questions/104801/why-arent-mixed-content-connections-allowed-on-localhost https://security.stackexchange.com/questions/104801/why-aren...
- user5994461 9y ago
  Remember than any page in your browser can run scripts from your computer. Browsers have a security model of what is allowed or not, that is a huge super-complicated mess. One of the protection is blocking mixed http and https. localhost and 127.0.0.1 never get exceptions to security rules, including mixed content. The rational is that there are many intranet and local applications that might be accessible on 127.0.0.1, they were not designed or secured to be accessible from the internet.
  - xg15 9y ago
    I don't think that really makes sense in that context. The current situation is that you can happily access localhost from unencrypted sites - even though those sites are more likely to contain malicious code. Additionally, localhost services are treated as a separate origin, so if a service is non-cooperating, you can only send fire-and-forget GETs which reduces the attack surface considerably.
- tonetheman 9y ago
  The https everywhere movement really caused this. Until google figures out a way to make money serving ads off localhost I cannot imagine they give a flying shit. :)
- xg15 9y ago
  (Update) Ok, so apparently there is a security exception: "localhost" is blocked but "127.0.0.1" is treated as a secure origin [1] - but only if you cantact it via http, not via websocket. (though they might allow websocket in the future too) [2] (A related chrome bug even specifically mentions the "people installing local root certs" workaround as a reason they are doing this. [3]) This still seems like an enormous mess but it's good to see the use-case is acknowledged and someone at Mozilla cares about it. So I guess Blizzard could have avoided the whole scare if they had just used "127.0.0.1" instead of "localbattle.net" [1] https://bugzilla.mozilla.org/show_bug.cgi?id=903966 https://bugzilla.mozilla.org/show_bug.cgi?id=903966 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1376309 https://bugzilla.mozilla.org/show_bug.cgi?id=1376309 [3] https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://chromium.googlesource.com/chromium/src.git/+/130ee68...

xg15 9y ago

I think the root problem is that apparently connections to http://localhost http://localhost from a https:// https:// site are considered mixed content and therefore blocked. I thought there was an exception for localhost, but apparently there isn't. [1] (I don't really understand the rationale for this) So with connections to http://localhost http://localhost not possible due to mixed content and connections to https://localhost https://localhost not possible because your cert will be blocked, there doesn't seem to be any obvious way left to connect from https to localhost at all. [1] https://security.stackexchange.com/questions/104801/why-arent-mixed-content-connections-allowed-on-localhost https://security.stackexchange.com/questions/104801/why-aren...

user5994461 9y ago
Remember than any page in your browser can run scripts from your computer. Browsers have a security model of what is allowed or not, that is a huge super-complicated mess. One of the protection is blocking mixed http and https. localhost and 127.0.0.1 never get exceptions to security rules, including mixed content. The rational is that there are many intranet and local applications that might be accessible on 127.0.0.1, they were not designed or secured to be accessible from the internet.
- xg15 9y ago
  I don't think that really makes sense in that context. The current situation is that you can happily access localhost from unencrypted sites - even though those sites are more likely to contain malicious code. Additionally, localhost services are treated as a separate origin, so if a service is non-cooperating, you can only send fire-and-forget GETs which reduces the attack surface considerably.
tonetheman 9y ago
The https everywhere movement really caused this. Until google figures out a way to make money serving ads off localhost I cannot imagine they give a flying shit. :)
xg15 9y ago
(Update) Ok, so apparently there is a security exception: "localhost" is blocked but "127.0.0.1" is treated as a secure origin [1] - but only if you cantact it via http, not via websocket. (though they might allow websocket in the future too) [2] (A related chrome bug even specifically mentions the "people installing local root certs" workaround as a reason they are doing this. [3]) This still seems like an enormous mess but it's good to see the use-case is acknowledged and someone at Mozilla cares about it. So I guess Blizzard could have avoided the whole scare if they had just used "127.0.0.1" instead of "localbattle.net" [1] https://bugzilla.mozilla.org/show_bug.cgi?id=903966 https://bugzilla.mozilla.org/show_bug.cgi?id=903966 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1376309 https://bugzilla.mozilla.org/show_bug.cgi?id=1376309 [3] https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e https://chromium.googlesource.com/chromium/src.git/+/130ee68...