35 ms·

Chrome may start restricting requests to private networks

267 points by zdw 5y ago

coldacid 5y ago
Every day my belief that the web should never have been allowed to go beyond hyperlinked documents grows stronger.
gunapologist99 5y ago
Yes, this potentially increases security, but it further increases Google's control over even my private network? There surely must be a better way.
- ep103 5y ago
  Firefox
  - guywithahat 5y ago
    Yeah but then I have to use firefox, and the way Mozilla's marketing (and user) numbers have been going it feels like a losing battle. I mean not to long ago they put out a paper on why a distributed internet is bad and ways to stop it; the people running Firefox are completely out of touch
bugmen0t 5y ago
Pretty sure you will be able to opt out via group policy. If you control your network so hard that you can accept CSRF, it even makes sense. But would you swear that none of your smart devices are terribly insecure and incapable of even updating at all? You’ll have my utmost admiration if you can.
Macha 5y ago
Hmm, this may break a project I'm working on, depending on how far it goes. It's a web based client to a service that is commonly self hosted. Users enter the URL of their server instance at startup. That server is frequently on the users home network. I have a public instance of the client hosted for a zero install user experience. I think this immediate change would be fine since that public instance is a secure context, but it sounds like the ultimate direction is to prevent web->local access altogether.
- afavour 5y ago
  I think you should be able to provide CORS headers in the local server and have the functionality still work.
  - Macha 5y ago
    I don't control/develop the server application. It lets users configure it and defaults CORS to pretty open access to its API endpoints. That part is fine. It just seems from this thread that the direction is to shut down that access entirely.
    - afavour 5y ago
      I’d ignore this thread and go to the spec. If local servers are emitting CORS headers they’ll work: https://wicg.github.io/private-network-access/#example-opt-in https://wicg.github.io/private-network-access/#example-opt-i...
vadfa 5y ago
Years ago I noticed any webpage could just use an <img> tag to include an image hosted in my LAN. For example, adding such a tag to any website to include a link to the usual gateway ip addresses (192.168.0.1 and so on) will trigger an http authentication dialog for many users. It's the kind of thing that I thought would be impossible because it seems like such a boundary crossing. Glad they are eventually fixing this...
- southerntofu 5y ago
  That's what we get for enabling 3rd party requests on the web in the first place. Hyperlinks are great but enabling content from/to 3rd parties was definitely a design mistake of the web. Gemini definitely got this right, so when you run a query to a server, there's only 2 parties involve and no external tracker, and no served script to try and undermine your security by scanning your local network. Seriously, if you'd told me in the mid-90s we'd have connected locks and lightbulbs and surfing to a random website could alter physical properties of my surroundings and scan my local network for vulns without my consent, i would probably have given up on IT entirely as humanity's doom.
rusk 5y ago
I initially read “restrict” as “prohibit” and felt my blood rise. No harm I suppose so long as I can still do it in certain specific circumstances.
zoobab 5y ago
Tell me to avoid this browser, and all other browsers based on it.
ur-whale 5y ago
The list of good reasons to switch away from Chrome is getting very long.
tejohnso 5y ago
The chrome developer blog has a good writeup[1] about this. [1]: https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd...
EvanAnderson 5y ago
I'll work around this, when I need to, by picking some backwater public IPv4 space and using that for the subnet where I put my on-prem-hosted servers. (Maybe North Korea's address space...) I get the "public IP" behavior of the browser and, as a bonus, that "real" IP space on the Internet is inaccessible to my end users and servers!
- rootusrootus 5y ago
  I did something like this, though it wasn't public space exactly. I had to live with a work VPN that routed all traffic for all RFC1918 addresses into the corporate network. Because we had acquired companies over the years with their own RFC1918 choices, and not all was integrated and renumbered. Since I wanted to be able to reach my own home gear at times, I used 192.0.2.0/24 for my network. Not technically RFC1918, but not used in public, either. I still remember the incredulity from one of my friends saying "but, but, you just took someone else's addresses?" and I said "sure, but whose? does it matter?" and then he looked it up on rwhois and started reading the company name... he got as far as 'Internet Corporation for Assigned...' and then he stopped and threw something at me. Ha! There are a number of non-public but not commonly used address spaces out there, I suspect most of them would suffice for getting around Chrome's RFC1918 blocking. Though it's possible they have another heuristic for determine what constitutes a 'private' address that includes space other than the officially recognized RFC1918 subnets.
  - rootusrootus 5y ago
    One thing I forgot to mention. Some consumer devices make assumptions about RFC1918 space, and will not operate if they think they're running on a public IP. This is what prompted me to switch back into RFC1918 for my home network (and I had long since left the company with the voracious VPN anyway). YMMV, of course, but it's something to keep in the back of your head if you plan to switch out of RFC1918 for your home network.
    - EvanAnderson 5y ago
      We ran into some of these different behaviors when we hit a Customer who was using the 192.9.0.0/24 network internally. (Then we hit a few more. Several police departments in Western Ohio are using that subnet internally for some reason. Some vendor in common must have come thru and done it.)
thrdbndndn 5y ago
Maybe different scales, but some of the restrictions already happened in M94. I used to use a remotely hosted web GUI to control my local ari2c RPC but since then I have to move it to my local network.
roody15 5y ago
The big players continue to try and push out smaller independent outlets… always under the banner of “security”. There are lots of split horizon setups in small to medium size businesses, schools, colleges etc. Just another attempt to try and push a “cloud” rent model.
dpryden 5y ago
Overall this seems like a very positive change. However, I wonder how it will affect local development of servers that participate in API flows with public-facing systems. As an example: imagine I am developing my application locally, at http://localhost:8080/ http://localhost:8080/ , and this application supports an OpenID Connect identity flow with an identity provider, https://idp.corp.example https://idp.corp.example . Today I can test the login flow by telling the IDP that localhost:8080 is a valid URL to redirect back to, so that I can click a "login" button in my application, log into the real IDP, and get a token posted back to something like http://localhost:8080/idp-callback http://localhost:8080/idp-callback . This makes it easy to develop a system locally that also communicates with various backend microservices which require authentication with a common IDP. I can't imagine that this is a rare scenario: it seems pretty normal to me. But if I understand the proposal, it sounds like the long-term goal is to prevent this kind of environment for local development, and instead force you to either run your dev stack remotely (with a public IP!) or else run your entire IDP stack locally (so that it has a local IP). Neither of those seem like good ideas to me. Of course, the other option would be to modify local dev servers to accept CORS preflight requests and respond correctly, but I'm always slightly uncomfortable adding code into a local dev stack that would be unsafe if enabled in production. At very least it makes it harder to debug when something inevitably goes wrong with this API flow. There are probably ways to solve this by introducing more proxies into a local dev stack, but I worry that these kinds of little papercuts will just make development that much harder for microservices-architecture applications, which are already hard enough to develop and debug as it is.
- Sohcahtoa82 5y ago
  If you have a domain that you can control the DNS of, you could temporarily stand up an internet-facing server for localhost.yourdomain.com, get a certificate, then change the DNS to localhost.yourdomain.com to 127.0.0.1 (or put it in your HOSTS file), then address it with localhost.yourdomain.com rather than just localhost. But yeah, I think really, browsers should be able to allow self-signed certs for localhost.
  - jabbany 5y ago
