search

WICG / private-network-access

https://wicg.github.io/private-network-access/
Other
57 stars 22 forks source link

Clarity on private networks #68

Closed BenjamenMeyer closed 2 years ago

BenjamenMeyer commented 2 years ago

How does this effect private networks? Does one need to make policies for their networks and distribute them? Or would this not effect them at all?

I know my personal case is more unique - I run a full network at home using the 192.168.x.y address space, and host my own services. On the face of it, this sounds like it could be a big issue, but reading over it it doesn't seem to be, though it's unclear.

Note: Docker usually uses the 172.16.x.y address space on Linux so most any developer will run into some cross network situations even without VPN involved.

It would be helpful to have a small example of a situation like mine, which wouldn't be that different from most small companies BTW, to bring clarity for end users and network administrators.

HolgerJeromin commented 2 years ago

If the services are running on the same host (192.168.x.y) as the webpage everything is fine. If you access the services from another host (say a page from example.org uses resources from 192.168.x.y) the request will be rejected.

I had the situation with http://example.org fetching http://192.168.0.1 stuff. This is rejected in current chrome based browsers.

Another situation is https://example.org fetching https://192.168.0.1 stuff. This is working right now in current browsers (you need to handle tls certificates). https://192.168.0.1 fetching https://192.168.0.1 stuff should be always working. http://192.168.0.1 fetching http://192.168.0.1 stuff should be always working but with more and more ugly address bars due to missing encryption.

letitz commented 2 years ago

@HolgerJeromin is right.

The only requests that are affected are those going from a public IP to a private IP or localhost, and those going from a private IP to localhost.

See the definition of a private network request in the spec.

BenjamenMeyer commented 2 years ago

@HolgerJeromin @letitz that's what I thought; it would just be good to make that more clear in the documents themselves.

@letitz your statement would be a good addition to the documentation:

The only requests that are affected are those going from a public IP to a private IP or localhost, and those going from a private IP to localhost.

BenjamenMeyer commented 2 years ago

I will ask one other question: how would this effect one type of private network to another type of private network - e.g 192.168.0.0/16 with 192.168.2.x and 192.168.3.x or 192.168.0.0/16 vs 10.0.0.0/24 vs 172.16.0.0/16? They are distinct networks and the issue this attempts to address would still be at play. Should implementations consider them all the same or separately?

letitz commented 2 years ago

This specification does not affects such requests yet. See #39 which leaves the door open to some changes there in the future.