7 ms·

And for developers: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/84 https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel... The bi

by jefftk 6y ago

And for developers: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/84 https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel... The biggest change from my perspective is "Firefox now ensures that localhost URLs — such as http://localhost/ http://localhost/ and http://dev.localhost/ http://dev.localhost/ — refer to the local host's loopback interface (e.g. http://127.0.0.1 http://127.0.0.1). As a result, resources loaded from localhost are now assumed to have been delivered securely (see Secure contexts), and also will not be treated as mixed content (bug 1220810, bug 1488740)." This is great for local development.

macspoofing 6y ago
>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in part) with a locally hosted web-server.
- nerdponx 6y ago
  Or even just browser apps that are easy/encouraged to run locally, like Jupyter Notebook.
  - rhizome 6y ago
    Like, started from the local filesystem? I see they have a "Notebook Server," is that what you mean by "locally," rather than starting it from clicking an e.g. "jupyter.html" file? To their credit, it doesn't seem to use Node, and configuration via .py files tells me maybe they have some lightweight server thing that makes it a bit more manageable as a single-user app than via Node or Electron and friends. Anyway, I have a project I have been wanting to be completely self-contained in an HTML file, but that gives me CORS problems, so now I'm thinking maybe the Jupyter posse has implemented a nice compromise I can use.
    - nerdponx 6y ago
      Yes, Jupyter Notebook (and its successor Jupyter Lab) is a Python program that serves a browser (HTML/CSS/JS) application. It is meant to be used equally well when the Jupyter server is on your local machine or somewhere else on the network. Other tools that use similar architectures: Tabula, Kiwi IRC, The Lounge IRC. The user experience is maybe more "technical", but you don't have Electron involved, just whatever web browser you would use for anything else.
      - rhizome 6y ago
        The part that appeals to me is that they're using a smaller than nodejs (and Electron for that matter) local server to do so! CORS means something has to proxy, so seeing the existence of what I'm assuming is a minimum implementation is really helpful. Obviously I'm not hanging out in the right slacks or subreddits. ;)
- est31 6y ago
  I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe these services were coded assuming that an URL can only be 1 kb long? What if you overrun that buffer? For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 ? TLDR: not a fan of this.
  - bayindirh 6y ago
    > For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 A typical Linux installation can run much more web servers on localhost. I run transmission-daemon, syncthing, cups, sometimes pagico (which is a desktop app which runs a php/web server backend on loopback). I guess that Firefox folks have thought of this otherwise, it'd be patched pretty quickly.
    - pimterry 6y ago
      CORS solves much of this - servers have to opt in to allowing these requests, just like any other cross-origin requests. Badwebsite.com in general cannot send a POST to bank.com/send-money from inside your browser, and similarly it cannot POST to localhost:631. There's caveats and of course servers can be configured insecurely, but this isn't a general risk by default.
      - minitech 6y ago
        Both of those requests can be sent. CORS just stops the response from being read. It’s up to web servers on localhost to assume they’re at just as much risk as any other non-local service, and they often fail to do so. (See also DNS rebinding that nets an attacker the opposite set of permissions, in a sense.)
        6y ago
- SomeHacker44 6y ago
  Like Zoom. Joy.
- bigbubba 6y ago
  I hate this shit, I've only seen the sketchiest sort of spyware, like discord, do it. Browsers should forbid it, since it's a blatant end-run around the limitations a 'web app' would normally have. Furthermore, browsers even having this ability facilitates inter-protocol exploitation. It's not only local webservers that are put at risk by this, other sorts of local servers can be attacked as well. See CVE-2016-8606 for an example of a browser being used to attack a guile repl.
- edoceo 6y ago
  Yes, I have a localhost running python script to communicate with serial devices and printers, so this makes it a bit easier. (I currently slide in a self-signed cert)
hannob 6y ago
If I understand this correctly this doesn't change that much. It means you can now safely use localhost, but you could achieve the same before by using 127.0.0.1.
- nathell 6y ago
  Not if your app extracts some info out of the domain, e.g., tenant slug.