johnchristopher 5y ago
Chrome is a bit of a PITA for local dev now that it also prevents me from using https://localhost https://localhost with self signed certificates. There are some flags you can toggle in chrome/chromium but I can't figure out which versions still support them.
- jaywalk 5y ago
  As long as you go through the steps for your OS to properly trust the certificate, Chrome won't block it or even throw up a warning.
  - johnchristopher 5y ago
    Ain't got no time for that. In Firefox I just click "accept" for my *.localhost and I am done. It used to be that straight forward in chrome/chromium but now I'd have to meddle with certificate stores, etc.
- paulirish 5y ago
  The modern guide for this is https://web.dev/how-to-use-local-https/ https://web.dev/how-to-use-local-https/ and the flag you probably want is #allow-insecure-localhost but the guide steers you towards local trusted certs as an improvement over self-signed.
  - johnchristopher 5y ago
    Thanks, I'll probably revisit that when I have too many pitfalls with ff+allow self signed.
- jabbany 5y ago
  If you have a domain already, you can get a certificate for free from Let's Encrypt and just repurpose the certificate. You don't even have to run an out facing HTTP server as they have a DNS-only challenge. I have a similar setup where I have something akin to "my-home.network" and manage a wildcard cert from Let's encrypt through a local cron job. My router intercepts all the DNS requests to the domain and returns local IPs on the local network. Machines that need HTTPS can get a copy of the wildcard key and do something like "hostname.my-home.network" and get HTTP.
lnanek2 5y ago
Would we be nice if they'd fix wifi terms of service pages first before layering on yet another security screen. Every time I go to the gym or mail room it's a five minute battle with Chrome to let me see my apartment complex's terms of use screen so I can access the internet. Our building doesn't get good cellular data service inside. Yes, I'm sure I want to see the terms of use page, Chrome. No, I don't need to be an advanced user to know that. Actually I do since you only let me get redirected to it if I know to type an http site you haven't seen first instead of an https one...
- jaywalk 5y ago
  http://neverssl.com http://neverssl.com is perfect for that scenario.
- Sohcahtoa82 5y ago
  Whenever I'm fighting with a WiFi that doesn't properly send me to a capture portal, I open a browser window to http://www.neverssl.com/ http://www.neverssl.com/ . It was specifically created for this purpose.
gwbas1c 5y ago
One thing I don't understand is: What defines "local" or "private?" Is it by IP?
- marcosdumay 5y ago
  I imagine anything on the loopback or the local scope IPs. I'm curious what it will do with the 10.0.0.0/8 network.
- jabbany 5y ago
  Yes. It's in the doc: https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/ Of course one obvious workaround is to misconfigure your router to allocate from a non-private but unused/reserved address space. That way your internal network is also on the "outside".
marshray 5y ago
Think of every developer tutorial that shows you how to get started running HTTP on localhost port 8080 (or whatever). Authentication is left as an exercise for later. Every web page you visit can access that site.
egberts1 5y ago
That would completely screw up my Chrome usage as I’ve got some pretty esoteric network setup having dual-homed route table, some private 13-server Root DNSSEC, and no, just no, Chrome. oh wait, I haven’t used Chrome in 2 years. whew. Never mind.
unethical_ban 5y ago
This seems like it would break certain caching solutions.
- rocqua 5y ago
  Care to elaborate more?
  - unethical_ban 5y ago
    Honestly, not much. I was a little buzzed and was throwing out thoughts. I was imagining local caches of assets or large content, like a web proxy.
