7 ms·

This includes blocking access by web apps such as Dropbox to their local daemon, which currently rely on a public DNS record resolving to 127.0.0.1 and a secure

This includes blocking access by web apps such as Dropbox to their local daemon, which currently rely on a public DNS record resolving to 127.0.0.1 and a secure localhost websocket server (using a certificate for the public DNS record's FQDN) to make the connection (with additional mutual authentication after the websocket handshake). After this change, there will be no way for a web app to communicate directly with a locally installed daemon.

wingerlang 12y ago
As a normal user, i.e. someone who does't really keep up to speed with whatever is the latest news in cross-platform-XRGS-injection-attack, is this good or bad?
- jorangreef 12y ago
  On the one hand, blocking access to plain http servers on localhost is a good idea as it prevents people from trying to probe router servers etc. which don't expect to be accessed from the web. But on the other hand, blocking secure websocket servers on 127.0.0.1 using a public DNS record and valid SSL certificate, is going too far. Secure websocket servers on localhost are often implemented precisely for the purpose of being accessed by the public web, and are secured for that purpose. It's very rare to find wss servers on localhost using a public dns record resolving to 127.0.0.1 and a valid ssl certificate (most people seem to think a wss server on localhost is not possible). So this is bad for users. For example, it will break Dropbox's feature which allows you to open files from within the web app in a native application such as Excel (if you have the file synced on your computer). If Chrome continue with this, then apps such as Dropbox will have to implement these kinds of features using server proxies. These will be slower and less secure since they will need to be able to guarantee that a TCP connection from a web browser and a TCP connection from a local daemon are from the same machine (this is not easy to do when NAT is involved).
  - deleted 12y ago
    [deleted]
  - kalleboo 12y ago
    > For example, it will break Dropbox's feature which allows you to open files from within the web app in a native application such as Excel (if you have the file synced on your computer). Couldn't that just do that with a custom URL scheme like dropbox:// that's handled by the local app? Or is there more to the feature?
    - Piskvorrr 12y ago
      The issue with custom URL schemes is that they're a cure worse than the disease here. The "internal webserver for local apps" was supposed to be a workaround for this very problem.
      - jorangreef 12y ago
        Yes, the custom protocol scheme is also only really useful for doing something "once". That is, you can only issue one custom protocol request or so each time you load a web page, the browser blocks the rest to prevent spamming the user.
  - justinschuh 12y ago
    I'm sorry, I know this is an earlier comment but I wanted to correct this framing of the threat and proposed mitigations. My response to you here explains why these measures don't solve the attacks that we're trying to address: https://news.ycombinator.com/item?id=9211034 https://news.ycombinator.com/item?id=9211034
nraynaud 12y ago
To complete with an example of that, easel, the hipster Computer Aided Manufacturing software is hosted in the web, and it assumes that your CNC router is on the local network to receive the instructions in a HTTP post request.
diminoten 12y ago
> After this change, there will be no way for a web app to communicate directly with a locally installed daemon. Well, you could just not use Chrome.
- jorangreef 12y ago
  Yes, but if you're developing a cross-browser web app you can't expect your users to just not use Chrome.
  - grennis 12y ago
    Wow how things have changed
  - TheOtherHobbes 12y ago
    If Google keeps breaking web apps, users will move from Chrome anyway.
    - threeseed 12y ago
      This argument has been shown to be wrong on many, many occasions. Many users do not have a choice which browser they use, do not know they even have a choice or do not know how to exercise that choice i.e. download and install a competing browser. Finally you're then left with the massive problem of sites only working on certain browsers.
      - Turing_Machine 12y ago
        The situation where the user doesn't know about and/or is incapable of installing another browser is pretty common with default browsers like IE and Safari, but not nearly as common with Chrome.
        makomk 12y ago
        Google have been bundling Chrome with widely-used software like Adobe Flash for years now, there's probably many people who've installed it and set it as their default browser without intending to.
justinschuh 12y ago
I mentioned this above, but we plan to let the localhost/private page support an explicit opt-in, maybe via CORS headers. Those details may not be captured in the bugs yet because currently no one is actively working on this.
- jorangreef 12y ago
  Websockets already have the Origin header as mentioned in the bug by Tyoshino: https://code.google.com/p/chromium/issues/detail?id=378566#c5 https://code.google.com/p/chromium/issues/detail?id=378566#c... Edit: From my other comments, there is the additional implicit opt-in shown by WSS itself on localhost requiring (1) a public DNS record and (2) a valid SSL certificate for that FQDN. I doubt that there are WSS servers on localhost out there setup with a public DNS record and validating SSL certificate which are not also expecting public traffic.
  - justinschuh 12y ago
    As I explained in my other comment, the origin header in websockets doesn't help in addressing the attacks we see, because it is a server-side measure.

wingerlang 12y ago

As a normal user, i.e. someone who does't really keep up to speed with whatever is the latest news in cross-platform-XRGS-injection-attack, is this good or bad?

jorangreef 12y ago
On the one hand, blocking access to plain http servers on localhost is a good idea as it prevents people from trying to probe router servers etc. which don't expect to be accessed from the web. But on the other hand, blocking secure websocket servers on 127.0.0.1 using a public DNS record and valid SSL certificate, is going too far. Secure websocket servers on localhost are often implemented precisely for the purpose of being accessed by the public web, and are secured for that purpose. It's very rare to find wss servers on localhost using a public dns record resolving to 127.0.0.1 and a valid ssl certificate (most people seem to think a wss server on localhost is not possible). So this is bad for users. For example, it will break Dropbox's feature which allows you to open files from within the web app in a native application such as Excel (if you have the file synced on your computer). If Chrome continue with this, then apps such as Dropbox will have to implement these kinds of features using server proxies. These will be slower and less secure since they will need to be able to guarantee that a TCP connection from a web browser and a TCP connection from a local daemon are from the same machine (this is not easy to do when NAT is involved).
- deleted 12y ago
  [deleted]
- kalleboo 12y ago
  > For example, it will break Dropbox's feature which allows you to open files from within the web app in a native application such as Excel (if you have the file synced on your computer). Couldn't that just do that with a custom URL scheme like dropbox:// that's handled by the local app? Or is there more to the feature?
  - Piskvorrr 12y ago
    The issue with custom URL schemes is that they're a cure worse than the disease here. The "internal webserver for local apps" was supposed to be a workaround for this very problem.
    - jorangreef 12y ago
      Yes, the custom protocol scheme is also only really useful for doing something "once". That is, you can only issue one custom protocol request or so each time you load a web page, the browser blocks the rest to prevent spamming the user.
- justinschuh 12y ago
  I'm sorry, I know this is an earlier comment but I wanted to correct this framing of the threat and proposed mitigations. My response to you here explains why these measures don't solve the attacks that we're trying to address: https://news.ycombinator.com/item?id=9211034 https://news.ycombinator.com/item?id=9211034

nraynaud 12y ago

To complete with an example of that, easel, the hipster Computer Aided Manufacturing software is hosted in the web, and it assumes that your CNC router is on the local network to receive the instructions in a HTTP post request.

diminoten 12y ago

> After this change, there will be no way for a web app to communicate directly with a locally installed daemon. Well, you could just not use Chrome.

jorangreef 12y ago
Yes, but if you're developing a cross-browser web app you can't expect your users to just not use Chrome.
- grennis 12y ago
  Wow how things have changed
- TheOtherHobbes 12y ago
  If Google keeps breaking web apps, users will move from Chrome anyway.
  - threeseed 12y ago
    This argument has been shown to be wrong on many, many occasions. Many users do not have a choice which browser they use, do not know they even have a choice or do not know how to exercise that choice i.e. download and install a competing browser. Finally you're then left with the massive problem of sites only working on certain browsers.
    - Turing_Machine 12y ago
      The situation where the user doesn't know about and/or is incapable of installing another browser is pretty common with default browsers like IE and Safari, but not nearly as common with Chrome.
      - makomk 12y ago
        Google have been bundling Chrome with widely-used software like Adobe Flash for years now, there's probably many people who've installed it and set it as their default browser without intending to.

justinschuh 12y ago

I mentioned this above, but we plan to let the localhost/private page support an explicit opt-in, maybe via CORS headers. Those details may not be captured in the bugs yet because currently no one is actively working on this.

jorangreef 12y ago
Websockets already have the Origin header as mentioned in the bug by Tyoshino: https://code.google.com/p/chromium/issues/detail?id=378566#c5 https://code.google.com/p/chromium/issues/detail?id=378566#c... Edit: From my other comments, there is the additional implicit opt-in shown by WSS itself on localhost requiring (1) a public DNS record and (2) a valid SSL certificate for that FQDN. I doubt that there are WSS servers on localhost out there setup with a public DNS record and validating SSL certificate which are not also expecting public traffic.
- justinschuh 12y ago
  As I explained in my other comment, the origin header in websockets doesn't help in addressing the attacks we see, because it is a server-side measure.