Hacker News Reader

Comment by lilyball | Hacker News Reader

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?

View on HN

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.

How the heck would I go about installing my own root cert into my TV? My fridge? (I'm picking devices here that could actually run browsers.)

How the heck would I have my DNS be public, if I don't have a domain? Getting one means a cost (some amount for the registration, plus whatever you consider costs to avoid your information in the registry getting leaked)

For large corporations, yes it totally makes sense to have your infrastructure be using proper domains and things. For your neighbor's network behind his router… not so much. Nothing that requires TLS does.

In the context of this proposal, i'm not sure why your routers and stuff would need one, it seems like only corporate stuff would be affected.

That said, for a router, it would be vendors responsibility to set this all up. It seems possible but annoying to do this in a secure but privacy preserving way.

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.

The proposal does not attempt to force private network resources to use TLS. That would be an excellent outcome, but it's difficult to do in the status quo, and is a separate problem to address separately.

The proposal _does_ require pages that wish to request resources across a network boundary to be delivered securely, which therefore requires resources that wish to be accessible across network boundaries to be served securely (as they'd otherwise be blocked as mixed content). This places the burden upon those resources which wish to be included externally, which seems like the right place for it to land.

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

"Local", in this context, means localhost (i.e. the machine that the web browser is running on). It does not mean other machines on the private network.

Generally speaking, this simply enforces that, if you are running a web server on your local machine, external web sites (either on your private network or on the Internet at large) cannot trigger requests to that web server.

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?

That's not how I understood it. "Make sure the website making requests to a private network is served over HTTPS."

My understanding of it is the site making the call to the resource on the 'private' network, must be served via HTTPS.

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.

Just because your internal domain for your computers ends in .local does not mean your internal websites need to end in .local.

There's nothing preventing you from creating another DNS zone.

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

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

Reply on news.ycombinator.com