kazinator 5y ago
The NoScript extension for Firefox has been doing this for years.
- southerntofu 5y ago
  Best answer so far. There is absolutely 0 legitimate reason (that i can think of anyway) a website should be making requests from your browser to another website without explicit user consent/interaction. Hyperlinks are great, but random javascript crap making request on our behalf is just harming us users.
  - kazinator 5y ago
    It doesn't have to be Javascript. I made an application many years ago that used almost zero Javascript. The only piece of JS is an onLoad handler to position a cursor on a particular field when a page loads. The application uses its own web server, so the browser talks to localhost. For licensing, the application sends the user to my domain, whose pages can send the user back to the app on localhost, again with no JS. The NoScript suite detects and blocks that. The simple fact of a remote website serving up a local URL via dynamic HTML is enough.
    - netizen79865243 5y ago
      with "The application uses its own web server, so the browser talks to localhost." you are not actually saying that your application itself contains a webserver, running inside a browser, serving a website running on localhost, are you?
      - kazinator 5y ago
        In this case, the application is a native executable containing a web server. (It runs in the background, controlled by an icon in the desktop notification area, which can also be double-licked to open a browser to the application's URL).
exabrial 5y ago
We run all of our traffic over ipsec to our VPS. It's https anyway, but I don't really care for Google to know how many clients I have behind my network. Everything is in 10.x.x.x space. No, we're not going to do let-everyone-access-everything. We believe in layered security. Locks on the front door, locks to get around the house.
- notatoad 5y ago
  Seems like as long as everything is in the 10.x.x.x/8 range and a user gets there by typing the IP into their address bar, nothing is going to change for you. This is only about mixing public and private contexts. If you have a link to private IP space on a public website, then you're going to get warnings.
  - deleted 5y ago
    [deleted]
  - rocqua 5y ago
    I presume DNS names that resolve to 10.x.x.x are also fine to write into your address bar directly? It seems to me the issue with a DNS split-horizon is that google results return DNS names that are in your local intranet, and thus resolve to a local IP, but you clicked on that link from the outside world, and hence chrome would block that.
    - southerntofu 5y ago
      Yes it would be fine. The issue would arise if you connect to a remote service which then instructs your browser to run local queries.
    - notatoad 5y ago
      I think any sort of split-horizon on devices you don't fully control is going to start giving you a lot of problems going forward. For example, any sort of DNS-over-https is going to make split-horizon non existent unless you control the client device. And presumably if you control the client to change the DNS behaviour, you could turn off this new behaviour too. Fwiw, I think this is generally good. Network operators shouldn't be able to arbitrarily intercept traffic on their networks.
tptacek 5y ago
The backstory on this, if you don't follow web security at all, is that building public web pages to trick browsers into talking to private networks (or your loopback interface) is a surprisingly pernicious attack vector. The modern countermeasure for this is to require devices parked on private networks to opt-in to the ability mix public Internet requests with private network accesses, using CORS, which is what this is about. You should probably be mostly thrilled about this development.
- api 5y ago
  This is why one of my security mantras has become: if it is not secure enough to connect to the open Internet, it is not secure at all. That doesn't necessarily mean you connect it to the open Internet, but it means you don't leave everything inside wide open because "oh there's a firewall." It also means buggy vulnerable IoT (Internet of Targets) stuff has to be dealt with. Firewalls are almost security theater. They're just a basic precautionary thing. Same goes for virtual and zero trust networks. Systems must be secure, period.
- cmaggiulli 5y ago
  So would this be like creating a public webpage called “help troubleshoot my router”, and having that webpage serve up malicious JavaScript which attempts to attack my routers local web server?
- deleted 5y ago
  [deleted]
- Ajedi32 5y ago
  Been following this for a while; I'm really surprised it's taken so long for browsers to begin to address this problem. It's kinda crazy that random websites can just send any HTTP request they want to your private network or local PC with no restrictions; that's a pretty huge attack surface to expose to the public internet. Even this measure by Chrome is extremely limited, as it sounds like they're only blocking insecure (HTTP) sites from making requests to your private network. HTTPS sites are unaffected (for now).
  - 5y ago
shadowgovt 5y ago
""" But perhaps the risk of CSRF attacks against insecure devices on private networks or localhost is severe enough to justify such a change. I see only one side of this whole issue, not both of them. """
deleted 5y ago
[deleted]
missblit 5y ago
> While the specification has some suggestions, I'm not sure that it would allow our specific situation even if we could get all of the people with web servers that are possibly affected by this to make changes to them. Wouldn't this be as simple as an `Access-Control-Allow-Origin: *` (plus all the other junk mentioned in the opt-in section[1] of the draft spec). I'm having a hard time of thinking what wouldn't be workable in the author's situation (assuming he gets all the people with webservers to add headers to them). And yes... understanding CORS should absolutely be a requirement for writing local webservers that people can poke from the public internet; being able to stumble your way through writing a CORS policy is basic web security at this point. [1] https://wicg.github.io/private-network-access/#example-opt-in https://wicg.github.io/private-network-access/#example-opt-i...
- EvanAnderson 5y ago
  The author is in a large University context where getting everybody who runs all the web servers (various departments, schools, etc) to add headers probably is really difficult (especially when you consider potentially closed-source applications or embedded devices that aren't easily updated).
  - jabbany 5y ago
    It's not that hard though given we're working with HTTP... Since they control the network (DNS and all) couldn't they just wrap non-compliant devices behind a forwarding proxy that adds those headers? Like rather than resolve to the device, resolve to a proxy that adds those headers.
    - EvanAnderson 5y ago
      No, it's not particularly hard, but it is complicating the plumbing. We have to make the Internet safe for manufacturers of devices who can't be bothered to incorporate a modicum of security in their devices.
      - jabbany 5y ago
PragmaticPulp 5y ago
In case it wasn’t clear: This won’t stop you from going to 192.168.1.1 or otherwise accessing private network resources from Chrome. This is about closing specific public/private boundary security vulnerabilities that you don’t want 99% of the time. The author of this article happens to have a 1% corner case, but the average user generally doesn’t want this.
- fanf2 5y ago
  I think split-horizon DNS is a bit more than a 1% corner case: it's almost universal in corporate and education contexts.
  - phkahler 5y ago
    When I read that all I could think of was routing things through a privacy-invading proxy. Is that what it is?
    - nybble41 5y ago
      There often is such a proxy in these environments but it isn't really related. The scenario here is that you have servers with both internal and external IP addresses, and for whatever reason if someone is connecting from inside the network you want them using the internal IPs and not the external ones. (Simpler routing, different features available to internal clients, etc.) So you set up the DNS servers for your network to serve internal IP addresses for your domains, but anyone outside the network sees the public IPs for those same domains. (That's the "split horizon" part.) Now someone in the network could follow a link from a page served from a public IP to a domain with a private IP address—which this change would disallow unless the first page was served from a "secure context" (with TLS) and the internal server responds to a "preflight" OPTIONS request with the required CORS headers to allow following links from public networks.
      - Anunayj 5y ago
        This is extremely common in Universities where you share 2-4 public IPs that you can usually ask ports to be forwarded to a internal IP, and often there are resources (Like say Servers with GPUs) available on a interally reachable IPs using a easy to use hostname served by the internal DNS server. Ofc this change won't be that big of a issue, things would just need to change a little, using Split-DNS was already a pain when students wanted to say use DNS-over-HTTPS and didn't want the University DNS servers to know every site they visited.
deleted 5y ago
[deleted]
hulitu 5y ago
Why is Google trying to be the smart ass here. Since when network access control and topology is the atribute of a web browser ? What's next ? X server ? OS kernel ?
- pjmlp 5y ago
  ChromeOS.
- adamrezich 5y ago
  filesystem? ...oh wait, google drive updated itself without me asking a few weeks ago, even though I haven't used it in ages, and now, randomly, every few days, I get a popup telling me I need to sign back into drive, even though I closed the system tray application. (is being annoying to the user just an inherent property of this kind of service? are they trying to compete with OneDrive for reluctant end-user obnoxiousness??) there's probably half a dozen ways to get rid of it but it's a nice periodic reminder that I really don't care for google anymore
  - beebeepka 5y ago
    Not sure why you're being downvoted. I had the exact same experience with Epic's craptastic launcher a few years ago. Behind the scenes update followed by a sneaky autostart entry. I hadn't used it in a while and only discovered what had happened by accident months later
    - afavour 5y ago
      OP is probably being downvoted because the rant is pretty off-topic.
- laumars 5y ago
  Since network end points have supported HTTP GET requests. If your router or IoT device isn’t secure any webpage online can embed a (for example) <img src=“http://192.168.1.1/enable_remote_access.php”> And it’s not as if consumer routers nor cheap Chinese IoT hardware have a proven track record for security.
deleted 5y ago
[deleted]
nottorp 5y ago
Hmm question: Will this race to secure the internet mostly by applying ever more complex band aids end up in completely discouraging small entities from running their own public resources? It's already next to impossible to run a public home server. Is it likely to become completely impossible?
- MonaroVXR 5y ago
  >It's already next to impossible to run a public home server. Is it likely to become completely impossible? Why? I try to do this, it's an exercise that I wanted to do.
- sergiomattei 5y ago
  I’m curious. Are there any new major difficulties when setting up home servers? Last time I tried it was a little annoying with dynamic IPs getting in the way, but possible with just a port forward or UPnP. Are ISPs making changes to prevent this?
  - southerntofu 5y ago
    That's about it. In addition, some ISPs make sure you cannot change the resolver advertised on DHCP, and that your own IP is routed via the Internet and back (so local requests are slow as hell), both of which can be hacked around by running your own router behind the ISP's modem/router. Of course, the real solution to the problem is to find a decent ISP, like a non-profit from FFDN.org federation. Then you have "real" internet and no worries for selfhosting.
  - nottorp 5y ago
    And how much time/expertise do you need to not trigger all kinds of warnings in modern browsers?
    - space_fountain 5y ago
      Fairly little? I think you might be thinking of email where running your own email sever is tough
PostThisTooFast 5y ago
WTF is that supposed to mean? Another lazy, bullshit HN headline and another shitty article.
zzo38computer 5y ago
Restricting such requests can be a good idea, but it should be user configurable (e.g. in case you want to redirect some requests to your own implementations), and whether or not it is allowed should have nothing to do with whether or not TLS is used (it means HTTP vs HTTPS, but really that is irrelevant to this issue, which is a different issue). Furthermore, if you do not explicitly type a localhost URL or IP address, it should also block access to stuff on localhost or local networks, again it should be user configurable though in case you want to enable specific cases.
- mattowen_uk 5y ago
  Ok, so I have a dynamic page hosted externally. It's set as my homepage on all my browsers. It's full of links to things I use. Some of those links are on my internal network, and are NOT https (seriously, for small things/apps you don't need it). If I understand this correctly, Chrome will now block me clicking on these links? I'm all for improving browser security, but as an end user, I should have the option to turn settings off that cause me a problem.
  - southerntofu 5y ago
    > Some of those links are on my internal network (...) Chrome will now block me clicking on these links? Unless i missed something, you will still be able to click links. Chrome will block the original page from running queries without your consent to your local networks, eg. a javascript bit trying to find a vulnerable router/crapware on your local network.
  - zzo38computer 5y ago
    > I'm all for improving browser security, but as an end user, I should have the option to turn settings off that cause me a problem. I agree. I will want to configure a lot of things. However, allowing finer configuration can also be helpful; you might not want to turn off that feature entirely. (For example, maybe if you want to assign that dynamic page to the local zone (if such a thing is possible; the article says something else, though) even if it isn't local, then it will be able to work such links.)
yrro 5y ago
I guess this won't/can't protect web services on private networks that nonetheless.use public routable address space? What about IPv6, both public routable address space and ULA space?
- tommiegannert 5y ago
  I was also curious about IPv6 non-local scopes. The spec linked in the article says > User Agents MAY allow certain IP address blocks' address space to be overridden through administrator or user configuration. This could prove useful to protect e.g. IPv6 intranets where most IP addresses are considered public per the algorithm above, by instead configuring user agents to treat the intranet as private. https://wicg.github.io/private-network-access/#ip-address-space-heading https://wicg.github.io/private-network-access/#ip-address-sp... So aside from loopback and link-local, the only effect this will have on IPv6 is what the browser decides to do. If that's a manual add/remove or a look into the routing table seems unspecified.
  - yrro 5y ago
    Ah, I missed the spec link and landed on the design documentation... So I will have to wait to see what form this configuration takes. Hang on a minute, this is suddenly sounding rather familiar--I'm suddenly reminded of the Internet control panel in Windows, which lets you assign web sites to different zones (internet, LAN, trusted, restricted)...
xg15 5y ago
Linked in the Private Network Access draft is a discussion which outlines some general points about HTTPS on local devices and participation of local devices on the web in general. It's interesting to read, even though the results seem rather bleak. https://github.com/wicg/private-network-access/issues/23 https://github.com/wicg/private-network-access/issues/23
readflaggedcomm 5y ago
Just integrate a basic uMatrix into the browser, as it should have, and none of this matters. Why is it impossible to view the origins of resources in one simple interactive panel? That's simpler than the major browsers' dev tools' features, in fact. Except then, the user would have a dashboard of control, which they can not be trusted with.
- southerntofu 5y ago
  Shouldn't we redefined WWW specs to prevent 3rd party requests entirely? It would fix this problem and many others.
amenghra 5y ago
I believe this will fix a ~14 year old bug. Browsers have been punting on dns rebinding forever. Initially documented by Collin, here are two threads: Paper: https://crypto.stanford.edu/dns/dns-rebinding.pdf https://crypto.stanford.edu/dns/dns-rebinding.pdf Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=98357 https://bugs.chromium.org/p/chromium/issues/detail?id=98357 Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=689835#c3 https://bugzilla.mozilla.org/show_bug.cgi?id=689835#c3
- hoppla 5y ago
  Exactly what I think as well. I have not looked into this attack for a while, but have always assumed it still is possible to proxy traffic via a user’s browser
gry_gh 5y ago
Besides NoScript, another webextension addon is doing that: LAN port scan forbidder: https://github.com/garywill/LAN-port-scan-forbidder https://github.com/garywill/LAN-port-scan-forbidder Addon already on Firefox
- gxnxcxcx 5y ago
  uBO has this filter list available by default: https://github.com/gwarser/filter-lists/blob/master/lan-block.txt https://github.com/gwarser/filter-lists/blob/master/lan-bloc...
jabbany 5y ago
This seems mostly benign, basically changing the default cross-boundary behavior from "allow" to "deny" but also providing a way for intranet devices to exclude themselves. On the other hand I'm also not a huge fan of these measures because they address the issue from the wrong end. Servers should protect themselves from CSRF, it shouldn't be the job of browsers to do that. A server (think router or IoT device) shouldn't be like: Hey I'm getting an internal IP anyways so I'm going to be lax. With this there's now no motivation to fix anything from the server/device side so you have failure modes where someone's using a weird/old browser that doesn't preflight and they're vulnerable but everyone still has a false sense of security... Additionally, I'm worried that rather than adopt the whole preflight/headers thing, a lazy org might decide to just repurpose some reserved public IP space for their internal private addressing so things don't "cross-bounds" anymore...It basically becomes unusable security that's circumvented like writing your password on a sticky because it's forced to be really complex. Never underestimate the ability for someone to blow through any and all security or safety measures if they prevent them from doing something that they could do before...
- cygx 5y ago
  As far as I'm concerned, this change is long overdue: Browsers should never have granted arbitrary websites the ability to port scan your local machine and network. Note that Opera came with cross network protections a decade ago, cf https://web.archive.org/web/20121001002815/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20121001002815/http://my.opera.c...
  - jabbany 5y ago
    Scanning is not allowed anyways just from standard cross-origin protections. If intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. It's the same reason you cannot embed an Ajax request in your blog to query someone's bank account's API. In order for information to be made available to the external site, the service has to cooperate with the remote site already. In fact, even CSRF is mostly due to the server misusing HTTP. Look at the example in the W3C doc, where the remote site has a hidden frame/resource that hits local servers. Well guess what, GET requests should not change state, so changing some DNS configuration via a GET request is already doing it wrong. There's no inherent reason an intranet site should be treated any differently from an Internet site. At best the current argument is that "intranet sites are more likely to be hacky and poorly implemented", but that should reflect more on those devices/services on the intranet than anything else.
StingyJelly 5y ago
I feel like this is going to break many IoT devices (definitely my ones) and I wouldn't be surprised if it's a move to push more developers towards integrating with GoogleHomeSpyware™. Since there's still no mdns (resolution of .local domains) in android nor in chromium despite long standing feature requests, workaround I (a hobbyist) and likely other IoT devs chose chose was to host a small website that would brute-force check local ip ranges until the IoT device was found. At least for now I have another reason to transfer hypertext securely but I've honestly no idea for future workaround (other than a large banner saying "install firefox")
- southerntofu 5y ago
  > I feel like this is going to break many IoT devices (definitely my ones) On one hand i'm sorry for you. On the other hand, the less IoT there is as a whole, the better humanity will fare. IoT is a disaster for security, for the environment, and repairability... I have yet to see a single useful application of IoT which does not bring major downsides.
- nybble41 5y ago
  > Since there's still no mdns (resolution of .local domains) in android nor in chromium despite long standing feature requests… If you run your own DNS resolver for your local network, you can use a Discovery Proxy (RFC 8766) to allow unicast DNS resolution of multicast DNS records. I'm using mdns-discovery-proxy[0] (slightly modified to support a newer version of the zeroconf Python library) with a forward-only zone rule in bind9 so that xyz.local is mirrored in unicast DNS as xyz.home.arpa. The latter address will work for any program on the network regardless of mDNS support. [0] https://github.com/nybble41/mdns-discovery-proxy https://github.com/nybble41/mdns-discovery-proxy
- jabbany 5y ago
  IoT onboarding has always been less than ideal. I've personally never been of fan of the "spray (local) and pray" approach as it always felt _super_ sketchy... (IIRC, Magicjack does something like that to register your device from its public site? At least that's what I think it does since it's somehow magically grabbing a serial number during sign up despite the URL entry point not having any identifying parameters...) Let's just hope this pushes support for better options like mdns further.
jrockway 5y ago
I talked myself out of writing 'GET /quitquitquit' handlers for debugging because of CSRF, but I guess enough people haven't that we have to make browsers just deny access. I think that's probably fine. Is anyone working on making CORS stricter? I have always been annoyed that you can do cross-origin GETs and form submissions without a preflight. Whenever I Google it I just find people talking about how the existing CORS restrictions ruin their lives. Personally, never had a problem, so I'm not sure what all the fuss is about.

267 points by zdw 5y ago

Every day my belief that the web should never have been allowed to go beyond hyperlinked documents grows stronger.

Yes, this potentially increases security, but it further increases Google's control over even my private network? There surely must be a better way.

ep103 5y ago
Firefox
- guywithahat 5y ago
  Yeah but then I have to use firefox, and the way Mozilla's marketing (and user) numbers have been going it feels like a losing battle. I mean not to long ago they put out a paper on why a distributed internet is bad and ways to stop it; the people running Firefox are completely out of touch

bugmen0t 5y ago

Pretty sure you will be able to opt out via group policy. If you control your network so hard that you can accept CSRF, it even makes sense. But would you swear that none of your smart devices are terribly insecure and incapable of even updating at all? You’ll have my utmost admiration if you can.

Macha 5y ago

Hmm, this may break a project I'm working on, depending on how far it goes. It's a web based client to a service that is commonly self hosted. Users enter the URL of their server instance at startup. That server is frequently on the users home network. I have a public instance of the client hosted for a zero install user experience. I think this immediate change would be fine since that public instance is a secure context, but it sounds like the ultimate direction is to prevent web->local access altogether.

afavour 5y ago
I think you should be able to provide CORS headers in the local server and have the functionality still work.
- Macha 5y ago
  I don't control/develop the server application. It lets users configure it and defaults CORS to pretty open access to its API endpoints. That part is fine. It just seems from this thread that the direction is to shut down that access entirely.
  - afavour 5y ago
    I’d ignore this thread and go to the spec. If local servers are emitting CORS headers they’ll work: https://wicg.github.io/private-network-access/#example-opt-in https://wicg.github.io/private-network-access/#example-opt-i...

vadfa 5y ago

Years ago I noticed any webpage could just use an <img> tag to include an image hosted in my LAN. For example, adding such a tag to any website to include a link to the usual gateway ip addresses (192.168.0.1 and so on) will trigger an http authentication dialog for many users. It's the kind of thing that I thought would be impossible because it seems like such a boundary crossing. Glad they are eventually fixing this...

southerntofu 5y ago
That's what we get for enabling 3rd party requests on the web in the first place. Hyperlinks are great but enabling content from/to 3rd parties was definitely a design mistake of the web. Gemini definitely got this right, so when you run a query to a server, there's only 2 parties involve and no external tracker, and no served script to try and undermine your security by scanning your local network. Seriously, if you'd told me in the mid-90s we'd have connected locks and lightbulbs and surfing to a random website could alter physical properties of my surroundings and scan my local network for vulns without my consent, i would probably have given up on IT entirely as humanity's doom.

rusk 5y ago

I initially read “restrict” as “prohibit” and felt my blood rise. No harm I suppose so long as I can still do it in certain specific circumstances.

zoobab 5y ago

Tell me to avoid this browser, and all other browsers based on it.

ur-whale 5y ago

The list of good reasons to switch away from Chrome is getting very long.

tejohnso 5y ago

The chrome developer blog has a good writeup[1] about this. [1]: https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd...

EvanAnderson 5y ago

I'll work around this, when I need to, by picking some backwater public IPv4 space and using that for the subnet where I put my on-prem-hosted servers. (Maybe North Korea's address space...) I get the "public IP" behavior of the browser and, as a bonus, that "real" IP space on the Internet is inaccessible to my end users and servers!

