7 ms·

Chrome team planning to block all access from browser to localhost wss

74 points by jorangreef 12y ago

jorangreef 12y ago
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.
Theodores 12y ago
Does this mean I cannot develop on localtest.me (that resolves to 127.0.0.1)?
- dvirsky 12y ago
  From the description, it only means that external pages won't be able to access resources on localhost, but you could still develop on localhost as usual.
orf 12y ago
This is a good thing. I recently found an exploit in a widely-distributed bit of software that listened on localhost but had minimal protection against malicious inputs. Anyone who could trigger your browser to make a crafted request to locahost (which is very easy) could make this bit of software download and execute any remote executable.
- jorangreef 12y ago
  Yes it is, but if you read closer, you will see that they are also planning to block access to secure websocket servers with public dns resolving to 127.0.0.1 and valid ssl certificates setup precisely for the purpose of being accessed by the public web. This is completely unnecessary.
  - acqq 12y ago
    But then malware can exploit every user of Dropbox, for example, it doesn't even need their own certificate. And even the users wo don't have Dropbox are vulnerable throgh Dropbox's DNS entry.
    - jorangreef 12y ago
      There are already plenty of public DNS records which resolve to 127.0.0.1. They're offered as services. For example, 37Signals have a domain resolving to localhost. Malware on a user's computer already has access to everything the user has. Malware on a website would be blocked by the mutual authentication and origin checking that Dropbox do after establishing the WSS connection. Malware in the form of a local daemon on a public computer where someone logs into Dropbox will not be able to authenticate with the web app.
logn 12y ago
They're not blocking all access, just sub-resources from Internet pages (you can still develop/use local servers). And they're adding a command line switch and enterprise policy to allow localhost. Also this is preferred way to communicate with localhost: https://developer.chrome.com/extensions/messaging https://developer.chrome.com/extensions/messaging https://developer.chrome.com/extensions/nativeMessaging https://developer.chrome.com/extensions/nativeMessaging
- jorangreef 12y ago
  Sub-resources includes websocket connections. The link you point to is not a standard and will not work cross-browser. You will also need to package your app using Chrome's format AFAIK. Basically, it's not really an option at this point in time.
  - logn 12y ago
    I agree with you and someone has mentioned this on the issue, as well as a proposed exception to this policy: https://code.google.com/p/chromium/issues/detail?id=378566#c32 https://code.google.com/p/chromium/issues/detail?id=378566#c...
- dvirsky 12y ago
  Yep, this is a good thing. Apart from dev work, I like the pattern of local Web UIs for installed apps, I wish they were more commonplace - without risking the user's security.
  - jorangreef 12y ago
    Yes, but it should not be blocking access to wss with DNS resolving to 127.0.0.1 and valid SSL certificate, which is what they are planning to do, breaking web apps such as Dropbox which rely on this.
    - dvirsky 12y ago
      Can't using CORS Allow-Origin headers solve this issue, if there's a domain for localhost and a valid certificate for it?
yskchu 12y ago
Well we can still enable it if we need it "In conjunction with the change, we will need a command line switch and enterprise policy to revert to the older behavior for testing and legacy applications."
- jorangreef 12y ago
  If you rely on connecting your web app with a locally installed daemon (properly secured using wss and additional mutual authentication) then that's not really an option either, as you can't expect your users to know how to use command line switches. Cutting off access to wss is a big deal.
  - andybak 12y ago
    Command line switches are a bitch on OS X. Is an about:config switch not being considered? If so I'd imagine the thinking might be "too easy to social engineer round this".
