Private Network Access (aka CORS-RFC1918)

[letitz]

Hi there friendly TAG members,

I'm requesting a TAG review of CORS-RFC1918.

CORS-RFC1918 is a web specification which aims to protect websites accessed over the private network (either on localhost or a private IP address) from malicious cross-origin requests.

• Explainer: https://github.com/WICG/cors-rfc1918/blob/master/explainer.md
• Security and Privacy self-review: https://github.com/WICG/cors-rfc1918/blob/master/security_privacy_self_review.md
• GitHub repo: https://github.com/WICG/cors-rfc1918/
• Primary contacts (and their relationship to the specification):
  • Titouan Rigoudy (@letitz), Google, specifier / implementer
  • Mike West (@mikewest), Google, original specifier / implementer
• Organization driving the design: Google
• External status/issue trackers for this feature:
  • https://chromestatus.com/feature/5436853517811712 for the secure context restriction
  • https://chromestatus.com/feature/5733828735795200 for the whole shebang

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG, I think?
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/WICG/cors-rfc1918/issues/
• Major unresolved issues with or opposition to this design: none
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[torgo]

Hi @mikewest - just picking this up at our "f2f" this week. Has there been any update since the request came through? In particular is there any further info on multi-stakeholder / multi-impleneter feedback?

[plinss]

We discussed this a bit in our VF2F today, and had some concerns about IPv6 addresses. Looking though the repo there seem to be several existing issues already covering our concerns. Linking for visibility/tracking:
WICG/private-network-access#6
WICG/private-network-access#28
WICG/private-network-access#36

[mikewest]

Hey @torgo! @letitz is driving this inside Chromium. I'm just pointy-haired overhead at this point.

