Feedback wanted: CORS for private networks (RFC1918) • Hacker News Board

Re: Feedback wanted: CORS for private networks (RFC1918)

#51

Post by _qulr » Wed, Nov 11, 2020, 6:51 PM UTC

duskwuff wrote: post #50

_qulr wrote: post #40

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…

> 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.

Sure. But we've seen cases where so-called "trusted" https sites such as ebay are probing your LAN, so the fundamental problem remains.

https://nullsweep.com/why-is-this-website-port-scanning-me/

Re: Feedback wanted: CORS for private networks (RFC1918)

#52

Post by zeroimpl » Wed, Nov 11, 2020, 9:18 PM UTC

xg15 wrote: post #33

zeroimpl wrote: post #23

Earlier quoted context omitted.

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…

You cannot make an AJAX call from an HTTPS site to a HTTP site on a local IP address. 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.

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.

Re: Feedback wanted: CORS for private networks (RFC1918)

#53

Post by cratermoon » Thu, Nov 12, 2020, 8:35 PM UTC

toomuchtodo wrote: post #12

cratermoon wrote: post #9

Earlier quoted context omitted.

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…

> 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.

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".

Re: Feedback wanted: CORS for private networks (RFC1918)

#54

Post by xg15 » Sat, Nov 14, 2020, 9:45 AM UTC

duskwuff wrote: post #49

xg15 wrote: post #30

Earlier quoted context omitted.

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?