rootusrootus 5y ago
I did something like this, though it wasn't public space exactly. I had to live with a work VPN that routed all traffic for all RFC1918 addresses into the corporate network. Because we had acquired companies over the years with their own RFC1918 choices, and not all was integrated and renumbered. Since I wanted to be able to reach my own home gear at times, I used 192.0.2.0/24 for my network. Not technically RFC1918, but not used in public, either. I still remember the incredulity from one of my friends saying "but, but, you just took someone else's addresses?" and I said "sure, but whose? does it matter?" and then he looked it up on rwhois and started reading the company name... he got as far as 'Internet Corporation for Assigned...' and then he stopped and threw something at me. Ha! There are a number of non-public but not commonly used address spaces out there, I suspect most of them would suffice for getting around Chrome's RFC1918 blocking. Though it's possible they have another heuristic for determine what constitutes a 'private' address that includes space other than the officially recognized RFC1918 subnets.
- rootusrootus 5y ago
  One thing I forgot to mention. Some consumer devices make assumptions about RFC1918 space, and will not operate if they think they're running on a public IP. This is what prompted me to switch back into RFC1918 for my home network (and I had long since left the company with the voracious VPN anyway). YMMV, of course, but it's something to keep in the back of your head if you plan to switch out of RFC1918 for your home network.
  - EvanAnderson 5y ago
    We ran into some of these different behaviors when we hit a Customer who was using the 192.9.0.0/24 network internally. (Then we hit a few more. Several police departments in Western Ohio are using that subnet internally for some reason. Some vendor in common must have come thru and done it.)

