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

131–140 of 290 posts

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

#131

Post by frogsRnice »

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…

Pinning is very complex, there is always the chance that you forget to update the pins and perform a denial of service against your own users. At the point where the device itself is compromised, you can’t really assert to anything. Furthermore, there is always the risk that your developers implement pinning incorrectly and introduce a chain validation failure.

Lots of apps use the anticheat/obfuscation mechanisms added by mobile apps are also trivial to bypass using instrumentation - ie frida codeshare. I know you aren’t implying that people should use client side controls to protect an app running on a device and an environment that they control, but in my experience even some technical folk will try and to do this

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

#132

Post by PokestarFan »

ninkendo wrote: post #117
quectophoton wrote: post #34

Earlier quoted context omitted.

When you need to assign an IP address for a host, the safest thing to do is to either use an IP address you own^Ware renting, or to use an IP address nobody will be able to "own" in the foreseeable future. This is that but for domain names. When you need to use a domain name to refer to a host, the safest thing to do is to either use a domain name you own^Ware renting, or to use a domain name nobody will be able to "…

There’s similar discussions about this in other threads, but I’ve taken to just using a real domain name (lan. .me) even for my house stuff, but otherwise doing something like you say above. The advantage is that I can run real letsencrypt certs for services in my house, which is nicer than having to agree to self signed cert warnings or otherwise having my browser nag me about plaintext passwords/etc. If anyone care…

Why not just use ACME DNS?

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

#133

Post by politelemon »

qmarchi wrote: post #125
Helmut10001 wrote: post #114

Earlier quoted context omitted.

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.

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.

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

#134

Post by luma »

jcrites wrote: post #31
leeter wrote: post #27

Earlier quoted context omitted.

I can't speak for others but HSTS is a major reason. Not everybody wants to deal with setting up certs for every single application on a network but they want HSTS preload externally. I get why for AWS the solution of having everything from a .com works. But for a lot of small businesses it's just more than they want to deal with. Another reason is information leakage. Having DNS records leak could actually provide p…

> Having DNS records leak could actually provide potential information on things you'd rather not have public. This is true, but using a regular domain name as your root does not require you to actually publish those DNS records on the Internet. For example, say that you own the domain `example.com`. You can build a private service `foo.example.com` and only publish its DNS records within the networks where it needs…

It's not DNS that's leaking those names, it's certificate transparency. If you are using certs on foo.example.com, that's publicly discoverable due to CTLs. As others have mentioned here it leaves you with a dilemma, either you have good working certs internally but are also exposing all of your internal hostnames, or you keep your hostnames private but have cert problems (either dealing with trusting a private CA or dealing with not having certs).

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

#135

Post by bawolff »

thebeardisred wrote: post #113
bawolff wrote: post #45

Earlier quoted context omitted.

I think there is a benefit that it reduces possibility of misconfiguration. You can't accidentally publish .internal. If you see a .internal name, there is never any possibility of confusion on that point.

Additionally how do you define publish? When someone embeds https://test.internal with a cert validation turned off (rather then fingerprint pinning or setting up an internal CA) in their mobile application that client will greedily accept whatever response is provided by their local resolver... Correct or malicious.

That seems kind of besides the point. If you turn off cert validation, it doesn't matter if the domain name is internal or external.

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

#136

Post by unethical_ban »

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.

That's some "it's okay to keep my finger on the trigger when the gun is unloaded" energy.

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

#137

Post by Too »

akira2501 wrote: post #99
j1elo wrote: post #93

Earlier quoted context omitted.

Try running anything more complicated than a plain and basic web server! See what happens if you attempt to serve something that browsers deem to require a mandatory "Secure Context", so they will reject running it when using HTTP. For example, you won't be able to run internal videocalls (no access to webcams!), or a web page able to scan QR codes. Here's the full list: * https://developer.mozilla.org/en-US/docs/Web…

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.

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

#138

Post by viraptor »

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

Ideally, you use "testing.company-name.internal" for that kind of things. (Especially if you think you'll ever end up interacting at that level)
Post reply on HN