We have weak signals of interest from both WebKittens (https://bugs.webkit.org/show_bug.cgi?id=218623#c36) and Mozillians (mozilla/standards-positions#143 and https://bugzilla.mozilla.org/show_bug.cgi?id=1481298), but nothing that rises to the level of "support" from the Blink process's perspective.

Still, this feels to me like an important problem, and one that hasn't generated any other proposals in the very-long-time-indeed since we originally wrote it. It's something Chromium is actively working towards (we aim to deprecate non-secure local network access in ~three milestones), and if there's a better direction, it would be excellent to discover it quickly. :)

[letitz]

Hi @plinss, thanks for taking a look!

I believe IPv6-related discussions in the issues you link have been resolved, largely thanks to WICG/private-network-access#30. I've updated the issues you linked in the repo to better reflect the current state of affairs.

Do you have other concerns you would like to discuss?

[torgo]

Bringing this to the attention of @wseltzer, @martinthomson as this could use some scrutiny with regard to W3C / IETF liaison…

[torgo]

Hi @letitz We have reopened and are taking a look. Could you give a little more detail on what's changed e.g. in the Fetch integration section? That would help us re-review. Thanks!

[letitz]

Hi @torgo! Sorry for the late response, I was in and out of the office for a bit and dropped this.

A bunch of things have changed - all in all I'd say at least half of the spec was rewritten. More specifically:

The Fetch integration has been re-written to refer to the latest Fetch spec version (as opposed to a years-old version). It is much closer to a real patch, with concrete definitions, less handwavy overall.

The IP address space classification has been re-worked to be simpler and drop the dependency on the IANA special address registry, per suggestions by network experts / the IETF.

The secure context restriction is now specified separately from the CORS preflights, allowing a more straightforward mapping of Chromium changes to parts of the spec (I'm trying to ship the secure context restriction for subresources).

The HTML integration section has been dramatically simplified by relying on the policy container work by @antosart to implement inheritance correctly.

Finally, discussions of both proxy and cache handling have been significantly expanded to explain the risks and tradeoffs involved.

HTH!

[torgo]

Hi @letitz - we're picking this up today and thanks for the info on what to look for.

[ylafon]

We discussed this again in our Virtual F2F, and had questions about legacy devices.
As one goal is to ensure that you don't attack devices, legacy devices that can't be updated comes to mind, link printers.
Most of those devices are usually advertised on the local network, so the UA might be able to figure them out and allowing access like a "paired" device (to avoid completely blocking them out).

Another issue is, should the local network be only the ip/netmask range and not the list of all the private ranges?

[letitz]

We discussed this again in our Virtual F2F, and had questions about legacy devices.
As one goal is to ensure that you don't attack devices, legacy devices that can't be updated comes to mind, link printers.
Most of those devices are usually advertised on the local network, so the UA might be able to figure them out and allowing access like a "paired" device (to avoid completely blocking them out).

The goal is not to block any and all accesses to local network devices, but rather to prevent CSRF attacks on them. As such, only requests initiated by more-public websites will be subject to new restrictions.

If such a device offers its own UI on http://printer.local, and the user navigates there by typing it in the URL bar, then no restrictions are applied and things will work as before.

As for pairing, that's an interesting question. Without using HTTPS to cryptographically authenticate the target device, granting access permissions seems to open the door to confused deputy issues. Are you suggesting "pairing" ceremonies between origins and devices advertising themselves using mDNS?

Another issue is, should the local network be only the ip/netmask range and not the list of all the private ranges?

Currently, all IP ranges specified in RFC 1918 are considered private, as well as a few others. See this algorithm in the spec. An earlier version of this spec proposed to rely on the IANA special-purpose address to define address spaces, but that was discouraged by network experts upon consultation: see WICG/private-network-access#50.

Edit: Oh, I think I misunderstood your point. You mean to suggest that only the current subnet be considered private? That makes some sense in terms of protecting the devices around the user. I stand by the belief that considering all private ranges as private makes more sense, because a public website initiating a request to 10.0.0.1 would usually not be able to reach the same host using that address. In other words, as the spec currently states: "[the private address space] contains addresses that have meaning only within the current network. In other words, addresses whose target differs based on network position."

[ylafon]

Hi @letitz

Yes, it is quite clear that the goal is to prevent CSRF attacks, but for example, being able to access a device on your local network from outside has its value, be it a printer, a music player or a cloud-based configuration manager for some of your local devices. In the first case, you can't really expect to upgrade the firmware on your printer, while on the second case it is trivial to do so to support a more secure way of allowing this kind of interaction.

This is the reason why it would be good for some services to see them not as services, but as attached pseudo-devices (the printer case).

On the second point, I think there is a difference between the local network and the private networks you can reach, like corporate private networks. The pseudo-device use case makes sense only for local networks, not for corporate private networks, for example.

[letitz]

This is the reason why it would be good for some services to see them not as services, but as attached pseudo-devices (the printer case).

Making sure I understand your concern correctly:

1. Certain devices will not be able to update and support CORS preflights, for example old printers
2. There should be a way for websites to request access to such devices that bypasses PNA restrictions

If I've understood correctly, then I can certainly see your point. I have two reservations, however:

1. This mechanism would significantly reduce the incentive for devices to implement PNA proper. In other words, it seems advantageous for device maintainers (and disadvantageous for user security) to classify all services as pseudo-devices.
2. It begs the question: how do you identify a pseudo-device? IP address alone works to an extent, but is hardly fool-proof. mDNS names are not authenticated either, though one could argue that on the private network they should be relatively stable.

On the second point, I think there is a difference between the local network and the private networks you can reach, like corporate private networks. The pseudo-device use case makes sense only for local networks, not for corporate private networks, for example.

Oh, so you propose allowing the pseudo-device attachment only work within the currently subnet(s)?

[ylafon]

Making sure I understand your concern correctly:

1. Certain devices will not be able to update and support CORS preflights, for example old printers
2. There should be a way for websites to request access to such devices that bypasses PNA restrictions

Well, not really bypass restrictions, as the goal would not to let them be available through http, but as an attached device.

If I've understood correctly, then I can certainly see your point. I have two reservations, however:

1. This mechanism would significantly reduce the incentive for devices to implement PNA proper. In other words, it seems advantageous for device maintainers (and disadvantageous for user security) to classify all services as pseudo-devices.

I don't think so, as not all services can be seen as a pseudo device, router configuration is definitely not in that range. I think more about devices sitting on the local network where the function can be identified easily.

2. It begs the question: how do you identify a pseudo-device? IP address alone works to an extent, but is hardly fool-proof. mDNS names are not authenticated either, though one could argue that on the private network they should be relatively stable.

mDNS is probably the most reliable way to identify an ipp or roap device, for example, but it is just a possibility.

On the second point, I think there is a difference between the local network and the private networks you can reach, like corporate private networks. The pseudo-device use case makes sense only for local networks, not for corporate private networks, for example.

Oh, so you propose allowing the pseudo-device attachment only work within the currently subnet(s)?

Yes, on remote private network, you can imagine that gateways to implement PNA would be in place to access devices that can't be directly upgraded.

[letitz]

Making sure I understand your concern correctly:

1. Certain devices will not be able to update and support CORS preflights, for example old printers
2. There should be a way for websites to request access to such devices that bypasses PNA restrictions

Well, not really bypass restrictions, as the goal would not to let them be available through http, but as an attached device.

Do you propose to introduce a new API for loading websites that does not use http, then? Or a new scheme perhaps? Though that would not prevent CSRF, so I think I am missing your point. Could you explain how you envision a user agent would interact with a pseudo-device?

If I've understood correctly, then I can certainly see your point. I have two reservations, however:

1. This mechanism would significantly reduce the incentive for devices to implement PNA proper. In other words, it seems advantageous for device maintainers (and disadvantageous for user security) to classify all services as pseudo-devices.

I don't think so, as not all services can be seen as a pseudo device, router configuration is definitely not in that range. I think more about devices sitting on the local network where the function can be identified easily.

Who makes that call, and how is it made? I think this is a crucial question with such an approach.

Either the user agent has some list of acceptable pseudo-devices, or the target service must be trusted to self-identify, in which case we are back to solution relatively similar to the current proposal.

In the former case, it seems that the only recourse we have is to ask either the host OS or the user for help determining what are acceptable pseudo-devices to communicate with. I have shied away from asking users for input on the theory that most will be unable to make an educated decision on the risks involved with allowing a random website to probe at a private network device. As a defense-in-depth measure, I am not opposed to it. However, I believe relying on user consent alone would significantly weaken the protections afforded by the preflight protocol envisioned in the current spec.

2. It begs the question: how do you identify a pseudo-device? IP address alone works to an extent, but is hardly fool-proof. mDNS names are not authenticated either, though one could argue that on the private network they should be relatively stable.

mDNS is probably the most reliable way to identify an ipp or roap device, for example, but it is just a possibility.

On the second point, I think there is a difference between the local network and the private networks you can reach, like corporate private networks. The pseudo-device use case makes sense only for local networks, not for corporate private networks, for example.

Oh, so you propose allowing the pseudo-device attachment only work within the currently subnet(s)?

Yes, on remote private network, you can imagine that gateways to implement PNA would be in place to access devices that can't be directly upgraded.

That makes sense.

[ylafon]

Making sure I understand your concern correctly:

1. Certain devices will not be able to update and support CORS preflights, for example old printers
2. There should be a way for websites to request access to such devices that bypasses PNA restrictions

Well, not really bypass restrictions, as the goal would not to let them be available through http, but as an attached device.

Do you propose to introduce a new API for loading websites that does not use http, then? Or a new scheme perhaps? Though that would not prevent CSRF, so I think I am missing your point. Could you explain how you envision a user agent would interact with a pseudo-device?

Not really, my point was to make it seen (if allowed) as a peripheral directly attached to the computer, with the browser deciding which device can be seen or not. That would solve the use case of legacy devices like printers, scanners, cameras, etc... But how it can be done, or even would it be the best solution for enabling those legacy devices is out of scope of this review.

If I've understood correctly, then I can certainly see your point. I have two reservations, however:

1. This mechanism would significantly reduce the incentive for devices to implement PNA proper. In other words, it seems advantageous for device maintainers (and disadvantageous for user security) to classify all services as pseudo-devices.

I don't think so, as not all services can be seen as a pseudo device, router configuration is definitely not in that range. I think more about devices sitting on the local network where the function can be identified easily.

Who makes that call, and how is it made? I think this is a crucial question with such an approach.

Either the user agent has some list of acceptable pseudo-devices, or the target service must be trusted to self-identify, in which case we are back to solution relatively similar to the current proposal.

In the former case, it seems that the only recourse we have is to ask either the host OS or the user for help determining what are acceptable pseudo-devices to communicate with. I have shied away from asking users for input on the theory that most will be unable to make an educated decision on the risks involved with allowing a random website to probe at a private network device. As a defense-in-depth measure, I am not opposed to it. However, I believe relying on user consent alone would significantly weaken the protections afforded by the preflight protocol envisioned in the current spec.

Decisions in that case shouldn't be on the user, to avoid permission fatigue.

2. It begs the question: how do you identify a pseudo-device? IP address alone works to an extent, but is hardly fool-proof. mDNS names are not authenticated either, though one could argue that on the private network they should be relatively stable.

mDNS is probably the most reliable way to identify an ipp or roap device, for example, but it is just a possibility.

On the second point, I think there is a difference between the local network and the private networks you can reach, like corporate private networks. The pseudo-device use case makes sense only for local networks, not for corporate private networks, for example.

Oh, so you propose allowing the pseudo-device attachment only work within the currently subnet(s)?

Yes, on remote private network, you can imagine that gateways to implement PNA would be in place to access devices that can't be directly upgraded.

That makes sense.

We discussed this again during our F2F, and decided that it looks good enough to close it.
Thanks!

[johnathan79717]

FYI that we're planning to allow same-origin fetches to potentially-trustworthy origins WICG/private-network-access#89