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

121–130 of 290 posts

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

#121

Post by abtinf »

jeroenhd wrote: post #19
duskwuff wrote: post #7

Earlier quoted context omitted.

.local is already reserved for mDNS.

.local is in this weird state where it's _technically_ not reserved, but most PCs in the world already resolve it with special non-DNS software because of the Bonjour/mDNS protocol. So you end up with the IETF standardising .local, because Apple was already using it, but ICANN never did much with that standardisation. I doubt ICANN will actually touch .local, but they could. One could imagine a scheme where .local is…

> but they could.

Presumably, ICANN, like any other committee, is not interested in self-castration. Which is what would happen if they challenged Apple.

ICANN could do anything with enough rule changes. And then everyone will ignore them.

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

#122

Post by francislavoie »

seb1204 wrote: post #120
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…

https://letsencrypt.org/ does not work?

No, that's a public CA. No public domain registrars will be allowed to sell .internal domains so no public DNS servers will resolve .internal and that's a requirement for let's encrypt to validate that you control the domain. So you must use a private CA (one that you create yourself, with something like Smallstep, Caddy, or OpenSSL commands) and you'll need to install that CA's root certificate on any devices you want to be able to connect to your server(s) that use .internal

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

#123

Post by gorgoiler »

bruce511 wrote: post #92
lysace wrote: post #88

Earlier quoted context omitted.

There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.

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…

Well said. I used to be of the mindset that if I ran VLANs I could at least segregate the good guys from the evil AliExpress wifi connected toasters. Now everything feels like it could become hostile at any moment and so, on that basis, we all share the same network with shields up as if it were the plain, scary Internet. It feels a lot safer.

I guess my toaster is going to hack my printer someday, but at least it won’t get into my properly-secured laptop that makes no assumptions the local network is “safe”.

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

#124

Post by slimsag »

bruce511 wrote: post #92
lysace wrote: post #88

Earlier quoted context omitted.

There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.

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 to install a proxy root CA on the system.

Finally, you can add binary obfuscation / anticheat mechanisms used commonly in video games to ensure that even if someone is familiar with the application in question they cannot alter the certificates your application will accept.

Lots of e.g. mobile banking apps, etc. do this for maximal security guarantees.

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

#125

Post by qmarchi »

Helmut10001 wrote: post #114
prussian wrote: post #104

Earlier quoted context omitted.

Just be mindful that any certs you issue in this way will be public information[1] so make sure the domain names don't give away any interesting facts about your infrastructure or future product ideas. I did this at my last job as well and I can still see them renewing them, including an unfortunate wildcard cert which wasn't me. [1] https://crt.sh/

Just use wildcard certs and internal subdomains remain internal information.

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.

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

#126

Post by fulafel »

nox101 wrote: post #76
ghshephard wrote: post #52

Earlier quoted context omitted.

Number one reason that comes to mind is you prevent the possibility of information leakage. You can't screw up your split-dns configuration and end up leaking your internal IP space if everything is .internal. It's much the same reason why some very large IPv6 services deploy some protected IPv6 space in RFC4193 FC::/7 space. Of course you have firewalls. And of course you have all sorts of layers of IDS and air-gaps…

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

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

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

#127

Post by Spooky23 »

bruce511 wrote: post #92
lysace wrote: post #88

Earlier quoted context omitted.

There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.

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…

The big issue with encrypted HTTP on the local LAN is that you’re stuck running a certificate authority, ignoring TLS validation, or exposing parts of your network in the name of transparency.

Running certificate authority is one of those a minute to learn, lifetime to master scenarios.

You are often trading “people can sniff my network scenario” to a “compromise the CA someone setup 10 years ago that we don’t touch” scenario.

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

#128

Post by PokestarFan »

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…

At some point you have to wonder if your app even matters that much.

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

#129

Post by hsbauauvhabzb »

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.

So we’re back to trusting the user?

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

#130

Post by laz »

lysace wrote: post #88
yjftsjthsd-h wrote: post #83

Earlier quoted context omitted.

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.

There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.

Exactly what an NSA puppet account would say!

Don't believe the hype. Remember the smiley from "SSL added and removed here"

https://blog.encrypt.me/2013/11/05/ssl-added-and-removed-her...

Post reply on HN