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

151–160 of 290 posts

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

#151

Post by im3w1l »

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,…

localhost is pretty special in that it's like the only domain typically defined in a default /etc/hosts.

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

#152

Post by 7bit »

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…

> My biggest frustration with .internal is that it requires a private certificate authority

So don't use it?

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

#153

Post by jve »

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.

I consider HTTPS to be easier to run - you get less trouble in the end.

As mentioned, some browser features are HTTPS only. You get security warnings on HTTP. Many tools now default to HTTPS by default - like newer SQL Server drivers. Dev env must resemble prod very closely so having HTTP in DEV and HTTPS in prod is asking for pain and trouble. It forces you to have some kind of expiration registry/monitoring and renewal procedures. And you happen to go throught dev env first and gain confidence and then prod.

Then there are systems where client certificate is mandatory and you want to familiarize yourself already in dev/test env.

Some systems even need additional configuration to allow OAuth via HTTP and that makes me feel dirty thus I rather not do it. Why do it if PROD won't have HTTP? And if one didn't know such configuration must be done, you'd be troubleshooting that system and figuring out why it doesn't work with my simple setup?

Yeah, we have internal CA set up, so issuing certs are pretty easy and mostly automated and once you go HTTPS all in, you get the experience why/how things work and why they may not and got more experience to troubleshoot HTTPS stuff. You have no choice actually - the world has moved to TLS secured protocols and there is no way around getting yourself familiar with security certificates.

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

#154

Post by soraminazuki »

otabdeveloper4 wrote: post #105
kortilla wrote: post #96

Earlier quoted context omitted.

Hoping datacenter to datacenter links are secure is how the NSA popped Google. Turn on crypto, don’t be lazy

Pretty sure state-level actors sniffing datacenter traffic is literally the very last of your security issues. This kind of theater actively harms your organization's security, not helps it. Do people not do risk analysis anymore?

NSA sniffs all traffic through various internet choke points in what's known as upstream surveillance. It's not just data center traffic.

https://www.eff.org/pages/upstream-prism

These kind of risks are obvious, real, and extensively documented stuff. I can't imagine why anyone serious about improving security for everyone would want to downplay and ridicule it.

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

#157

Post by 8organicbits »

Terr_ wrote: post #119
wkat4242 wrote: post #98

Earlier quoted context omitted.

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.

Speculating a bit out of my depth here, but I'm under the impression that most of those sometimes-configurable OS-level CA lists are treated as "trust anything consistent with this data", as opposed to "only trust this CA record for these specific domain-patterns because that's the narrow purpose I chose to install it for." So there are a bunch of cases where we only want the second (simpler, lower-risk) case, but we…

Yes! Context specific CA trust would be great, but AFAIK isn't possible yet. Even name constraints, which are domain name limitations a CA or intermediate cert place on itself, are slowly being supported by relevant software [1].

As a contractor, I'll create a per-client VM for each contract and install any client network CAs only within that VM.

[1] https://alexsci.com/blog/name-non-constraint/

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

#158

Post by 0l »

hsbauauvhabzb wrote: post #129
kelnos wrote: post #100

Earlier quoted context omitted.

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?

Use HSTS, browsers are specifically designed not to let users bypass these.

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

#159

Post by AndyMcConachie »

zzo38computer wrote: post #48
Denvercoder9 wrote: post #29

Earlier quoted context omitted.

> I also think that a .pseudo TLD should be made up which also cannot be assigned on the internet, but is also not for assigning on local networks either. There's already .example, .invalid, .test and .localhost; which are reserved. What usecase do you have that's not covered by one of them?

.example is used for examples in documentation and stuff like that. .invalid means that a domain name is required but a valid name should not be used; for example, a false email address in a "From:" header in Usenet, to indicate that you cannot send email to the author in this way. .test is for a internal testing use, of DNS and other stuff. .localhost is for identifying the local computer. .internal is (presumably)…

Have a look at .ALT

https://www.rfc-editor.org/rfc/rfc9476.html

Post reply on HN