I am thinking of use cases and I think one would be folding@home. Their Web client is hosted on their public website and it makes http calls to a localhost:port running on a background service. Is that correct or have I misunderstood?
The core assertion behind this proposal is that devices and services running on a local network can continue making themselves available to external networks if and only if they can update themselves to make that desired relationship explicit. If they can't update themselves, they also can't fix security bugs, and really must not be exposed to the web.
The example feedback goes a bit in that direction, but how would that interact with mixed content?
Say, I have a server running on 192.168.1.1. The box is only accessible through its IP address, so I can't get a public certificate for it and therefore can't enable https.
I cannot access the box from a http site due to the new restriction.
I cannot access the box from a https site due to mixed content.
My understanding is that you can access it directly. But you can't embed e.g. images or JavaScript from that server within a website running on a public IP address. I consider that a good thing.
You cannot make an AJAX call from an HTTPS site to a HTTP site on a local IP address.
One of the internal web applications I develop (which is hosted over HTTPS itself) has to workaround this by doing the connection from the browser to the local IP address over HTTPS, but upon detecting HTTPS cert errors it opens a popup and walks the user through the process of adding an exception to connect anyways. Once that popup closes, then the AJAX request gets retried and succeeds.
While this works for an internal application, it would be unacceptable for any consumer product.
Agreed - this HTTPS everywhere madness needs to stop as there are still valid use-cases for HTTP and no user-friendly workaround for enabling access to local IP addresses via HTTPS.
Correct. In the status quo, you will be best-served by looking at solutions similar to what Plex is shipping (https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...). ACME's DNS-based challenges might even make this easier today than it was when that mechanism was designed.
Longer-term, it seems clear that it would be valuable to come up with ways in which we can teach browsers how to trust devices on a local network. Thus far, this hasn't been a heavy area of investment. I can imagine it becoming more important if we're able to ship restrictions like the ones described here, as they do make the capability to authenticate and encrypt communication channels to local devices more important.
Fuck this. It increases the complexity of browsers and servers and erects yet another burden for makers. And for what? So orgs with broken infrastructure (and budgets for running it) and device manufacturers (with budgets of their own) can keep up their garbage practices instead of fixing them? And they can push their costs onto a deep-pocketed company like Google who's willing to subsidize them? Here's to hoping that WebKit and Mozilla say "No."
It's probably wrong to consider any 'private' network to be secure any more. With zero-trust principles in mind, you wouldn't necessarily believe every device or system on your network is trusted, so you ensure that what is able to send and receive traffic on your network has other mechanisms in place for trust and authenticity.
I mean, you have to hand it to them that the point of this change is to strengthen the security of "everything in LAN is trusted" networks: Using the browser as a gateway to access internal services is one of the most important ways to break into local networks.
Huh? I think you may have a very incorrect idea about who is being burdened here.
A major effect of these changes is to make it simpler for anyone ("makers" included) to securely implement devices which expose web services, by making web browsers refuse to allow external web sites to send arbitrary requests to those devices.
Most network devices have no need to receive such requests. No action is necessary on their part; these changes will make those devices stop receiving those requests.
The few network devices that do need to receive those requests can opt in to receiving them by responding to a CORS probe (an OPTIONS HTTP request) with a specific HTTP header. This is not complicated to implement.
Web browsers already implement complex CORS policies. Adding this is not a huge burden upon them, and may actually obviate the need for other more complex defenses.
The whole DNS rebinding thing makes this very complicated to implement correctly in browsers. (I.e. the public/private status of a domain name can change in time under attacker control)
> I think you may have a very incorrect idea about who is being burdened here
Convenient stance, but no. It's possible to have a decent grasp on the proposal (thanks) and to mean what was written in the comment you're responding to above.
Your response belongs to a class of responses that can be called "well, you can just…" responses. The problem with these is that they tend to diminish what the just part is out of some lack of awareness and failure to truly take stock. (HN's infamous Dropbox comment can be considered an instance of a "well, you can just…" response.) And in your case, apparent unawareness that the response can be just as easily applied in the opposite direction—orgs with staff setting up insecure private networks can just do things the right way; device manufacturers who have software engineers but cheap out and take shortcuts can just stop doing that and commence with doing the thing they're getting paid for. And it turns out those justs make a lot more sense than the one that says ordinary people should deal with an even more complicated and hostile landscape that raises the barrier to entry for pulling off small accomplishments _without_ funding—just because some folks wanted to be able to offload their job duties.
And there was no suggestion that implementing this is a "huge burden" for _existing_ browser vendors. The fact that you seque there from a point about how browsers "already implement complex CORS policies" shows your failure to grasp the point that was being made.
I don't get it. What's wrong with normal CORS? They do work for private networks. Also I don't think browsers are the right place to do this kind of protection.
> status quo CORS protections don’t protect against the kinds of attacks discussed here as they rely only on CORS-safelisted methods and CORS-safelisted request-headers. No preflight is triggered, and the attacker doesn’t actually care about reading the response, as the request itself is the CSRF attack.
But what about those vulnerabilities is specific to being on a private network? If we can find a public website with the same vulnerability, will we start enforcing stricter CORS requirements everywhere?
Ok, this will protect old unpatched vulnerable devices. But what will prevent a negligent manufacturer that uses HTTP GET without CSFR protection to apply configuration to the device from just adding the CORS opt-in header everywhere? I mean it would be the simplest solution for them.
Requiring HTTPS for services on the private network seems rather extreme. How do you even do HTTPS on a private network not attached to some publicly-resolvable external domain without installing the root certificate on all devices?
Zero-trust architecture would note that there's not really anything 'private', once the traffic is 'inside'. The old way of thinking with firewalls and DMZs falls apart now, so you have to treat all traffic, even what you think of as "inside" as potentially hostile or disruptive. Thus, TLS everywhere.
How to do it? self-signed certs and distribute your own CA and install it across devices that are authorized to be on your network.
This is not a proposal for users, it's a tool for network administrators and programmers. "Yeah but I have a home LAN, too" isn't relevant here, unless your home network has high-value targets on it and all the other technologies this applies to, in which case maybe you're not in "the vast majority of users".
If you are running a private intranet type thing, installing your own root certs seems fairly reasonable to me.
You could also just have the dns be public. No reason why private networks can't be in public dns. If you are really paranoid use wildcard certs, and only have top domain be in the public dns.
The certificate transparency log for an internal network would let you see which domains are in use and make it far easier for an attacker to exploit internal services. The attacker need not be an APT for this, it could be as mundane as a XSS attack.
How the heck would I go about installing my own root cert into my TV? My fridge? (I'm picking devices here that could actually run browsers.)
How the heck would I have my DNS be public, if I don't have a domain? Getting one means a cost (some amount for the registration, plus whatever you consider costs to avoid your information in the registry getting leaked)
For large corporations, yes it totally makes sense to have your infrastructure be using proper domains and things. For your neighbor's network behind his router… not so much. Nothing that requires TLS does.
In the context of this proposal, i'm not sure why your routers and stuff would need one, it seems like only corporate stuff would be affected.
That said, for a router, it would be vendors responsibility to set this all up. It seems possible but annoying to do this in a secure but privacy preserving way.
I just read the proposal. I do not see where it says that internal services will require https.
My reading is that public websites making an ajax request to http://10.0.0.12 will need to be https. I'm not sure how that protects against anything, but it also doesn't affect the internal services themselves.
"Local", in this context, means localhost (i.e. the machine that the web browser is running on). It does not mean other machines on the private network.
Generally speaking, this simply enforces that, if you are running a web server on your local machine, external web sites (either on your private network or on the Internet at large) cannot trigger requests to that web server.
Yes, but that would mean that a web page served from 192.168.1.1 wouldn't be able to talk with a deamon on localhost if I understand that correctly - unless the private site speaks https, has a domain on the public DNS with a valid cert, etc etc.
Correct. But that's a really weird use case, and one which deserves some attention to security. The local network can contain untrusted devices (or devices which can be subverted into behaving in untrustworthy ways), after all; it's no more appropriate to allow one of them to access a daemon running on localhost than it would be to allow an arbitrary web site to do so.
I still have to consciously open the devices' web page in my browser. Why is it fine for a random web page served from the other side of the world to make that connection but not for a web page served from a device sitting next to me?
Just because your domain is public doesn't mean your DNS is public as well. You can use a cert signed by a public CA in a private network just fine so long as you're using the right DNS setup.
Except that a lot of places have .local (which is terrible, I know, but still lots of places have it), or .lan. A public CA won't create certs for those.
The proposal does not attempt to force private network resources to use TLS. That would be an excellent outcome, but it's difficult to do in the status quo, and is a separate problem to address separately.
The proposal _does_ require pages that wish to request resources across a network boundary to be delivered securely, which therefore requires resources that wish to be accessible across network boundaries to be served securely (as they'd otherwise be blocked as mixed content). This places the burden upon those resources which wish to be included externally, which seems like the right place for it to land.
Assuming I'm running malware.com, I would make 192-168-0-1.router.malware.com resolve to 192.168.0.1 so the origin matches and I can prod the router as much as I'd like without crossing the origin.
The proposal talks about sites resolving to private/local addresses, so presumably, the browser would still apply the checks to all requests to that domain.
The only thing that would not trigger CORS is if you somehow loaded a top-level document from that domain. (The address is in the browser's address bar) - however, a malicious website can't do that as this server is not under their control.
Also I don't understand how this works with IPv6 initiative that wants every device have a public IP address. The same goes for IPv4 routers - on many of them you could use the public IP to do the drive-by attack.
IPv6 does indeed complicate things. I suspect we'll end up trying a few things before finding the right answer, starting with a) allowing network admins to configure IP ranges that correspond to the network they control, and b) examining the local network to infer a private range.
Happily(?), IPv4 networks are still pervasive, and this proposal seems clearly valuable in those environments.
I can't fathom why anyone would be up in arms against preventing random websites from accessing servers running on localhost or inside home networks. This is not about "web bloat," as some people are suggesting, but rather closing a gaping security hole that should never have existed from the start.
This change can't come soon enough. My only objection is that the rollout is way too slow, and the first step is only a baby step. What we have now is essential a 0day situation.
Unfortunately a lot of commenters completely misunderstand the proposal, as well as the attacks it is designed to mitigate. Here's a good paper describing the issue, "Attacking the internal network from the public Internet using a browser as a proxy":
https://www.forcepoint.com/sites/default/files/resources/fil...
The "HTTPS" part of Google's proposal is a bit of a red herring, as I said, only a baby step. It does not mean that your local services have to be https. It just means that public http sites can't make requests to local IP addresses.
> The "HTTPS" part of Google's proposal is a bit of a red herring, as I said, only a baby step.
It's in there for the same reason that risky APIs like geolocation require HTTPS -- so that injecting content into an insecure HTTP transaction cannot allow an attacker to hijack a trusted HTTP site's permissions.
53 comments
[ 3.5 ms ] story [ 94.8 ms ] threadSay, I have a server running on 192.168.1.1. The box is only accessible through its IP address, so I can't get a public certificate for it and therefore can't enable https.
I cannot access the box from a http site due to the new restriction.
I cannot access the box from a https site due to mixed content.
So I cannot access the box anymore at all?
My understanding is that you can access it directly. But you can't embed e.g. images or JavaScript from that server within a website running on a public IP address. I consider that a good thing.
One of the internal web applications I develop (which is hosted over HTTPS itself) has to workaround this by doing the connection from the browser to the local IP address over HTTPS, but upon detecting HTTPS cert errors it opens a popup and walks the user through the process of adding an exception to connect anyways. Once that popup closes, then the AJAX request gets retried and succeeds.
While this works for an internal application, it would be unacceptable for any consumer product.
This was sort of my point - because with the new rules in place, I cannot make an AJAX call from a HTTP site to an internal address either.
If you need passive mixed content, I believe it is and will remain supported by browsers for some time.
If you need active mixed content though you probably will need a workaround via passive content instead.
Longer-term, it seems clear that it would be valuable to come up with ways in which we can teach browsers how to trust devices on a local network. Thus far, this hasn't been a heavy area of investment. I can imagine it becoming more important if we're able to ship restrictions like the ones described here, as they do make the capability to authenticate and encrypt communication channels to local devices more important.
A major effect of these changes is to make it simpler for anyone ("makers" included) to securely implement devices which expose web services, by making web browsers refuse to allow external web sites to send arbitrary requests to those devices.
Most network devices have no need to receive such requests. No action is necessary on their part; these changes will make those devices stop receiving those requests.
The few network devices that do need to receive those requests can opt in to receiving them by responding to a CORS probe (an OPTIONS HTTP request) with a specific HTTP header. This is not complicated to implement.
Web browsers already implement complex CORS policies. Adding this is not a huge burden upon them, and may actually obviate the need for other more complex defenses.
Convenient stance, but no. It's possible to have a decent grasp on the proposal (thanks) and to mean what was written in the comment you're responding to above.
Your response belongs to a class of responses that can be called "well, you can just…" responses. The problem with these is that they tend to diminish what the just part is out of some lack of awareness and failure to truly take stock. (HN's infamous Dropbox comment can be considered an instance of a "well, you can just…" response.) And in your case, apparent unawareness that the response can be just as easily applied in the opposite direction—orgs with staff setting up insecure private networks can just do things the right way; device manufacturers who have software engineers but cheap out and take shortcuts can just stop doing that and commence with doing the thing they're getting paid for. And it turns out those justs make a lot more sense than the one that says ordinary people should deal with an even more complicated and hostile landscape that raises the barrier to entry for pulling off small accomplishments _without_ funding—just because some folks wanted to be able to offload their job duties.
And there was no suggestion that implementing this is a "huge burden" for _existing_ browser vendors. The fact that you seque there from a point about how browsers "already implement complex CORS policies" shows your failure to grasp the point that was being made.
> status quo CORS protections don’t protect against the kinds of attacks discussed here as they rely only on CORS-safelisted methods and CORS-safelisted request-headers. No preflight is triggered, and the attacker doesn’t actually care about reading the response, as the request itself is the CSRF attack.
How to do it? self-signed certs and distribute your own CA and install it across devices that are authorized to be on your network.
This is an unreasonable ask for the vast majority of users.
You could also just have the dns be public. No reason why private networks can't be in public dns. If you are really paranoid use wildcard certs, and only have top domain be in the public dns.
That said, regardless of what one does, i wouldn't reccomend putting too much faith in security by obscurity.
How the heck would I have my DNS be public, if I don't have a domain? Getting one means a cost (some amount for the registration, plus whatever you consider costs to avoid your information in the registry getting leaked)
For large corporations, yes it totally makes sense to have your infrastructure be using proper domains and things. For your neighbor's network behind his router… not so much. Nothing that requires TLS does.
That said, for a router, it would be vendors responsibility to set this all up. It seems possible but annoying to do this in a secure but privacy preserving way.
My reading is that public websites making an ajax request to http://10.0.0.12 will need to be https. I'm not sure how that protects against anything, but it also doesn't affect the internal services themselves.
> Requests from a private network to a local network
https://web.dev/cors-rfc1918-feedback/#what-kinds-of-request...
Generally speaking, this simply enforces that, if you are running a web server on your local machine, external web sites (either on your private network or on the Internet at large) cannot trigger requests to that web server.
There's nothing preventing you from creating another DNS zone.
My understanding of it is the site making the call to the resource on the 'private' network, must be served via HTTPS.
The proposal _does_ require pages that wish to request resources across a network boundary to be delivered securely, which therefore requires resources that wish to be accessible across network boundaries to be served securely (as they'd otherwise be blocked as mixed content). This places the burden upon those resources which wish to be included externally, which seems like the right place for it to land.
I guess this still wouldn't protect against attacks on non http(s) services. So things like https://samy.pl/slipstream/ still work?
The only thing that would not trigger CORS is if you somehow loaded a top-level document from that domain. (The address is in the browser's address bar) - however, a malicious website can't do that as this server is not under their control.
Does the proposal also apply to private-to-private?
E.g., if a page at 192.168.1.1 fetches a resource from 192.168.1.2, will that also trigger the new rules?
Happily(?), IPv4 networks are still pervasive, and this proposal seems clearly valuable in those environments.
Unfortunately a lot of commenters completely misunderstand the proposal, as well as the attacks it is designed to mitigate. Here's a good paper describing the issue, "Attacking the internal network from the public Internet using a browser as a proxy": https://www.forcepoint.com/sites/default/files/resources/fil...
The "HTTPS" part of Google's proposal is a bit of a red herring, as I said, only a baby step. It does not mean that your local services have to be https. It just means that public http sites can't make requests to local IP addresses.
It's in there for the same reason that risky APIs like geolocation require HTTPS -- so that injecting content into an insecure HTTP transaction cannot allow an attacker to hijack a trusted HTTP site's permissions.
https://nullsweep.com/why-is-this-website-port-scanning-me/