.INTERNAL is now reserved for private-use applications • Hacker News Board

Re: .INTERNAL is now reserved for private-use applications

#231

Post by JonathonW » Sat, Aug 10, 2024, 4:20 PM UTC

Wicher wrote: post #143

JonathonW wrote: post #102

Earlier quoted context omitted.

Unlikely. Localhost can be a secure context because localhost traffic doesn't leave your local machine; .internal names have no guarantees about where they go (not inconceivable that some particularly "creative" admin might have .internal names that resolve to something on the public internet).

One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it). So it's not a rock-hard guarantee that traffic to localhost never leaves your system. It would be unconventional and uncommon for it to, though,…

> One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it).

The secure context spec [1] addresses this-- localhost should only be considered potentially trustworthy if the agent complies with specific name resolution rules to guarantee that it never resolves to anything except the host's loopback interface.

[1] https://w3c.github.io/webappsec-secure-contexts/#localhost

Re: .INTERNAL is now reserved for private-use applications

#232

Post by brewmarche » Sat, Aug 10, 2024, 4:24 PM UTC

qwertox wrote: post #210

qmarchi wrote: post #125

Earlier quoted context omitted.

There's a larger risk that if someone breaches a system with a wildcard cert, then you can end up with them being able to impersonate _every_ part of your domain, not just the one application.

I issue a wildcard cert for *.something.example.com . All subdomains which are meant for public consumption are at the first level, like www.example.com or blog.example.com , and the ones I use internally (or even privately accessible on the internet, like xmpp.something.example.com ) are not up for discovery, as no public records exist. Everything at *.something.example.com , if it is supposed to be privately access…

This is the DNS setup I’d have in mind as well.

Regarding the certificates, if you don’t want to set up stuff on clients manually, the only drawback is the use of a wildcard certificate (which when compromised can be used to hijack everything under something.example.com).

An intermediate CA with name constraints (can only sign certificates with names under something.example.com) sounds like a better solution if you deem the wildcard certificate too risky. Not sure which CA can issue it (letsencrypt is probably out) and how well supported it is

Re: .INTERNAL is now reserved for private-use applications

#233

Post by 8organicbits » Sat, Aug 10, 2024, 4:24 PM UTC

nightpool wrote: post #218

layer8 wrote: post #201

Earlier quoted context omitted.

You’re basically saying that .internal can cause frustration when it is used without good reason. Fair enough, but also not surprising. When it is used for the intended reasons though, then there’s just no other solution. It’s a trade-off between conflicting goals. “Simply do X instead” doesn’t remove the trade-off.

What do you see as the intended reasons with no other solutions?

The biggest benefit of .internal IMO is that it is free to use. Free domains used to be a thing, but after the fall of Freenom you're stuck with free subdomains.

Re: .INTERNAL is now reserved for private-use applications

#234

Post by thayne » Sat, Aug 10, 2024, 4:24 PM UTC

kelnos wrote: post #100

nox101 wrote: post #76

Earlier quoted context omitted.

What about things like cookies, storage, caching, etc.. If my job has ` https://testing.internal ` and some company I visit also has ` https://testing.internal ` ...

Presumably you don't trust the CA that signed the certificate on the server at the company you're visiting. As long as you heed the certificate error and don't visits the site, you're fine.

Now suppose you are a contractor who did some work for company A, then went to do some work for company B, and still have some cookies set from A's internal site.

Re: .INTERNAL is now reserved for private-use applications

#235

Post by [deleted] » Sat, Aug 10, 2024, 4:34 PM UTC

dboreham wrote: post #87

jeroenhd wrote: post #71

Earlier quoted context omitted.

It does! I generally assume mDNS to just be available on every device these days. But I've also seen managed environments where mDNS has been turned off or blocked at the firewall.

mDNS is a broadcast protocol so always "blocked at the firewall ".

[deleted]

Re: .INTERNAL is now reserved for private-use applications

#236

Post by fleminra » Sat, Aug 10, 2024, 4:44 PM UTC

thayne wrote: post #222

layer8 wrote: post #188

Earlier quoted context omitted.

I don’t understand the frustration. The use of .internal is explicitly for when you don’t want a publicly valid domain. Nobody is forcing anyone to use .internal otherwise.

My frustration is because using a private CA is more difficult than it should be. You can't just add the CA to system trust stores on each device, because some applications, notably browsers and java, use their own trust stores, you have to add it to. You also can't scope the CA to just .internal, which means in a BYOD environment, you have to require your employees to trust you not to sign certs for other domains. A…

The Name Constraints extension can limit the applicability of a CA cert to certain subdomains or IP addresses.

Re: .INTERNAL is now reserved for private-use applications

#237

Post by undersuit » Sat, Aug 10, 2024, 4:52 PM UTC

dawnerd wrote: post #60

I'm still peeved they let google take over .dev when they knew tons of us used that in the older days for dev environments.

I used .coffee on my home network until it became a for-profit TLD. https://icannwiki.org/.coffee

Re: .INTERNAL is now reserved for private-use applications

#238

Post by derefr » Sat, Aug 10, 2024, 4:58 PM UTC

8organicbits wrote: post #46

My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess. Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of t…

It would be impossible for .internal domains to be publicly CAed, because they're non-unique; the whole point of .internal domains is that, just like private-use IP space, anyone can reuse the same .internal DNS names within their own organization.

X.509 trust just doesn't work if multiple entities can get a cert for the same CN under the same root-of-trust, as then one of the issuees can impersonate the other.

If public issuers would sign .internal certs, then presuming you have access to a random org's intranet, you could MITM any machine in that org by first setting up your own intranet with its own DNS, creating .internal records in it, getting a public issuer to issue certs for those domains, and then using those certs to impersonate the .internal servers in the org-intranet you're trying to attack.

Re: .INTERNAL is now reserved for private-use applications

#239

Post by briHass » Sat, Aug 10, 2024, 5:02 PM UTC

yjftsjthsd-h wrote: post #198

briHass wrote: post #195

Earlier quoted context omitted.

I just got burned on my home network by running my own CA (.home) and DNS for connected devices. The Android warning when installing a self-signed CA ('someone may be monitoring this network') is fine for my case, if annoying, but my current blocker is using webhooks from a security camera to Home Assistant. HA allows you to use a self-signed cert, but if you turn on HTTPS, your webhook endpoints must also use HTTPS…

> Once again, we're stuck in this annoying scenario where certificates serve 2 goals: encryption and verification, but internal use really only cares about the former. Depending on your threat model, I'm not sure that's true. Encryption without verification prevents a passive observer from seeing the content of a connection, but does nothing to prevent an active MITM from decrypting it.

I meant more: centralized verification. I'm fine with deploying a self-CA cert to verify in my personal world, but browsers and devices have become increasingly hostile to certs that aren't signed by the standard players.

Re: .INTERNAL is now reserved for private-use applications

#240

Post by fulafel » Sat, Aug 10, 2024, 5:06 PM UTC

kevincox wrote: post #170

fulafel wrote: post #126

Earlier quoted context omitted.

Yep, ambiguous addressing doesn't save you, same as 10.x IPv4 networks. And one day you'll need to connect or merge or otherwise coexist with disparate uses if it's a common one (like in .internal and 10.x)...

IPv6 solves this as you are strongly recommend to use a random component at the top of the internal reserved space. So the chance of a collision is quite low.

There's usually little reason to use reserved space vs internet addresses, unless you just want to relive the pain of NAT+IPv4. The exception is if you lack PI space and can't copy with potential renumbering.