thrdbndndn 5y ago

Maybe different scales, but some of the restrictions already happened in M94. I used to use a remotely hosted web GUI to control my local ari2c RPC but since then I have to move it to my local network.

roody15 5y ago

The big players continue to try and push out smaller independent outlets… always under the banner of “security”. There are lots of split horizon setups in small to medium size businesses, schools, colleges etc. Just another attempt to try and push a “cloud” rent model.

dpryden 5y ago

Overall this seems like a very positive change. However, I wonder how it will affect local development of servers that participate in API flows with public-facing systems. As an example: imagine I am developing my application locally, at http://localhost:8080/ http://localhost:8080/ , and this application supports an OpenID Connect identity flow with an identity provider, https://idp.corp.example https://idp.corp.example . Today I can test the login flow by telling the IDP that localhost:8080 is a valid URL to redirect back to, so that I can click a "login" button in my application, log into the real IDP, and get a token posted back to something like http://localhost:8080/idp-callback http://localhost:8080/idp-callback . This makes it easy to develop a system locally that also communicates with various backend microservices which require authentication with a common IDP. I can't imagine that this is a rare scenario: it seems pretty normal to me. But if I understand the proposal, it sounds like the long-term goal is to prevent this kind of environment for local development, and instead force you to either run your dev stack remotely (with a public IP!) or else run your entire IDP stack locally (so that it has a local IP). Neither of those seem like good ideas to me. Of course, the other option would be to modify local dev servers to accept CORS preflight requests and respond correctly, but I'm always slightly uncomfortable adding code into a local dev stack that would be unsafe if enabled in production. At very least it makes it harder to debug when something inevitably goes wrong with this API flow. There are probably ways to solve this by introducing more proxies into a local dev stack, but I worry that these kinds of little papercuts will just make development that much harder for microservices-architecture applications, which are already hard enough to develop and debug as it is.

Sohcahtoa82 5y ago
If you have a domain that you can control the DNS of, you could temporarily stand up an internet-facing server for localhost.yourdomain.com, get a certificate, then change the DNS to localhost.yourdomain.com to 127.0.0.1 (or put it in your HOSTS file), then address it with localhost.yourdomain.com rather than just localhost. But yeah, I think really, browsers should be able to allow self-signed certs for localhost.
- jabbany 5y ago

johnchristopher 5y ago

Chrome is a bit of a PITA for local dev now that it also prevents me from using https://localhost https://localhost with self signed certificates. There are some flags you can toggle in chrome/chromium but I can't figure out which versions still support them.

