I prefer to assign an external name to an internal device and grab a free SSL cert from LetsEncrypt, but using DNS challenge instead as internal IP addresses aren't reachable by their servers.
replies(9):
Especially Android is finicky, ignoring your DNS server if it doesn't like your setup. For example, if it gets an IPv6 address, it requires the DNS server to also have an IPv6 address, or it'll use Google's DNS servers.
It works now but I'm not convinced it's worth it for me.
Yes, I sometimes think about that, but have come to the conclusion that it's not likely to make any difference. If someone is trying to infiltrate my home network, then it's not going to really help them to know internal IP addresses as by the time they get to use them, they're already in.
The only thing public is that you may have an internal network with nodes.
Basically, CNAME record from service.myserver.com to myserver.internal on a public DNS server, A record from myserver.internal to 1.2.3.4 on private DNS server.
I think I could maybe get it working on Windows too by tweaking the TTLs. Currently both DNS servers are automatically setting the TTL and I think Windows freaks out about that.
It was only until recently someone told me about the DNS challenge and I immediately ported everything over with a wildcard cert - its been great!
I don't think the publishing of host names was mentioned as a concern for small home networks, but more for larger organisations that might be subject to a coordinated break-in or simply have trade secrets¹² that might be hinted at by careless naming of resources.
----
[1] Their next big product/enhancement, as yet unannounced even within the company, for instance.
[2] Hmm, checking what is recorded against one of DayJob's domains I see clues as to who some of our clients are. Not really a significant issue for security at all, but I know at least some of our contracts say we shouldn't openly talk about that we provide services to that client³ so I'll drop a message to the ISC to suggest we discuss if we need to care about the matter…
[3] Though that is mostly in the form of not using their logos in our advertising and such.
Now it’s have a nice script that distributes my key automatically to 20 or so hosts and apps and have a real SSL cert on everything from my UDM Pro to my Synology to random Raspberry Pis running containers. Most of which have domain names that only resolve on my local network.
This is made possible by a fairly robust DNS setup that consists of not only giving A records to all my hosts automatically, but also adding in CNAMEs for services and blocking almost all outbound DNS, DNS over TLS, DoH, etc.
This would allow folks to have .internal with auto-discovered, decentralized, trusted PKI. It would also enable something like a DNSSEC on/off toggle switch for IoT devices to allow owners to MITM them and provide local functionality for their cloud services.
According to that, it's not supported by Chrome, nor Firefox.
* Loading it into every device was more work than it sounds. We have Android, iOS, Mac, Windows, and Linux, all of which have their own rules.
* Even once loaded, some applications come with their own set of root CAs. Some of those have a custom way of adding a new one (Firefox), others you just had to accept the invalid cert each time, and still others just refused to work.
* I deploy my self-hosted stuff with Docker, which means that not only does each device need to have the root CA added to it but every Docker image that talks to the internal network needs to have it as well. This ends up being a mix of the previous two problems, as I now have to figure out how to mount the CA on an eclectic bunch of distros and I often then have to figure out why the dockerized application isn't using the CA.
In the end I settled on a DNS-challenge wildcard SSL cert loaded into Caddy, with Caddy terminating TLS for everything that's on my home server. It's way simpler to configure the single server (or even 2-3 servers) than every single client.
One advantage of DNS challenge is that it can be run anywhere (i.e. doesn't need to run on the webserver) - it just needs the relevant credentials to add a DNS TXT record. I've got my automation wrapped up into a Docker container.
> It disables DoH when [...] a network tells Firefox not to use secure DNS. [1]
If we enabled DANE right now, then a malicious network could tell the browser to turn off DoH and to use a malicious DNS resolver. The malicious resolver could set the AD flag, so it would look like DNSSEC had been validated. They'd then be able to intercept traffic for all domains with DANE-validated TLS certificates. In contrast, it's difficult for an attacker to fraudulently obtain a TLS certificate from a public CA.
Even if we limit DANE to .internal domains, imagine connecting to a malicious network and loading webmail.internal. A malicious network would have no problem generating a DANE-validated TLS certificate to impersonate that domain.
[1] https://support.mozilla.org/en-US/kb/dns-over-https#w_defaul...
Putting aside the DNSSEC issues, IMO, DNS should be authoritative for everything. It's perfectly decentralized, and by purchasing a domain you prove ownership of it and shouldn't then need to work within more centralized services like Lets Encrypt/ACME to get a certificate (which seems to becoming more and more required for a web presence). A domain name and a routable IP should be all you need to host services/prove to users that domain.com is yours, and it's something I think we've lost sight of.
Yes, DANE can create security issues, your webmail example is a perfectly valid one. In those situations, you either accept the risk or use a different domain. Not allowing the behavior because of footguns never ends well with technology, and if you're smart enough to use .internal you should understand the risks of doing so.
Basically, we should let adults be adults on the internet and stop creating more centralization in the name of security, IMO.
FWIW, I solve this problem with wildcards + a central reverse proxy for containerized apps. I host most services on a subdomain of the machine that hosts containers, like "xxx.container.internal", "xxx2.container.internal", etc. Instead of each container doing it's own SSL I have one central reverse proxy container that binds to 443 and each app container gets put on an internal Docker network with the reverse proxy. Reverse proxy has a wildcard certificate for the host system domain name "*.container.internal" and you can just add an endpoint for each service SNI. I'm using Zoraxy, which makes it very easy to just add a new endpoint if I install a new app with a couple clicks, but this works with lots of other reverse proxies like Caddy, Nginx, etc. If containers need to talk to each other over the external endpoint for some reason and thus need the root CA you can mount the host system's certificate store into the container, which seems to work pretty well the one or two times I needed to do it.
I haven't really solved the annoyance of deploying my root CA to all the devices that need it, which truly is a clusterfuck, but I only have to do it once a year so it isn't that bad. Very open to suggestions if people have good ways to automate this, especially in a general way that can cover Windows/Mac/iOS/Android/various Linuxes uniformly since I have a lot of devices. I've experimented with Ansible, but that doesn't cover mobile devices, which are the ones that make it most difficult.
I've had working validly signed SSL on literally all my private home self-hosted services and load-balancers internally for years this way.
It also easily switches to a production like setup if you later did decide to host something on the public internet.
I have since then switched to ubiquiti products, and now I just run wireguard server for my road-warrior devices. Would use CloudFlare Tunnel if I ever need to expose anything publically.
It happens. I liked HPKP, which was also tried, and also failed.
IPv6 is going to happen (albeit over a longer time horizon than its advocates hoped). DNSSEC has failed.
Works great.
In my case everything points to a tailscale operator endpoint, which goes to nginx ingress, which routes to the appropriate pods.
It's very much a set-and-forget solution.
I didn't like this approach because I don't like to leak information about my internal setup but I found that you don't even have to register your servers on a public DNS so it's ok. Just the domain has to exist. It does create very temporary TXT records though.
The overlap of people that suggest that you either run your own PKI or just distribute a wildcard certificate and have the technical understanding on how to do this in a secure way is minuscule. The rest of those people are probably better off using something like Lets Encrypt.
https://www.verisign.com/en_US/company-information/verisign-...
Signed domains are increasing where they're done automatically by registrars; where the market has a say, use is declining --- sharply!
Apple is aware of it, but it's still not fixed in iOS 18.1.
Also I wouldn't be surprised if Let's Encrypt/ZeroSSL were compromised.
I have to wonder if there is some hidden ulterior motive behind that.
https://www.sidn.nl/en/modern-internet-standards/dnssec
Meanwhile: the graphs I posted in the preceding comment are pretty striking. If you haven't clicked through yet, you should. I've pointed out previous, minor drops in DNSSEC deployment in the US. The current one is not minor.
(For those who don’t know, MTA-STS is basically DANE but for people who hate DNSSEC. And are OK with requiring every mail server to also have a web server running.)
> The current one is not minor.
Maybe not, but I do not know the cause, and you have not proposed one either. Do you have a theory about what happened in late 2023? We’ll have to see if this trend continues; the graphs you linked do show a slight upward turn right at the end of the graphs.
(Also, your test is wrong. It should be “_mta-sts”, not “_mta_sts”.)
When it’s purposefully set up by actual people, I only hear about DANE. It’s only when talking about huge e-mail providers that I hear about MTA-STS. And, as I said previously, those huge providers probably chose MTA-STS not for any reason which benefits their regular users, but for reasons which benefits only themselves, being a huge operator.
If you're wondering why DNSSEC never took off, these kinds of exchanges are illustrative!
I am baffled by this claim. DNSSEC works completely transparently to the user.
Also, we were comparing the specifics of MTA-STS to DANE, not to DNSSEC. Both MTA-STS and DANE solves the same problem, i.e. fake X.509 certificates and/or protocol degradation (SSL stripping). DANE has the potential to solve the same problem for every protocol, not just SMTP, while MTA-STS is both specific to e-mail, and stupidly requires an additional web server on every SMTP server.
> and falling
It’s actually rising again, according to your sources.
In recent years, you seem to have dropped all pretense of arguing against the specifics of DNSSEC, which is good, but you have then resorted to argumentum ad populum. However, this is a bad form of argumentation unless you can explain why DNSSEC is not as popular as it could be. For instance, what happened in late 2023 to cause the dip?