Live data from Hacker News

Feedback wanted: CORS for private networks (RFC1918)

web.dev

11–20 of 54 posts

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

#11
post #6

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.

It says right there in the proposal

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

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

#12
post #7

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…

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

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

#13
post #7

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?

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.

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

#14
post #7

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?

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.

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

#15
post #13
post #7

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?

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.

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

#17
post #7

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?

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.

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

#18
post #7

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?

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.

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

#19
post #15
post #13

Earlier quoted context omitted.

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.

That's why i was suggesting using wildcard certs - they would not have the actual domain name in them.

That said, regardless of what one does, i wouldn't reccomend putting too much faith in security by obscurity.

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

#20
post #14
post #7

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?

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.

It does mention private to local requests will be affected, which is implying the private network host must be served via https

> Requests from a private network to a local network

https://web.dev/cors-rfc1918-feedback/#what-kinds-of-request...

Post reply on HN