nerdponx 6y ago
Am I incompetent if I thought all browsers all did this already by default? Or was this typically enforced at the OS/networking-stack level, and now Firefox is adding an additional guarantee that it will happen directly in the browser, even if the networking stack would say otherwise?
- bzbarsky 6y ago
  The latter. You can always set your /etc/hosts or equivalent to map "localhost" to some random IP that is not loopback. Or a proxy could proxy that hostname, etc. In the new setup proxies can't proxy localhost unless you set a pref to explicitly let them do that, and for "localhost" and hostnames ending in ".localhost" Firefox won't even ask the DNS stack for the IP, assuming loopback instead.
  - cesarb 6y ago
    > Firefox won't even ask the DNS stack for the IP, assuming loopback instead. Which loopback, 127.0.0.1, ::1, or both?
    - arp242 6y ago
      You have all of 127.0.0.0/8 as a loopback; I hope it doesn't hard-code 127.0.0.1 as I use some other addresses as well.
      - bzbarsky 6y ago
        "localhost" is hardcoded to resolve to "127.0.0.1" (ignoring IPv6 for now). The "is secure context" state applies to 127.0.0.0/8 (again ignoring IPv6). See NetAddr::IsLoopBackAddressWithoutIPv6Mapping in https://searchfox.org/mozilla-central/source/netwerk/dns/DNS.cpp https://searchfox.org/mozilla-central/source/netwerk/dns/DNS... I'm pretty sure all of this is clearly specified at this point, so browsers should end up all aligning on a common behavior here at some point, if they haven't yet.
    - bzbarsky 6y ago
johnchristopher 6y ago
Does it mean I can curl https://whatever.localhost https://whatever.localhost without SSL warning for self signed certificates ? That would simplify my life when developing stuff on localhost and importing them between different things over http(s). edit: Kids, you see those articles that regularly hit the frontpage about work/life balance ? The ones about how you need healthy sleep patterns and crunching all night long is actually bad for you brain ? This comment is what happens when you read those but don't actually follow through with recommendations. Sorry everyone ^^.
- orev 6y ago
  curl is a separate program from Firefox. How would a change in Firefox affect how curl works?
- acoard 6y ago
  It means FireFox could visit https://whatever.localhost https://whatever.localhost without SSL warnings for self-signed certs. It has no bearing on cURL. cURL is maintained by Daniel Stenberg (an open source legend), whereas FireFox is maintained by Mozilla. Completely separate. This is like asking if Tesla's new car policy will affect your Toyota.
  - aorth 6y ago
    I was curious about this because the release notes don't mention changing the behavior of HTTPS for localhost. I set up a local test and http://mytest.localhost http://mytest.localhost works without having to add an entry to /etc/hosts, but https://mytest.localhost https://mytest.localhost with a self-signed TLS certificate will still raise a SEC_ERROR_UNKNOWN_ISSUER error. You still need to ignore those or install your own root CA with something like https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert for that to work seamlessly.
- deleted 6y ago
  [deleted]
- totetsu 6y ago
  also isnt there an ignore ssl option in man crul?
eterm 6y ago
That sounds great for local development. It sounds like a vector to keep an eye on for bug bounty hunters. Any time something is "assumed to be [...] secure" there's a good chance that assumption can be broken in some strange way in future.
rascul 6y ago
Does this mean Firefox will ignore my hosts file entry? 127.0.1.12 dev.localhost
- bzbarsky 6y ago
  Based on code inspection, I believe so, yes. It will map "dev.localhost" to 127.0.0.1.
  - rascul 6y ago
    I wonder if Mozilla overlooked this. IANA has 127.0.0.0/8 reserved for loopback, not just 127.0.0.1. https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.iana.org/assignments/iana-ipv4-special-registry/...
    - gpvos 6y ago
      Yes, but that's only relevant if Firefox were mapping from IP addresses to something. Here it's mapping to an IP address, so 127.0.0.1 is fine (even though, e.g., 127.0.0.42 would also have been fine).
      - rascul 6y ago
        It seems relevant because Firefox ignores that I might have dev.localhost mapped to a valid loopback address that is not 127.0.0.1.
        gpvos 6y ago
        Thanks, this was enlightening.
      - Seb-C 6y ago
        To have clean URLs I have in the past had a setup like this, which won't be possible anymore: http://foo.localhost/ -> 127.0.0.1:80 http://bar.localhost/ -> 127.0.0.2:80 This way you can have multiple services running on the default ports.
SCLeo 6y ago
So, does that mean things like WebCrypto (which requires https to be available) will work in development environment now? Or did they already work out of box? I never tried because I assumed they won't work.
- deleted 6y ago
  [deleted]
- bzbarsky 6y ago
  Yes, that is exactly what it means: things that require a "secure context" in spec terms, like WebCrypto, will work on http://localhost http://localhost even though it's not https.
devwastaken 6y ago
Does it work for mobile via USB debugging now too? I had a problem where I couldn't use shared memory in wasm because it didn't consider it secure.
darau1 6y ago
thank you jesus
amelius 6y ago
But can other websites visit localhost, and thus probe your development machine while you browse those websites?
inetknght 6y ago
> As a result, resources loaded from localhost are now assumed to have been delivered securely (see Secure contexts), and also will not be treated as mixed content (bug 1220810, bug 1488740)." That's dangerous. I don't want stuff loaded from localhost to have any different security context than stuff not loaded from localhost.
deleted 6y ago
[deleted]