jaywalk 5y ago
As long as you go through the steps for your OS to properly trust the certificate, Chrome won't block it or even throw up a warning.
- johnchristopher 5y ago
  Ain't got no time for that. In Firefox I just click "accept" for my *.localhost and I am done. It used to be that straight forward in chrome/chromium but now I'd have to meddle with certificate stores, etc.
paulirish 5y ago
The modern guide for this is https://web.dev/how-to-use-local-https/ https://web.dev/how-to-use-local-https/ and the flag you probably want is #allow-insecure-localhost but the guide steers you towards local trusted certs as an improvement over self-signed.
- johnchristopher 5y ago
  Thanks, I'll probably revisit that when I have too many pitfalls with ff+allow self signed.
jabbany 5y ago
If you have a domain already, you can get a certificate for free from Let's Encrypt and just repurpose the certificate. You don't even have to run an out facing HTTP server as they have a DNS-only challenge. I have a similar setup where I have something akin to "my-home.network" and manage a wildcard cert from Let's encrypt through a local cron job. My router intercepts all the DNS requests to the domain and returns local IPs on the local network. Machines that need HTTPS can get a copy of the wildcard key and do something like "hostname.my-home.network" and get HTTP.

lnanek2 5y ago

Would we be nice if they'd fix wifi terms of service pages first before layering on yet another security screen. Every time I go to the gym or mail room it's a five minute battle with Chrome to let me see my apartment complex's terms of use screen so I can access the internet. Our building doesn't get good cellular data service inside. Yes, I'm sure I want to see the terms of use page, Chrome. No, I don't need to be an advanced user to know that. Actually I do since you only let me get redirected to it if I know to type an http site you haven't seen first instead of an https one...

jaywalk 5y ago
http://neverssl.com http://neverssl.com is perfect for that scenario.
Sohcahtoa82 5y ago
Whenever I'm fighting with a WiFi that doesn't properly send me to a capture portal, I open a browser window to http://www.neverssl.com/ http://www.neverssl.com/ . It was specifically created for this purpose.

gwbas1c 5y ago

One thing I don't understand is: What defines "local" or "private?" Is it by IP?

marcosdumay 5y ago
I imagine anything on the loopback or the local scope IPs. I'm curious what it will do with the 10.0.0.0/8 network.
jabbany 5y ago
Yes. It's in the doc: https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/ Of course one obvious workaround is to misconfigure your router to allocate from a non-private but unused/reserved address space. That way your internal network is also on the "outside".

marshray 5y ago

Think of every developer tutorial that shows you how to get started running HTTP on localhost port 8080 (or whatever). Authentication is left as an exercise for later. Every web page you visit can access that site.

egberts1 5y ago

That would completely screw up my Chrome usage as I’ve got some pretty esoteric network setup having dual-homed route table, some private 13-server Root DNSSEC, and no, just no, Chrome. oh wait, I haven’t used Chrome in 2 years. whew. Never mind.

unethical_ban 5y ago

This seems like it would break certain caching solutions.

rocqua 5y ago
Care to elaborate more?
- unethical_ban 5y ago
  Honestly, not much. I was a little buzzed and was throwing out thoughts. I was imagining local caches of assets or large content, like a web proxy.

kazinator 5y ago

The NoScript extension for Firefox has been doing this for years.

