
Chrome team planning to block all access from browser to localhost wss - jorangreef
https://code.google.com/p/chromium/issues/detail?id=378566
======
justinschuh
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.

~~~
pfraze
> That's why we plan on supporting blocking UI overrides

By that do you mean, an in-browser prompt to allow the connection?

~~~
justinschuh
Pretty much. It would probably be an interstitial on navigation (similar to
how certificate errors are handled) and a page action for subresources
(similar to the shield page action for mixed content).

------
logn
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
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
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#c...](https://code.google.com/p/chromium/issues/detail?id=378566#c32)

------
orf
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
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
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
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.

------
xg15
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
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.

~~~
xg15
Okay, that makes sense. But then the real problem is that solving what should
be a trivial technical problem today requires an extremely wasteful
workaround. If I understood jschuh correctly in [1] and [2], then they plan to
make this workaround unnecessary by treating connections to localhost as
secure even when over plain http/ws.

As I understood, connecting to a daemon, both over ws _and_ wss will still be
possible, as long as the - to be defined - opt-in headers are sent by the
daemon. In fact, the associated change to mixed-content would even allow using
plain ws://localhost on secure sites, which - as you told - isn't possible
today.

Apparently vulnerable services exist and this is a security hole that needs to
be closed. So legitimate users of local connections need to update their
implementations anyway. If that's the case, I'd prefer a solution which just
requires me to add a new response header and not need me to manage a new DNS
entry and TLS cert for no real benefit.

I agree though that this change has possible sweeping implications and should
be done as part of the usual HTML5 process and not unilaterally be chrome.
Also, the opt-in protocol must be specified before this change comes into
effect.

[1]
[https://news.ycombinator.com/item?id=9211034](https://news.ycombinator.com/item?id=9211034)
[2]
[https://news.ycombinator.com/item?id=9210985](https://news.ycombinator.com/item?id=9210985)

------
jorangreef
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.

~~~
diminoten
> 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.

~~~
Piskvorrr
That's the same argument as "You could just not use IE4," and the same
situation: "let's just break the web, we know best what's best for you."
Ironic that it's Chrome this time, the browser that started out as the
champion of NOT breaking the web.

~~~
lmm
> Ironic that it's Chrome this time, the browser that started out as the
> champion of NOT breaking the web.

I don't think that was ever the message. Chrome has always been "the fastest
browser" rather than anything else, and it has lead to (much-needed IMO)
substantial performance improvements from the other camps.

~~~
Piskvorrr
I think you're retroactively spinning it, to fit what Chrome has become
_today_. Let me just find the comics v1 rolled out with.

 _Ahem_ : "There are a lot of limitations to the kinds of applications that
you can build today with web browsers. And the subset of things you can do is
different for each browser. If _one_ browser has a cool feature, that doesn't
help -- it has to exist across _all_ browsers in order for developers to use
it." (Emphasis original)

But yeah, Google _says_ they're not evil, so that _makes_ anything they do
non-evil...riiiiight. I have a feeling we're not in Kansas anymore.

~~~
lmm
I'm not trying to be retroactive - I genuinely don't remember any comics -
just the videos with the lasers and whatnot to show how fast it was.

~~~
Piskvorrr
Well, it's still out there. The main selling points were:

\- it's safe

\- it's fast

\- it's stable

\- doesn't break the web

All of that in contrast with IE of that time, which failed all four of the
above. Currently it's trying to stay somewhat safe, and ditched the other
three in the process.

[https://www.google.com/googlebooks/chrome/](https://www.google.com/googlebooks/chrome/)

------
pilif
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
Unfortunately, 'localhost' is not multiuser safe. So a better (cross browser!)
alternative would be OK.

~~~
icebraining
Multiuser on localhost can be safe like any other website; you just need
authentication.

------
andor
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_uti...](http://code.metager.de/source/xref/chromium/net/base/net_util.cc#462)

~~~
easytiger
How the hell do you access your router's admin page then?

~~~
wwarren
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
thanks, misunderstood

------
justinschuh
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".

------
rasz_pl
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
The only people this would inhibit do not know what a daemon is in the first
place. I have no interest in da clowd.

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

~~~
dvirsky
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.

------
yskchu
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
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
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".