by jefftk 6y ago

macspoofing 6y ago

>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in part) with a locally hosted web-server.

nerdponx 6y ago
Or even just browser apps that are easy/encouraged to run locally, like Jupyter Notebook.
- rhizome 6y ago
  Like, started from the local filesystem? I see they have a "Notebook Server," is that what you mean by "locally," rather than starting it from clicking an e.g. "jupyter.html" file? To their credit, it doesn't seem to use Node, and configuration via .py files tells me maybe they have some lightweight server thing that makes it a bit more manageable as a single-user app than via Node or Electron and friends. Anyway, I have a project I have been wanting to be completely self-contained in an HTML file, but that gives me CORS problems, so now I'm thinking maybe the Jupyter posse has implemented a nice compromise I can use.
  - nerdponx 6y ago
    Yes, Jupyter Notebook (and its successor Jupyter Lab) is a Python program that serves a browser (HTML/CSS/JS) application. It is meant to be used equally well when the Jupyter server is on your local machine or somewhere else on the network. Other tools that use similar architectures: Tabula, Kiwi IRC, The Lounge IRC. The user experience is maybe more "technical", but you don't have Electron involved, just whatever web browser you would use for anything else.
    - rhizome 6y ago
      The part that appeals to me is that they're using a smaller than nodejs (and Electron for that matter) local server to do so! CORS means something has to proxy, so seeing the existence of what I'm assuming is a minimum implementation is really helpful. Obviously I'm not hanging out in the right slacks or subreddits. ;)
est31 6y ago
I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe these services were coded assuming that an URL can only be 1 kb long? What if you overrun that buffer? For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 ? TLDR: not a fan of this.
- bayindirh 6y ago
  > For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 A typical Linux installation can run much more web servers on localhost. I run transmission-daemon, syncthing, cups, sometimes pagico (which is a desktop app which runs a php/web server backend on loopback). I guess that Firefox folks have thought of this otherwise, it'd be patched pretty quickly.
  - pimterry 6y ago
    CORS solves much of this - servers have to opt in to allowing these requests, just like any other cross-origin requests. Badwebsite.com in general cannot send a POST to bank.com/send-money from inside your browser, and similarly it cannot POST to localhost:631. There's caveats and of course servers can be configured insecurely, but this isn't a general risk by default.
    - minitech 6y ago
      Both of those requests can be sent. CORS just stops the response from being read. It’s up to web servers on localhost to assume they’re at just as much risk as any other non-local service, and they often fail to do so. (See also DNS rebinding that nets an attacker the opposite set of permissions, in a sense.)
      - 6y ago
SomeHacker44 6y ago
Like Zoom. Joy.
bigbubba 6y ago
I hate this shit, I've only seen the sketchiest sort of spyware, like discord, do it. Browsers should forbid it, since it's a blatant end-run around the limitations a 'web app' would normally have. Furthermore, browsers even having this ability facilitates inter-protocol exploitation. It's not only local webservers that are put at risk by this, other sorts of local servers can be attacked as well. See CVE-2016-8606 for an example of a browser being used to attack a guile repl.
edoceo 6y ago
Yes, I have a localhost running python script to communicate with serial devices and printers, so this makes it a bit easier. (I currently slide in a self-signed cert)

hannob 6y ago

If I understand this correctly this doesn't change that much. It means you can now safely use localhost, but you could achieve the same before by using 127.0.0.1.

nathell 6y ago
Not if your app extracts some info out of the domain, e.g., tenant slug.

nerdponx 6y ago

Am I incompetent if I thought all browsers all did this already by default? Or was this typically enforced at the OS/networking-stack level, and now Firefox is adding an additional guarantee that it will happen directly in the browser, even if the networking stack would say otherwise?

