Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.INTERNAL is now reserved for private-use applications

icann.org

Post reply on HN
Print view View original

141–150 of 290 posts

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

#141

Post by Hamuko »

xvilo wrote: post #37

Any ideas on how you would run SSL/TLS on these set-ups?

I just got myself a proper domain name. You can get a domain for pretty cheap if you're not picky about what you get. You could for example register cottagecheese.download on Cloudflare for about $5/year right now.

I have my domain's DNS on Cloudflare, so I can use DNS verification with Let's Encrypt to get myself a proper certificate that works on all of my devices. Then I just have Cloudflare DNS set up with a bunch of CNAME records to .internal addresses.

For example, if I needed to set up a local mail server, I'd set mail.cottagecheese.download to have a CNAME record pointing to localserver.internal and then have my router resolve localserver.internal to my actual home server's IP address. So if I punch in https://mail.cottagecheese.download in my browser, the browser resolves that to localserver.internal and then my router resolves that to 10.x.x.x/32, sending me to my internal home server that greets me with a proper Let's Encrypt certificate without any need to expose my internal IP addresses.

Windows doesn't seem to like my CNAME-based setup though. Every time I try to use them, it's a diceroll if it actually works.

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

#142

Post by IshKebab »

yjftsjthsd-h wrote: post #83
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…

Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.

A lot of modern web features now require HTTPS.

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

#143

Post by Wicher »

JonathonW wrote: post #102
akira2501 wrote: post #99

Earlier quoted context omitted.

localhost is a secure context. so.. presumably we're just waiting for .internal to be added to the white list.

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, except for the likes of us who like to ssh-tunnel all kinds of things on our loopback interfaces :-)

The sweet spot of security vs convenience, in the case of browsers and awarding "secure origin status" for .internal, could perhaps be on a dynamic case by case basis at connect time:

- check if it's using a self-signed cert - offer TOFU procedure if so - if not, verify as usual

Maaaaybe check whether the connection is to an RFC1918 private range address as well. Maybe. It would break proxying and tunneling. But perhaps that'd be a good thing.

This would just be for browsers, for the single purpose of enabling things like serviceworkers and other "secure origin"-only features, on this new .internal domain.

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

#144

Post by swiftcoder »

slimsag wrote: post #124
bruce511 wrote: post #92

Earlier quoted context omitted.

The big problem with running unencrypted HTTP on a LAN is that it's terribly easy for (most) LANs to be compromised. Let's start with the obvious; wifi. If you're visiting a company and ask the receptionist for the wifi password you'll likely get it. Next are eternity ports. Sitting waiting in a meeting room, plug your laptop into the ethernet port and you're in. And of course it's not just hardware, any software run…

Also, make sure your TLS certificates are hard-coded/pinned in your application binary. Just like the network, you really cannot trust what is happening on the user's system. This way you can ensure you as the developer have full control over your applications' network communication; by requiring client certificates issued by a CA you control, you can assert there is no MITM even if a sysadmin, user, or malware tries…

In practice pinning tends to be very "best effort", if not outright disadvantageous.

All our apps had to auto-disable pinning less than a year after the build date, because if the user hadn't updated the app by the time we had to renew all our certs... they'd be locked out.

Also dealt with the fallout from a lovely little internet-of-things device that baked cert pinning into the firmware, but after a year on store shelves the clock battery ran out, so they booted up in 1970 and decided the pinned certs wouldn't become valid for ~50 years :D

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

#145

Post by AndyMcConachie »

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…

If you read the document that originally lead the ICANN Board to reserve .INTERNAL (SAC113) you will find this exact sentiment.

The SSAC's recommendation is to only use .INTERNAL if using a publicly registered domain name is not an option. See Section 4.2.

https://itp.cdn.icann.org/en/files/security-and-stability-ad...

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

#146

Post by Too »

slimsag wrote: post #124
bruce511 wrote: post #92

Earlier quoted context omitted.

The big problem with running unencrypted HTTP on a LAN is that it's terribly easy for (most) LANs to be compromised. Let's start with the obvious; wifi. If you're visiting a company and ask the receptionist for the wifi password you'll likely get it. Next are eternity ports. Sitting waiting in a meeting room, plug your laptop into the ethernet port and you're in. And of course it's not just hardware, any software run…

Also, make sure your TLS certificates are hard-coded/pinned in your application binary. Just like the network, you really cannot trust what is happening on the user's system. This way you can ensure you as the developer have full control over your applications' network communication; by requiring client certificates issued by a CA you control, you can assert there is no MITM even if a sysadmin, user, or malware tries…

This is way overkill, unless you are making a nuclear rocket launch application. If you can not trust the system root CA, the whole internet breaks down.

You will also increase the risk that your already understaffed ops-team messes up and creates even worse exposure or outages, while they are trying to figure out what ssl-keygen does.

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

#147

Post by ixfo »

politelemon wrote: post #133
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.

It's the opposite - there is a risk, but not a larger risk. Environment traversal is easier through a certificate transparency log, there is almost zero work to do. Through a wildcard compromise, the environment is not immediately visible. It's much safer to do wildcard for certs for internal use.

Environment visibility is easy to get. If you pwn a box which has foo.internal, you can now impersonate foo.internal. If you pwn a box which has *.internal, you can now impersonate super-secret.internal and everything else, and now you're a DNS change away from MITM across an entire estate.

Security by obscurity while making the actual security of endpoints weaker is not an argument in favour of wildcards...

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

#148

Post by slaymaker1907 »

nine_k wrote: post #69
TheRealPomax wrote: post #61

Earlier quoted context omitted.

to be fair, ".dev" is not a full word, unlike INTERNAL or EXAMPLE. You're free to petition them to reserve .DEVELOPMENT, though, of course.

A convenient TLD is short, not excruciatingly loquacious. In ease of typing .dev certainly wins over .development.

Luckily, we have *.test. I’ve used that one quite a bit.

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

#149

Post by thaumasiotes »

wkat4242 wrote: post #98
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…

The problem with internal CAs is also that it's really hard to add them on some OSes now. Especially on android since version 7 IIRC, you can no longer get certs into the system store, and every app is free to ignore the user store (I think it was even the default to ignore it). So a lot of apps will not work with it.

> The problem with internal CAs is also that it's really hard to add them on some OSes now. Especially on android since version 7 IIRC

That's because the purpose of certificate pinning is to protect software from the user. Letting you supply your own certificates would defeat the purpose of having them.

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

#150

Post by tsimionescu »

Too wrote: post #137
akira2501 wrote: post #99

Earlier quoted context omitted.

localhost is a secure context. so.. presumably we're just waiting for .internal to be added to the white list.

No. The concept of a DMZ died decades ago. You could still be MITM within your company intranet. Any system designed these days should follow zero-trust principles.

Sure, but people still need to test things, and HTTPS greatly complicates things. Browsers' refusal to make it poasible to run anything unencrypted when you know what you're doing is extremely annoying, and has caused significant losses of productivity throughout the industry.

If they're so worried about users getting duped to activate the insecure mode, they could at least make it a compiler option and provide an entirely separate download in a separate place.

Also, don't get me started on HSTS and HSTS preloading making it impossible to inspect your own traffic with entities like Google. It's shameful that Firefox is even more strict about this idiocy than Chrome.

Post reply on HN