I need a dumbed down version of this.
.INTERNAL will never appear in the DNS root zone.
.INTERNAL is now reserved for private-use applications
161–170 of 290 posts
Re: .INTERNAL is now reserved for private-use applications
#162Earlier 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.
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 ren…
At my first job out of college we built an API and a couple official clients for it. The testing endpoint used self-signed certs so we had to selectively configure clients to support it. Right before product launch we caught that one of our apps was ignoring certificate verification in production too due to a bug. Ever since then I've tried to run publicly valid certificates on all endpoints to eliminate those classes of bugs. I still run into accidentally disabled cert validation doing security audits, it's a common mistake.
Re: .INTERNAL is now reserved for private-use applications
#163Earlier 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.
Can't you have a limited wildcard?
Something like *.for-testing-only.company.com?
Re: .INTERNAL is now reserved for private-use applications
#164Earlier quoted context omitted.
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?
Because this setup works fine, and I haven’t bothered getting to that level of automation with my external DNS provider.
Re: .INTERNAL is now reserved for private-use applications
#165My 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 use https://github.com/FiloSottile/mkcert for my internal stuff.
Re: .INTERNAL is now reserved for private-use applications
#166Earlier quoted context omitted.
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 en…
To inspect your own traffic you can use SSLKEYLOGFILE and then load it into wireshark.
Re: .INTERNAL is now reserved for private-use applications
#167Earlier 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.
Can't you have a limited wildcard? Something like *.for-testing-only.company.com?
Yes, but then you are putting more information into the publically logged certificate. So it is a tradeoff between scope of certificate and data leak.
I guess you can use a pattern like {human name}.{random}.internal but then you lose memoribility.
Re: .INTERNAL is now reserved for private-use applications
#168Earlier quoted context omitted.
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?
Taking defense in depth measures like using https on the local network is "theatre" that "actively harms your organization's security"? That seems like an extreme opinion to me. Picking some reasonable best practices like using https everywhere for the sake of maintaining a good security posture doesn't mean that you're "not doing risk analysis".
I have seen people disabling all cert validation in an application because SSL was simultaneously required and no proper CA was provided for internal things. The net effect was thus that even the traffic going to the internet was no longer validated.
Re: .INTERNAL is now reserved for private-use applications
#169Earlier 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.
> 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?
Re: .INTERNAL is now reserved for private-use applications
#170Earlier 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 ` ...
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)...
IPv6 solves this as you are strongly recommend to use a random component at the top of the internal reserved space. So the chance of a collision is quite low.