Chrome Will Limit Access To Private Networks, Citing Security Reasons (therecord.media) 32
Google says that its Chrome browser will soon block internet websites from querying and interacting with devices and servers located inside local private networks, citing security reasons and past abuse from malware operations. From a report: The change will take place through the implementation of a new W3C specification called Private Network Access (PNA) that will be rolled out in the first half of the year. The new PNA specification adds a mechanism inside the Chrome browser through which internet sites can ask systems inside local networks for permission before establishing a connection. If local devices, such as servers or routers fail to respond, internet websites will be blocked from connecting.
Scary title (Score:5, Informative)
It should be "block access to local websites from external domains", or something along that line. When I saw the title, I was really worried, thinking "will the browser really stop working without Internet?", then I realized it was just a security mechanism to disallow access to IoT and other local devices by making the user's browser into a proxy.
and what about captive portal setups? (Score:2)
and what about captive portal setups? that may really mess up networks that use them.
Re: and what about captive portal setups? (Score:2)
Re: (Score:3)
Ubiquiti and Synology both, for starters. However, it should only require a firmware update to allow it to answer the initial query with Access-Control-Allow-Private-Network: true in its headers.
And the remote device gets a Host: header to know what domain is wanting to load its resources on its page.
Re: (Score:2)
Provided that the manufacturer of the device chooses to actually provide such a firmware update, as opposed to requiring the purchase of a support contract or even new hardware in order to send this response header.
Re: (Score:3)
This is a big one, because lots of devices do this. Netgear routers use routerlogin.net - you visit that website, it goes to your router's login page, regardless of what IP range you configured it (i.e., it's not a static redirect to 192.168.1.1 - it finds your
Re: (Score:2)
External web sites scanning for devices on the local network lies squarely within the range of potentially malicious actions this change is designed to stop. mDNS is obviously the preferred answer for discovering local services but there are other ways to get similar results without scanning. For gateway routers a simple and common solution (provided you use the default DNS) is for the router to provide its own internal IP address in response to DNS queries for a well-known hostname (e.g., you could use gat
Dynamic DNS under what subdomain? (Score:2)
Another option which works for non-routers is to give the device its own randomly-generated subdomain which it can update with its internal IP address
In other words, dynamic DNS service like Plex does. Who would provide the service? (In other words, under what domain name would the subdomain be randomly generated?) If the device's manufacturer would operate this dynamic DNS service, I can think of two drawbacks. How would one go about solving those?
1. The operator of said domain name has an incentive to stop providing dynamic DNS service to the owner of a particular device the day the device's 12-month warranty expires.
2. It would seem to work only for a
Re: (Score:2)
In general, the device's manufacturer or the provider of the software would provide this service. Sure, you're dependent on the manufacturer, but that's not any different from the original scenario where the manufacturer provides a page which scans the local network (like routerlogin.net). With luck you'd have access to mDNS as a fallback in case the service ever disappears.
In principle a neutral third party could do it instead, and support any kind of device (or software). There are any number of free or c
Re: (Score:2)
This is a big one, because lots of devices do this. Netgear routers use routerlogin.net - you visit that website, it goes to your router's login page, regardless of what IP range you configured it (i.e., it's not a static redirect to 192.168.1.1 - it finds your gateway IP and uses that).
I'm not sure how big of a deal this is. That is, I'm not sure it's doing what you think it's doing. For example, if you switch your DNS to e.g. Google DNS, the routerlogin.net redirect stops working, and you have to use your router's IP address. That suggests to me that the magic is happening between the router and the client, no scanning involved.
Re: (Score:1)
and what about captive portal setups? that may really mess up networks that use them.
Good riddance, I say. Captive portals can be a huge p.i.t.a., preventing some devices from connecting altogether.
Re: (Score:3)
If they're implemented properly, you either access it from a private, local URL or directly from an external URL. If they use an external web site that loads resources from an internal server, they're absolutely doing it wrong.
Re: (Score:2)
and what about captive portal setups? that may really mess up networks that use them.
How? It should be your router redirecting their web requests to the captive portal server.
It has no need to ask their browser to connect anywhere except to the portal directly, so there's nothing to break.
The internal server that runs the captive portal should connect to other internal servers directly, like authentication systems or the NMS that will remove the routers redirect rules or whatnot.
Re: (Score:2)
How about just restricting and blocking access to third party addresses / domains? This should have been done already in the early browsers, but nobody thought about the security issues we see today.
The problem could however be how to identify a private network, especially in a complex corporate environment where public IP addresses are used internally.
In any case if I could go back in time I would have put strong restrictions in on cross-site javascript and other third party data so that for example tracki
Re: (Score:2)
I was going to say that the headline sounded positively dire, until the very last sentence where it made clear that this was disabling the means for external servers to use the browser to gain access to internal resources.
Not everybody is as technical as you (Score:2)
Anonymous Coward wrote:
Every time I open Chrome is see an outgoing firewall hit for UPNP. If I wanted my router to forwarded unsolicited connections, I'd set it up myself.
I get the impression that most users of desktop and mobile devices are less technical than you. They lack the attention to seek out first how to determine the make and model of router that they are using and second how to forward a port on that router.
Re: (Score:2)
"without a prompt" you have a point. The browser should initiate UPnP when and only when the user gives permission.
This seems unclear (Score:2)
"This preflight request will carry a new header, Access-Control-Request-Private-Network: true, and the response to it must carry a corresponding header, Access-Control-Allow-Private-Network: true.
If local devices, such as servers or routers fail to respond, internet websites will be blocked from connecting."
So which is it?
Is it Chrome sends the request with the new header to existing servers and routers, but they don't recognize it and therefore timeout and never respond back to Chrome?
Or do the existing se
Re:This seems unclear (Score:5, Informative)
This is to prevent rogue javascript from executing HTTP requests on the users behalf on their local network without them knowing. When Javascript makes an HTTP request to a domain other than the origin domain it will send out a preflight request to ask permission. Chrome will recognize that it's trying to connect to the local network and send out a new CORS header to ask permission to connect, and if the hardware rejects the request then an error would be thrown and the javascript would stop execution.
Re: (Score:2)
I understand the need for CORS, but I wish there were some more friendly options for developers. I've been attempting to up my skills in the javascript/Web API department. I spent more time the first few days fighting with CORs than I did writing code. You can get plugins and turn CORs off in Firefox and Chrome, but no matter the settings, Firefox will disable the plugin every time you start up Firefox.
I wish Firefox and Chrome had a developer mode that understood that I'm OK with connecting to localhost:58
Re: (Score:3)
If you're writing your own web apis, you simply set the CORS headers to allow any origin.
https://developer.mozilla.org/... [mozilla.org]
If you're using 3rd party APIs then you can run a proxy server locally that does the same thing.
find.synology.com (Score:1)
*Laughs in Firefox* (Score:2)
*cough*
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
No. Synology would simply have to provide updated software patches for their hardware that allowed the CORS header to be returned correctly.
Re: (Score:2)
Network appliance makers such as Synology also have the power to charge an additional fee for said patches on out-of-warranty devices.
security zones? (Score:4, Interesting)