bzbarsky 6y ago
The latter. You can always set your /etc/hosts or equivalent to map "localhost" to some random IP that is not loopback. Or a proxy could proxy that hostname, etc. In the new setup proxies can't proxy localhost unless you set a pref to explicitly let them do that, and for "localhost" and hostnames ending in ".localhost" Firefox won't even ask the DNS stack for the IP, assuming loopback instead.
- cesarb 6y ago
  > Firefox won't even ask the DNS stack for the IP, assuming loopback instead. Which loopback, 127.0.0.1, ::1, or both?
  - arp242 6y ago
    You have all of 127.0.0.0/8 as a loopback; I hope it doesn't hard-code 127.0.0.1 as I use some other addresses as well.
    - bzbarsky 6y ago
      "localhost" is hardcoded to resolve to "127.0.0.1" (ignoring IPv6 for now). The "is secure context" state applies to 127.0.0.0/8 (again ignoring IPv6). See NetAddr::IsLoopBackAddressWithoutIPv6Mapping in https://searchfox.org/mozilla-central/source/netwerk/dns/DNS.cpp https://searchfox.org/mozilla-central/source/netwerk/dns/DNS... I'm pretty sure all of this is clearly specified at this point, so browsers should end up all aligning on a common behavior here at some point, if they haven't yet.
  - bzbarsky 6y ago

johnchristopher 6y ago

Does it mean I can curl https://whatever.localhost https://whatever.localhost without SSL warning for self signed certificates ? That would simplify my life when developing stuff on localhost and importing them between different things over http(s). edit: Kids, you see those articles that regularly hit the frontpage about work/life balance ? The ones about how you need healthy sleep patterns and crunching all night long is actually bad for you brain ? This comment is what happens when you read those but don't actually follow through with recommendations. Sorry everyone ^^.

orev 6y ago
curl is a separate program from Firefox. How would a change in Firefox affect how curl works?
acoard 6y ago
It means FireFox could visit https://whatever.localhost https://whatever.localhost without SSL warnings for self-signed certs. It has no bearing on cURL. cURL is maintained by Daniel Stenberg (an open source legend), whereas FireFox is maintained by Mozilla. Completely separate. This is like asking if Tesla's new car policy will affect your Toyota.
- aorth 6y ago
  I was curious about this because the release notes don't mention changing the behavior of HTTPS for localhost. I set up a local test and http://mytest.localhost http://mytest.localhost works without having to add an entry to /etc/hosts, but https://mytest.localhost https://mytest.localhost with a self-signed TLS certificate will still raise a SEC_ERROR_UNKNOWN_ISSUER error. You still need to ignore those or install your own root CA with something like https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert for that to work seamlessly.
deleted 6y ago
[deleted]
totetsu 6y ago
also isnt there an ignore ssl option in man crul?

eterm 6y ago

That sounds great for local development. It sounds like a vector to keep an eye on for bug bounty hunters. Any time something is "assumed to be [...] secure" there's a good chance that assumption can be broken in some strange way in future.

rascul 6y ago

Does this mean Firefox will ignore my hosts file entry? 127.0.1.12 dev.localhost

bzbarsky 6y ago
Based on code inspection, I believe so, yes. It will map "dev.localhost" to 127.0.0.1.
- rascul 6y ago
  I wonder if Mozilla overlooked this. IANA has 127.0.0.0/8 reserved for loopback, not just 127.0.0.1. https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.iana.org/assignments/iana-ipv4-special-registry/...
  - gpvos 6y ago
    Yes, but that's only relevant if Firefox were mapping from IP addresses to something. Here it's mapping to an IP address, so 127.0.0.1 is fine (even though, e.g., 127.0.0.42 would also have been fine).
    - rascul 6y ago
      It seems relevant because Firefox ignores that I might have dev.localhost mapped to a valid loopback address that is not 127.0.0.1.
      - gpvos 6y ago
        Thanks, this was enlightening.
    - Seb-C 6y ago
      To have clean URLs I have in the past had a setup like this, which won't be possible anymore: http://foo.localhost/ -> 127.0.0.1:80 http://bar.localhost/ -> 127.0.0.2:80 This way you can have multiple services running on the default ports.

SCLeo 6y ago

So, does that mean things like WebCrypto (which requires https to be available) will work in development environment now? Or did they already work out of box? I never tried because I assumed they won't work.

deleted 6y ago
[deleted]
bzbarsky 6y ago
Yes, that is exactly what it means: things that require a "secure context" in spec terms, like WebCrypto, will work on http://localhost http://localhost even though it's not https.

devwastaken 6y ago

Does it work for mobile via USB debugging now too? I had a problem where I couldn't use shared memory in wasm because it didn't consider it secure.

darau1 6y ago

thank you jesus

amelius 6y ago

But can other websites visit localhost, and thus probe your development machine while you browse those websites?

inetknght 6y ago

> As a result, resources loaded from localhost are now assumed to have been delivered securely (see Secure contexts), and also will not be treated as mixed content (bug 1220810, bug 1488740)." That's dangerous. I don't want stuff loaded from localhost to have any different security context than stuff not loaded from localhost.

deleted 6y ago

[deleted]