Address class categories - overlap / intersection for "local" and "private"

[mhardeman]

I’m interested in the policy behavior differences in fetch requests / resource loads / etc of targets which are regarded “local” versus “private”.

If the two deserve distinct handling, it may be noteworthy to consider that especially in the IPv4 case, the “private” address of an interface on the local host is highly predictable (in most cases, the address will be one of less than 500 numbers, vast majority of cases far fewer candidates than that).

Combined with the fact that on virtually every platform, a naive listening daemon might bind 0.0.0.0:port_number_whatever, the host machine’s private IP endpoint for those binds is effectively local traffic. I wonder if the model and or definitions in section 2 need to consider that possibility that some “private” addresses are actually ALSO “local” addresses?

I would submit that any unicast IPv4 or IPv6 address which is an IP endpoint terminating on the host is arguably both a private IP address and a local IP address. Perhaps the policy applied when attempting to access these resources should be the most restrictive of either interpretation?

[letitz]

Interesting point. I don't see however how a browser would detect that a private IP actually mapped back to the current host?

[mhardeman]

The browser is native software running upon the OS stack. It can certainly enumerate the addresses bound to its various physical or virtual interfaces.

…

On Nov 10, 2020, at 10:05 AM, Titouan Rigoudy ***@***.***> wrote: Interesting point. I don't see however how a browser would detect that a private IP actually mapped back to the current host? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3IV4T6DD5ETL6CSO5DWGDSPFQEXANCNFSM4EK3OWQA>.

[letitz]

Ah, I see. I wonder if there are strange cases in which an interface is bound to IP X, but sending a packet to IP X does not result in it looping back because of network misconfiguration.

Such misconfigurations could cause intranet websites to be incorrectly categorized as local. This might fail some requests that should otherwise have succeeded, and that's fine. It might also let such intranet websites access localhost, which is more of a problem. We could introduce a distinction between these cases: use the more private interpretation for fetch targets, and the less private interpretation for fetch clients.

This seems like it's complicating things for not a ton of benefit? Protecting badly-configured local services against malicious IoT devices, maybe? As Anne pointed out, this resonates with issue #15.

[letitz]

Thinking about this some more, I do not think fixing the vulnerability of badly-configured daemons should be in scope (yet).

If a server is bound to the host's private IP as well as localhost, then it is accessible to other members of the private network. Making it accessible from websites served from the private network thus seems reasonable: after all, chances are that the host serving the website could just poke at the vulnerable server directly instead of relying on a browser to mediate the interaction.

In other words, we want to protect users against a kind of network privilege escalation, whereby websites gain access to network endpoints that they otherwise could not reach via the browser. In this case, there is no escalation.

Now, once we launch Private Network Access fully, then we will want to consider blocking all cross-origin requests destined to non-public addresses (see #1). In other words, prevent the smart fridge from talking to the router through the user's browser. That would address this concern.

[letitz]

Loosely related: #44.

Given the absence of activity here, I will follow the logic laid out in the previous comment and subsume this issue into #39.