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

181–190 of 290 posts

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

#181

Post by miah_ »

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.

Years back I ran into a issue at work because somebody named their computer "localhost" on a network with automatic DNS registration. Because of DNS search path configuration it would resolve. So, "localhost" ended up resolving to something other than an address on 127.0.0.0/8! It was a fun discovery and fixed soon after I reported it.

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

#182

Post by TeMPOraL »

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.

Doesn't matter for mixed content, like e.g. when you run a client-side only app that happens to be loaded from a public domain over HTTPS, and want it to call out to an API endpoint running locally. HTTP won't fly. And good luck reverse-proxying it without a public CA cert either.

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

#183

Post by PartiallyTyped »

cowsup wrote: post #172
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.

.com is not a full word either (company), or .org (organization), .net (internet), .gov (government), ...

I thought .com was for "commercial".

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

#184

Post by tsimionescu »

the8472 wrote: post #166
tsimionescu wrote: post #150

Earlier quoted context omitted.

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

To inspect your own traffic you can use SSLKEYLOGFILE and then load it into wireshark.

Most apps don't support SSLKEYLOGFILE. OpenSSL, the most popular TLS library, doesn't support it.

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

#185

Post by moontear »

prussian wrote: post #104
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…

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/

I wish there was a way to remove public information such as this. Just like historical website ownership records. Maybe interesting for research purposes, but there is so much stuff in public records I don't want everyone to have access to. Should have thought about that before creating public records - but one may not be aware of all the ramifications of e.g. just creating an SSL cert with letsencrypt or registering a random domain name without privacy extensions.

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

#186

Post by evandrofisico »

okanat wrote: post #169
thaumasiotes wrote: post #149

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

Protect the software from the user? Why are you giving them the software then?

For example, to make it harder to reverse engineer the protocol between the app and the server.

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

#187

Post by noirscape »

okanat wrote: post #169
thaumasiotes wrote: post #149

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

Protect the software from the user? Why are you giving them the software then?

A lot of mobile software is just a UI around an external web API. The main reason why Android makes it difficult to get the OS to accept an external certificate (you need root for it) is because without it, you can just do a hosts hack through a vpn/dns to redirect it to your own version of that API. Which app manufacturers want to prevent since it's a really easy way to snoop on what endpoints an app is calling and to say, build your own API clone of that app (which is desirable if you're say, selfhosting an open source server clone of said software... but all the official applications are owned by the corporate branch and don't let you self-configure the domain/reduce the experience when you point it to a selfhosted domain).

It's extremely user-hostile since Android has a separate user store for self-signed CAs, but apps are free to ignore the user store and only accept the system store. I think by default only like, Chrome accepts the user store?

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

#188

Post by layer8 »

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…

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.

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

#189

Post by layer8 »

jcrites wrote: post #24

Are there any good reasons to use a TLD like .internal for private-use applications, rather than just a regular gTLD like .com? It's nice that this is available, but if I was building a new system today that was internal, I'd use a regular domain name as the root. There are a number of reasons, and one of them is that it's incredibly nice to have the flexibility to make a name visible on the Internet, even if it is c…

Read section 2.1 of the linked https://itp.cdn.icann.org/en/files/security-and-stability-ad... for some motivations.
Post reply on HN