southerntofu 5y ago
Best answer so far. There is absolutely 0 legitimate reason (that i can think of anyway) a website should be making requests from your browser to another website without explicit user consent/interaction. Hyperlinks are great, but random javascript crap making request on our behalf is just harming us users.
- kazinator 5y ago
  It doesn't have to be Javascript. I made an application many years ago that used almost zero Javascript. The only piece of JS is an onLoad handler to position a cursor on a particular field when a page loads. The application uses its own web server, so the browser talks to localhost. For licensing, the application sends the user to my domain, whose pages can send the user back to the app on localhost, again with no JS. The NoScript suite detects and blocks that. The simple fact of a remote website serving up a local URL via dynamic HTML is enough.
  - netizen79865243 5y ago
    with "The application uses its own web server, so the browser talks to localhost." you are not actually saying that your application itself contains a webserver, running inside a browser, serving a website running on localhost, are you?
    - kazinator 5y ago
      In this case, the application is a native executable containing a web server. (It runs in the background, controlled by an icon in the desktop notification area, which can also be double-licked to open a browser to the application's URL).

exabrial 5y ago

We run all of our traffic over ipsec to our VPS. It's https anyway, but I don't really care for Google to know how many clients I have behind my network. Everything is in 10.x.x.x space. No, we're not going to do let-everyone-access-everything. We believe in layered security. Locks on the front door, locks to get around the house.

notatoad 5y ago
Seems like as long as everything is in the 10.x.x.x/8 range and a user gets there by typing the IP into their address bar, nothing is going to change for you. This is only about mixing public and private contexts. If you have a link to private IP space on a public website, then you're going to get warnings.
- deleted 5y ago
  [deleted]
- rocqua 5y ago
  I presume DNS names that resolve to 10.x.x.x are also fine to write into your address bar directly? It seems to me the issue with a DNS split-horizon is that google results return DNS names that are in your local intranet, and thus resolve to a local IP, but you clicked on that link from the outside world, and hence chrome would block that.
  - southerntofu 5y ago
    Yes it would be fine. The issue would arise if you connect to a remote service which then instructs your browser to run local queries.
  - notatoad 5y ago
    I think any sort of split-horizon on devices you don't fully control is going to start giving you a lot of problems going forward. For example, any sort of DNS-over-https is going to make split-horizon non existent unless you control the client device. And presumably if you control the client to change the DNS behaviour, you could turn off this new behaviour too. Fwiw, I think this is generally good. Network operators shouldn't be able to arbitrarily intercept traffic on their networks.

tptacek 5y ago

The backstory on this, if you don't follow web security at all, is that building public web pages to trick browsers into talking to private networks (or your loopback interface) is a surprisingly pernicious attack vector. The modern countermeasure for this is to require devices parked on private networks to opt-in to the ability mix public Internet requests with private network accesses, using CORS, which is what this is about. You should probably be mostly thrilled about this development.

api 5y ago
This is why one of my security mantras has become: if it is not secure enough to connect to the open Internet, it is not secure at all. That doesn't necessarily mean you connect it to the open Internet, but it means you don't leave everything inside wide open because "oh there's a firewall." It also means buggy vulnerable IoT (Internet of Targets) stuff has to be dealt with. Firewalls are almost security theater. They're just a basic precautionary thing. Same goes for virtual and zero trust networks. Systems must be secure, period.
cmaggiulli 5y ago
So would this be like creating a public webpage called “help troubleshoot my router”, and having that webpage serve up malicious JavaScript which attempts to attack my routers local web server?
deleted 5y ago
[deleted]
Ajedi32 5y ago
Been following this for a while; I'm really surprised it's taken so long for browsers to begin to address this problem. It's kinda crazy that random websites can just send any HTTP request they want to your private network or local PC with no restrictions; that's a pretty huge attack surface to expose to the public internet. Even this measure by Chrome is extremely limited, as it sounds like they're only blocking insecure (HTTP) sites from making requests to your private network. HTTPS sites are unaffected (for now).
- 5y ago

shadowgovt 5y ago

""" But perhaps the risk of CSRF attacks against insecure devices on private networks or localhost is severe enough to justify such a change. I see only one side of this whole issue, not both of them. """

deleted 5y ago

[deleted]

missblit 5y ago

> While the specification has some suggestions, I'm not sure that it would allow our specific situation even if we could get all of the people with web servers that are possibly affected by this to make changes to them. Wouldn't this be as simple as an `Access-Control-Allow-Origin: *` (plus all the other junk mentioned in the opt-in section[1] of the draft spec). I'm having a hard time of thinking what wouldn't be workable in the author's situation (assuming he gets all the people with webservers to add headers to them). And yes... understanding CORS should absolutely be a requirement for writing local webservers that people can poke from the public internet; being able to stumble your way through writing a CORS policy is basic web security at this point. [1] https://wicg.github.io/private-network-access/#example-opt-in https://wicg.github.io/private-network-access/#example-opt-i...

EvanAnderson 5y ago
The author is in a large University context where getting everybody who runs all the web servers (various departments, schools, etc) to add headers probably is really difficult (especially when you consider potentially closed-source applications or embedded devices that aren't easily updated).
- jabbany 5y ago
  It's not that hard though given we're working with HTTP... Since they control the network (DNS and all) couldn't they just wrap non-compliant devices behind a forwarding proxy that adds those headers? Like rather than resolve to the device, resolve to a proxy that adds those headers.
  - EvanAnderson 5y ago
    No, it's not particularly hard, but it is complicating the plumbing. We have to make the Internet safe for manufacturers of devices who can't be bothered to incorporate a modicum of security in their devices.
    - jabbany 5y ago

PragmaticPulp 5y ago

In case it wasn’t clear: This won’t stop you from going to 192.168.1.1 or otherwise accessing private network resources from Chrome. This is about closing specific public/private boundary security vulnerabilities that you don’t want 99% of the time. The author of this article happens to have a 1% corner case, but the average user generally doesn’t want this.

fanf2 5y ago
I think split-horizon DNS is a bit more than a 1% corner case: it's almost universal in corporate and education contexts.
- phkahler 5y ago
  When I read that all I could think of was routing things through a privacy-invading proxy. Is that what it is?
  - nybble41 5y ago
    There often is such a proxy in these environments but it isn't really related. The scenario here is that you have servers with both internal and external IP addresses, and for whatever reason if someone is connecting from inside the network you want them using the internal IPs and not the external ones. (Simpler routing, different features available to internal clients, etc.) So you set up the DNS servers for your network to serve internal IP addresses for your domains, but anyone outside the network sees the public IPs for those same domains. (That's the "split horizon" part.) Now someone in the network could follow a link from a page served from a public IP to a domain with a private IP address—which this change would disallow unless the first page was served from a "secure context" (with TLS) and the internal server responds to a "preflight" OPTIONS request with the required CORS headers to allow following links from public networks.
    - Anunayj 5y ago
      This is extremely common in Universities where you share 2-4 public IPs that you can usually ask ports to be forwarded to a internal IP, and often there are resources (Like say Servers with GPUs) available on a interally reachable IPs using a easy to use hostname served by the internal DNS server. Ofc this change won't be that big of a issue, things would just need to change a little, using Split-DNS was already a pain when students wanted to say use DNS-over-HTTPS and didn't want the University DNS servers to know every site they visited.

deleted 5y ago

[deleted]

hulitu 5y ago

Why is Google trying to be the smart ass here. Since when network access control and topology is the atribute of a web browser ? What's next ? X server ? OS kernel ?

pjmlp 5y ago
ChromeOS.
adamrezich 5y ago
filesystem? ...oh wait, google drive updated itself without me asking a few weeks ago, even though I haven't used it in ages, and now, randomly, every few days, I get a popup telling me I need to sign back into drive, even though I closed the system tray application. (is being annoying to the user just an inherent property of this kind of service? are they trying to compete with OneDrive for reluctant end-user obnoxiousness??) there's probably half a dozen ways to get rid of it but it's a nice periodic reminder that I really don't care for google anymore
- beebeepka 5y ago
  Not sure why you're being downvoted. I had the exact same experience with Epic's craptastic launcher a few years ago. Behind the scenes update followed by a sneaky autostart entry. I hadn't used it in a while and only discovered what had happened by accident months later
  - afavour 5y ago
    OP is probably being downvoted because the rant is pretty off-topic.
laumars 5y ago
Since network end points have supported HTTP GET requests. If your router or IoT device isn’t secure any webpage online can embed a (for example) <img src=“http://192.168.1.1/enable_remote_access.php”> And it’s not as if consumer routers nor cheap Chinese IoT hardware have a proven track record for security.

deleted 5y ago

[deleted]

nottorp 5y ago

Hmm question: Will this race to secure the internet mostly by applying ever more complex band aids end up in completely discouraging small entities from running their own public resources? It's already next to impossible to run a public home server. Is it likely to become completely impossible?

MonaroVXR 5y ago
>It's already next to impossible to run a public home server. Is it likely to become completely impossible? Why? I try to do this, it's an exercise that I wanted to do.
sergiomattei 5y ago
I’m curious. Are there any new major difficulties when setting up home servers? Last time I tried it was a little annoying with dynamic IPs getting in the way, but possible with just a port forward or UPnP. Are ISPs making changes to prevent this?
- southerntofu 5y ago
  That's about it. In addition, some ISPs make sure you cannot change the resolver advertised on DHCP, and that your own IP is routed via the Internet and back (so local requests are slow as hell), both of which can be hacked around by running your own router behind the ISP's modem/router. Of course, the real solution to the problem is to find a decent ISP, like a non-profit from FFDN.org federation. Then you have "real" internet and no worries for selfhosting.
- nottorp 5y ago
  And how much time/expertise do you need to not trigger all kinds of warnings in modern browsers?
  - space_fountain 5y ago
    Fairly little? I think you might be thinking of email where running your own email sever is tough

PostThisTooFast 5y ago

WTF is that supposed to mean? Another lazy, bullshit HN headline and another shitty article.

zzo38computer 5y ago

Restricting such requests can be a good idea, but it should be user configurable (e.g. in case you want to redirect some requests to your own implementations), and whether or not it is allowed should have nothing to do with whether or not TLS is used (it means HTTP vs HTTPS, but really that is irrelevant to this issue, which is a different issue). Furthermore, if you do not explicitly type a localhost URL or IP address, it should also block access to stuff on localhost or local networks, again it should be user configurable though in case you want to enable specific cases.

mattowen_uk 5y ago
Ok, so I have a dynamic page hosted externally. It's set as my homepage on all my browsers. It's full of links to things I use. Some of those links are on my internal network, and are NOT https (seriously, for small things/apps you don't need it). If I understand this correctly, Chrome will now block me clicking on these links? I'm all for improving browser security, but as an end user, I should have the option to turn settings off that cause me a problem.
- southerntofu 5y ago
  > Some of those links are on my internal network (...) Chrome will now block me clicking on these links? Unless i missed something, you will still be able to click links. Chrome will block the original page from running queries without your consent to your local networks, eg. a javascript bit trying to find a vulnerable router/crapware on your local network.
- zzo38computer 5y ago
  > I'm all for improving browser security, but as an end user, I should have the option to turn settings off that cause me a problem. I agree. I will want to configure a lot of things. However, allowing finer configuration can also be helpful; you might not want to turn off that feature entirely. (For example, maybe if you want to assign that dynamic page to the local zone (if such a thing is possible; the article says something else, though) even if it isn't local, then it will be able to work such links.)

yrro 5y ago

I guess this won't/can't protect web services on private networks that nonetheless.use public routable address space? What about IPv6, both public routable address space and ULA space?

tommiegannert 5y ago
I was also curious about IPv6 non-local scopes. The spec linked in the article says > User Agents MAY allow certain IP address blocks' address space to be overridden through administrator or user configuration. This could prove useful to protect e.g. IPv6 intranets where most IP addresses are considered public per the algorithm above, by instead configuring user agents to treat the intranet as private. https://wicg.github.io/private-network-access/#ip-address-space-heading https://wicg.github.io/private-network-access/#ip-address-sp... So aside from loopback and link-local, the only effect this will have on IPv6 is what the browser decides to do. If that's a manual add/remove or a look into the routing table seems unspecified.
- yrro 5y ago
  Ah, I missed the spec link and landed on the design documentation... So I will have to wait to see what form this configuration takes. Hang on a minute, this is suddenly sounding rather familiar--I'm suddenly reminded of the Internet control panel in Windows, which lets you assign web sites to different zones (internet, LAN, trusted, restricted)...

xg15 5y ago

Linked in the Private Network Access draft is a discussion which outlines some general points about HTTPS on local devices and participation of local devices on the web in general. It's interesting to read, even though the results seem rather bleak. https://github.com/wicg/private-network-access/issues/23 https://github.com/wicg/private-network-access/issues/23

readflaggedcomm 5y ago

Just integrate a basic uMatrix into the browser, as it should have, and none of this matters. Why is it impossible to view the origins of resources in one simple interactive panel? That's simpler than the major browsers' dev tools' features, in fact. Except then, the user would have a dashboard of control, which they can not be trusted with.

southerntofu 5y ago
Shouldn't we redefined WWW specs to prevent 3rd party requests entirely? It would fix this problem and many others.

amenghra 5y ago

I believe this will fix a ~14 year old bug. Browsers have been punting on dns rebinding forever. Initially documented by Collin, here are two threads: Paper: https://crypto.stanford.edu/dns/dns-rebinding.pdf https://crypto.stanford.edu/dns/dns-rebinding.pdf Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=98357 https://bugs.chromium.org/p/chromium/issues/detail?id=98357 Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=689835#c3 https://bugzilla.mozilla.org/show_bug.cgi?id=689835#c3

hoppla 5y ago
Exactly what I think as well. I have not looked into this attack for a while, but have always assumed it still is possible to proxy traffic via a user’s browser

gry_gh 5y ago

Besides NoScript, another webextension addon is doing that: LAN port scan forbidder: https://github.com/garywill/LAN-port-scan-forbidder https://github.com/garywill/LAN-port-scan-forbidder Addon already on Firefox

gxnxcxcx 5y ago
uBO has this filter list available by default: https://github.com/gwarser/filter-lists/blob/master/lan-block.txt https://github.com/gwarser/filter-lists/blob/master/lan-bloc...

jabbany 5y ago

This seems mostly benign, basically changing the default cross-boundary behavior from "allow" to "deny" but also providing a way for intranet devices to exclude themselves. On the other hand I'm also not a huge fan of these measures because they address the issue from the wrong end. Servers should protect themselves from CSRF, it shouldn't be the job of browsers to do that. A server (think router or IoT device) shouldn't be like: Hey I'm getting an internal IP anyways so I'm going to be lax. With this there's now no motivation to fix anything from the server/device side so you have failure modes where someone's using a weird/old browser that doesn't preflight and they're vulnerable but everyone still has a false sense of security... Additionally, I'm worried that rather than adopt the whole preflight/headers thing, a lazy org might decide to just repurpose some reserved public IP space for their internal private addressing so things don't "cross-bounds" anymore...It basically becomes unusable security that's circumvented like writing your password on a sticky because it's forced to be really complex. Never underestimate the ability for someone to blow through any and all security or safety measures if they prevent them from doing something that they could do before...

cygx 5y ago
As far as I'm concerned, this change is long overdue: Browsers should never have granted arbitrary websites the ability to port scan your local machine and network. Note that Opera came with cross network protections a decade ago, cf https://web.archive.org/web/20121001002815/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20121001002815/http://my.opera.c...
- jabbany 5y ago
  Scanning is not allowed anyways just from standard cross-origin protections. If intranet services do not send CORS allow headers, a remote site (which will certainly be from a different origin) cannot get any information as to whether certain ports/addresses have services running just like it should be. It's the same reason you cannot embed an Ajax request in your blog to query someone's bank account's API. In order for information to be made available to the external site, the service has to cooperate with the remote site already. In fact, even CSRF is mostly due to the server misusing HTTP. Look at the example in the W3C doc, where the remote site has a hidden frame/resource that hits local servers. Well guess what, GET requests should not change state, so changing some DNS configuration via a GET request is already doing it wrong. There's no inherent reason an intranet site should be treated any differently from an Internet site. At best the current argument is that "intranet sites are more likely to be hacky and poorly implemented", but that should reflect more on those devices/services on the intranet than anything else.

StingyJelly 5y ago

I feel like this is going to break many IoT devices (definitely my ones) and I wouldn't be surprised if it's a move to push more developers towards integrating with GoogleHomeSpyware™. Since there's still no mdns (resolution of .local domains) in android nor in chromium despite long standing feature requests, workaround I (a hobbyist) and likely other IoT devs chose chose was to host a small website that would brute-force check local ip ranges until the IoT device was found. At least for now I have another reason to transfer hypertext securely but I've honestly no idea for future workaround (other than a large banner saying "install firefox")

southerntofu 5y ago
> I feel like this is going to break many IoT devices (definitely my ones) On one hand i'm sorry for you. On the other hand, the less IoT there is as a whole, the better humanity will fare. IoT is a disaster for security, for the environment, and repairability... I have yet to see a single useful application of IoT which does not bring major downsides.
nybble41 5y ago
> Since there's still no mdns (resolution of .local domains) in android nor in chromium despite long standing feature requests… If you run your own DNS resolver for your local network, you can use a Discovery Proxy (RFC 8766) to allow unicast DNS resolution of multicast DNS records. I'm using mdns-discovery-proxy[0] (slightly modified to support a newer version of the zeroconf Python library) with a forward-only zone rule in bind9 so that xyz.local is mirrored in unicast DNS as xyz.home.arpa. The latter address will work for any program on the network regardless of mDNS support. [0] https://github.com/nybble41/mdns-discovery-proxy https://github.com/nybble41/mdns-discovery-proxy
jabbany 5y ago
IoT onboarding has always been less than ideal. I've personally never been of fan of the "spray (local) and pray" approach as it always felt _super_ sketchy... (IIRC, Magicjack does something like that to register your device from its public site? At least that's what I think it does since it's somehow magically grabbing a serial number during sign up despite the URL entry point not having any identifying parameters...) Let's just hope this pushes support for better options like mdns further.

jrockway 5y ago

I talked myself out of writing 'GET /quitquitquit' handlers for debugging because of CSRF, but I guess enough people haven't that we have to make browsers just deny access. I think that's probably fine. Is anyone working on making CORS stricter? I have always been annoyed that you can do cross-origin GETs and form submissions without a preflight. Whenever I Google it I just find people talking about how the existing CORS restrictions ruin their lives. Personally, never had a problem, so I'm not sure what all the fuss is about.