andor 12y ago
Not just to localhost, but to most of the IANA reserved space, including 192.168.0.0/16 and 10.0.0.0/8: http://code.metager.de/source/xref/chromium/net/base/net_util.cc#462 http://code.metager.de/source/xref/chromium/net/base/net_uti...
- easytiger 12y ago
  How the hell do you access your router's admin page then?
  - jorangreef 12y ago
    That will still be possible. The issue is about blocking access to secure websocket on localhost from public web pages. Routers don't generally use websocket, and if they do, probably not secure websocket.
  - detaro 12y ago
    By going there directly. It is only about sub-ressources in pages (so if you go to badsite.com it can't trigger a request to your router, which given the security track record of your average home router is a good thing)
  - wwarren 12y ago
    Seems like it only limits OTHER sites/pages from being able to access localhost or 192.168.x.x I think you'll still be able to access those pages directly yourself
    - easytiger 12y ago
      thanks, misunderstood
pilif 12y ago
I can see to not allow connections to be made to any host in the local network. That's fine. But blocking access to the loopback interface is IMHO going a bit too far as this was until now a very portable and secure way for websites to talk to locally installed helper applications. Dropbox does this, Github for Mac does this (and incidentally, my own home-grown solution for reading barcode scanners does this too). I really don't want to have to end up in a world where we have to write browser-specific solutions (the method recommended in the issue is chrome-specific) for these kind of things.
- silon3 12y ago
  Unfortunately, 'localhost' is not multiuser safe. So a better (cross browser!) alternative would be OK.
  - icebraining 12y ago
    Multiuser on localhost can be safe like any other website; you just need authentication.
justinschuh 12y ago
I filed this bug (along with http://crbug.com/458362 http://crbug.com/458362), and there's a bit of context that may be missed. First, this is to protect weak devices and services on private networks or localhost, that really can't be safely exposed to attacks pivoting from the web. It will block only sub-resource loads and navigation from the web to private networks. Navigating directly (via bookmarks or omnibox) or in the other direction (from private to web) is still fine. Essentially, this is applying similar rules to what's already in place for file URLs. We also appreciate the concerns for legacy apps, local servers, etc. That's why we plan on supporting blocking UI overrides, opt-in by the page on localhost/private (maybe via CORS headers), and permanent exceptions via the command-line and enterprise policy. So, there might need to be some small tweaks, but all the use cases I've seen described in this thread should still work in a portable manner after these changes are made. Also, to my knowledge no one is actively working on these changes yet. Hence why the details in the bugs are still a bit nebulous. Although that is likely to change pretty soon.
- jorangreef 12y ago
  It's great to block access to http routers on localhost, which I think was the original point of the bug. But it's essential that access to secure websocket on localhost not be blocked in the process (which appears to be the case is it stands). That's the reason for posting here in the first place.
  - justinschuh 12y ago
    As I already stated, we plan on having an explicit opt-in for these cases. However, what you're describing is an implicit opt-in (external DNS pointing to localhost, etc.), which can be trivially abused by third-parties in exactly the kind of attacks we're trying to prevent.
    - jorangreef 12y ago
      WSS already has explicit opt-in in the Origin header.
justinschuh 12y ago
FWIW, the title is beyond sensationalist, and outright wrong. The title on the link is "Block sub-resource loads from the web to private networks and localhost".
xg15 12y ago
I absolutely agree that an exception for legitimate use cases is necessary. (And that a proprietery Chrome API - which in addition is only available to approved extensions - is not an option) However, I don't see what security benefits TLS or DNS records would bring in this case and why they should be requirements for the exception. If your goal is to protect local daemons from malicious web sites, then I don't see why the usual CORS restrictions aren't enough. Maybe they aren't (You could tighten them a bit, e.g. not allowing "Allow: *" responses, treating all requests as CORS non-simple or even only allowing WebSocket connections if you must), but forcing TLS or a DNS entry doesn't seem to increase the security: If I were an attacker, there is nothing that keeps me from trying wss://localhost or wss://www.dropboxlocalhost.com in addition to plain localhost. So what security benefit would that bring? If you want to protect a legitimate web page from malicious daemons, those measures won't help you either: I can simply download your legitimate daemon, extract the TLS private key and generate a valid certificate for www.dropboxlocalhost.com myself - or I just install a custom root CA certificate and use my own private key. But I don't think defending against the latter scenario is very useful anyway: Either the "malicious" daemon has been purposefully installed by the user, in which case blocking it would be against user interests, or it is part of a malware. In that case, the malware will have dozens of other ways to compromise your web page and you will generally have bigger things to worry about. So, why can't we simply use CORS to protect connections to localhost like we do for everything else?
- jorangreef 12y ago
  The reason that web apps such as Dropbox currently go to all the effort of a public DNS record (www.dropboxlocalhost.com) resolving to 127.0.0.1 plus an SSL certificate for that domain, plus mutual authentication after the websocket is established, is because it's currently the only pragmatic way to setup a non-"mixed content" connection to a localhost websocket server. It doesn't increase security as you point out. It's just that it's the only way to do it. Any other connection would be blocked by browsers (e.g. a connection from https web app to a non-tls ws localhost server). The bug ticket referred to would seek to block this last remaining way of connecting, forcing localhost daemons to connect to the web app via server proxy.
  - 12y ago
rasz_pl 12y ago
You want _your_ browser to connect to _your_ local resources? BITCH PLEASE! Whats next? Maybe you want non gimped SD card access for you android apps? HAHA. We have ze Cloud specifically so you are forced to use us as the middle man, and we can see all of your data. How else are we going to make any money off of you? PS: Oh, and its about security in journa^^ of your data!
- narrowrail 12y ago
  The only people this would inhibit do not know what a daemon is in the first place. I have no interest in da clowd.

74 points by jorangreef 12y ago

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.

Theodores 12y ago

Does this mean I cannot develop on localtest.me (that resolves to 127.0.0.1)?

dvirsky 12y ago
From the description, it only means that external pages won't be able to access resources on localhost, but you could still develop on localhost as usual.

orf 12y ago

This is a good thing. I recently found an exploit in a widely-distributed bit of software that listened on localhost but had minimal protection against malicious inputs. Anyone who could trigger your browser to make a crafted request to locahost (which is very easy) could make this bit of software download and execute any remote executable.

jorangreef 12y ago
Yes it is, but if you read closer, you will see that they are also planning to block access to secure websocket servers with public dns resolving to 127.0.0.1 and valid ssl certificates setup precisely for the purpose of being accessed by the public web. This is completely unnecessary.
- acqq 12y ago
  But then malware can exploit every user of Dropbox, for example, it doesn't even need their own certificate. And even the users wo don't have Dropbox are vulnerable throgh Dropbox's DNS entry.
  - jorangreef 12y ago
    There are already plenty of public DNS records which resolve to 127.0.0.1. They're offered as services. For example, 37Signals have a domain resolving to localhost. Malware on a user's computer already has access to everything the user has. Malware on a website would be blocked by the mutual authentication and origin checking that Dropbox do after establishing the WSS connection. Malware in the form of a local daemon on a public computer where someone logs into Dropbox will not be able to authenticate with the web app.

logn 12y ago

They're not blocking all access, just sub-resources from Internet pages (you can still develop/use local servers). And they're adding a command line switch and enterprise policy to allow localhost. Also this is preferred way to communicate with localhost: https://developer.chrome.com/extensions/messaging https://developer.chrome.com/extensions/messaging https://developer.chrome.com/extensions/nativeMessaging https://developer.chrome.com/extensions/nativeMessaging

jorangreef 12y ago
Sub-resources includes websocket connections. The link you point to is not a standard and will not work cross-browser. You will also need to package your app using Chrome's format AFAIK. Basically, it's not really an option at this point in time.
- logn 12y ago
  I agree with you and someone has mentioned this on the issue, as well as a proposed exception to this policy: https://code.google.com/p/chromium/issues/detail?id=378566#c32 https://code.google.com/p/chromium/issues/detail?id=378566#c...
dvirsky 12y ago
Yep, this is a good thing. Apart from dev work, I like the pattern of local Web UIs for installed apps, I wish they were more commonplace - without risking the user's security.
- jorangreef 12y ago
  Yes, but it should not be blocking access to wss with DNS resolving to 127.0.0.1 and valid SSL certificate, which is what they are planning to do, breaking web apps such as Dropbox which rely on this.
  - dvirsky 12y ago
    Can't using CORS Allow-Origin headers solve this issue, if there's a domain for localhost and a valid certificate for it?

yskchu 12y ago

Well we can still enable it if we need it "In conjunction with the change, we will need a command line switch and enterprise policy to revert to the older behavior for testing and legacy applications."

jorangreef 12y ago
If you rely on connecting your web app with a locally installed daemon (properly secured using wss and additional mutual authentication) then that's not really an option either, as you can't expect your users to know how to use command line switches. Cutting off access to wss is a big deal.
- andybak 12y ago
  Command line switches are a bitch on OS X. Is an about:config switch not being considered? If so I'd imagine the thinking might be "too easy to social engineer round this".

andor 12y ago

Not just to localhost, but to most of the IANA reserved space, including 192.168.0.0/16 and 10.0.0.0/8: http://code.metager.de/source/xref/chromium/net/base/net_util.cc#462 http://code.metager.de/source/xref/chromium/net/base/net_uti...

easytiger 12y ago
How the hell do you access your router's admin page then?
- jorangreef 12y ago
  That will still be possible. The issue is about blocking access to secure websocket on localhost from public web pages. Routers don't generally use websocket, and if they do, probably not secure websocket.
- detaro 12y ago
  By going there directly. It is only about sub-ressources in pages (so if you go to badsite.com it can't trigger a request to your router, which given the security track record of your average home router is a good thing)
- wwarren 12y ago
  Seems like it only limits OTHER sites/pages from being able to access localhost or 192.168.x.x I think you'll still be able to access those pages directly yourself
  - easytiger 12y ago
    thanks, misunderstood

pilif 12y ago

I can see to not allow connections to be made to any host in the local network. That's fine. But blocking access to the loopback interface is IMHO going a bit too far as this was until now a very portable and secure way for websites to talk to locally installed helper applications. Dropbox does this, Github for Mac does this (and incidentally, my own home-grown solution for reading barcode scanners does this too). I really don't want to have to end up in a world where we have to write browser-specific solutions (the method recommended in the issue is chrome-specific) for these kind of things.

silon3 12y ago
Unfortunately, 'localhost' is not multiuser safe. So a better (cross browser!) alternative would be OK.
- icebraining 12y ago
  Multiuser on localhost can be safe like any other website; you just need authentication.

justinschuh 12y ago

I filed this bug (along with http://crbug.com/458362 http://crbug.com/458362), and there's a bit of context that may be missed. First, this is to protect weak devices and services on private networks or localhost, that really can't be safely exposed to attacks pivoting from the web. It will block only sub-resource loads and navigation from the web to private networks. Navigating directly (via bookmarks or omnibox) or in the other direction (from private to web) is still fine. Essentially, this is applying similar rules to what's already in place for file URLs. We also appreciate the concerns for legacy apps, local servers, etc. That's why we plan on supporting blocking UI overrides, opt-in by the page on localhost/private (maybe via CORS headers), and permanent exceptions via the command-line and enterprise policy. So, there might need to be some small tweaks, but all the use cases I've seen described in this thread should still work in a portable manner after these changes are made. Also, to my knowledge no one is actively working on these changes yet. Hence why the details in the bugs are still a bit nebulous. Although that is likely to change pretty soon.

jorangreef 12y ago
It's great to block access to http routers on localhost, which I think was the original point of the bug. But it's essential that access to secure websocket on localhost not be blocked in the process (which appears to be the case is it stands). That's the reason for posting here in the first place.
- justinschuh 12y ago
  As I already stated, we plan on having an explicit opt-in for these cases. However, what you're describing is an implicit opt-in (external DNS pointing to localhost, etc.), which can be trivially abused by third-parties in exactly the kind of attacks we're trying to prevent.
  - jorangreef 12y ago
    WSS already has explicit opt-in in the Origin header.

justinschuh 12y ago

FWIW, the title is beyond sensationalist, and outright wrong. The title on the link is "Block sub-resource loads from the web to private networks and localhost".

xg15 12y ago

I absolutely agree that an exception for legitimate use cases is necessary. (And that a proprietery Chrome API - which in addition is only available to approved extensions - is not an option) However, I don't see what security benefits TLS or DNS records would bring in this case and why they should be requirements for the exception. If your goal is to protect local daemons from malicious web sites, then I don't see why the usual CORS restrictions aren't enough. Maybe they aren't (You could tighten them a bit, e.g. not allowing "Allow: *" responses, treating all requests as CORS non-simple or even only allowing WebSocket connections if you must), but forcing TLS or a DNS entry doesn't seem to increase the security: If I were an attacker, there is nothing that keeps me from trying wss://localhost or wss://www.dropboxlocalhost.com in addition to plain localhost. So what security benefit would that bring? If you want to protect a legitimate web page from malicious daemons, those measures won't help you either: I can simply download your legitimate daemon, extract the TLS private key and generate a valid certificate for www.dropboxlocalhost.com myself - or I just install a custom root CA certificate and use my own private key. But I don't think defending against the latter scenario is very useful anyway: Either the "malicious" daemon has been purposefully installed by the user, in which case blocking it would be against user interests, or it is part of a malware. In that case, the malware will have dozens of other ways to compromise your web page and you will generally have bigger things to worry about. So, why can't we simply use CORS to protect connections to localhost like we do for everything else?

jorangreef 12y ago
The reason that web apps such as Dropbox currently go to all the effort of a public DNS record (www.dropboxlocalhost.com) resolving to 127.0.0.1 plus an SSL certificate for that domain, plus mutual authentication after the websocket is established, is because it's currently the only pragmatic way to setup a non-"mixed content" connection to a localhost websocket server. It doesn't increase security as you point out. It's just that it's the only way to do it. Any other connection would be blocked by browsers (e.g. a connection from https web app to a non-tls ws localhost server). The bug ticket referred to would seek to block this last remaining way of connecting, forcing localhost daemons to connect to the web app via server proxy.
- 12y ago

rasz_pl 12y ago

You want _your_ browser to connect to _your_ local resources? BITCH PLEASE! Whats next? Maybe you want non gimped SD card access for you android apps? HAHA. We have ze Cloud specifically so you are forced to use us as the middle man, and we can see all of your data. How else are we going to make any money off of you? PS: Oh, and its about security in journa^^ of your data!

narrowrail 12y ago
The only people this would inhibit do not know what a daemon is in the first place. I have no interest in da clowd.