Just want simple TLS for your .internal network?
github.com
github.com
This repo links to BetterTLS, which previously audited name constraint support, but BetterTLS only checked name constraint support at the intermediary certificates not at the trust anchors. I reported[1] the oversight a year back, but Netflix hasn't re-engineered the tests.
Knowing how widely adopted name constraints are on the client side would be really useful, but I haven't seen a sound caniuse style analysis.
Personally, I think the public CA route is better and I built a site that explores this[2].
I don't see how other solutions are less problematic.
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.
looks nice, can you give more details on this? tks!
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.
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.
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.
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.
Especially as people will talk about it as a “you'll never guess what…” when talking about places they work or have worked.
The only thing public is that you may have an internal network with nodes.
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!
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.
Let me know if I've misunderstood your point, and there some other widespread niche usage DANE finds in SMTP.
(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.)
(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?
> 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.
IPv6 is going to happen (albeit over a longer time horizon than its advocates hoped). DNSSEC has failed.
This is the customary comment by me that this is far from the prevailing view. From my viewpoint, DNSSEC is steadily increasing, both in demand and in amount of domains signed.
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!
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.
> 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.
It happens. I liked HPKP, which was also tried, and also failed.
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.
* 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.
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.
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.
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.
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.
Apple is aware of it, but it's still not fixed in iOS 18.1.
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.
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 Trouble with Name Constraints
> The Name Constraints extension lives on the certificate of a CA but can’t actually constrain what a bad actor does with that CA’s private key
> Therefore, it is up to the TLS _client_ to verify that all constraints are satisfied
> However, as we extended our test suite beyond basic tests we rapidly began to lose confidence. We created a battery of test certificates which moved the subject name between the certificate’s subject common name and Subject Alternate Name extension, which mixed the use of Name Constraint whitelisting and blacklisting, and which used both DNS names and IP names in the constraint. The result was that every browser (except for Firefox, which showed a 100% pass rate) and every HTTPS client (such as Java, Node.JS, and Python) allowed some sort of Name Constraint bypass.
That’s the danger of any solution that requires trusting a self-signed CA. Better just trust the leaf certificate, maybe make it wildcard, so you only have to go through the trust-invalid-cert once?
The situation has improved since then, see the linked https://news.ycombinator.com/item?id=37544094
The name constraints can give me a hint what it’s designed for, but if I import a cert to MITM devsite.org, I don’t want that cert working for mybank.com.
Packaged into a convenient one-liner to create a wildcard cert under for the new .internal TLD.
Please scrutinize!
I use this to provide e.g. at home:
https://octoprint.myhome.internal
https://paperless.myhome.internal
Friends and family can add the CA root to their devices without having to worry about me MitM'ing their other connections.
For example my government uses non-standard CA and some websites rely on it. But importing CA obviously makes them able to issue google.com and MITM me if they want to. And they already tried, so trust is broken.
I imagine something like generating separate name-constrained certificate, sign existing CA with this name-constrained certificate (I think it's called cross-sign or something like that) and import things into OS, expecting that browser will use name-constraints of the "Root-Root" certificate. Could it work?
[1] Yes, company is ok with it, most of my team does it, and this makes everyone more secure. Win-win.
Increasingly that kind of requirement puts you in the same camp as oppressive nation states. Being a network operator and wanting to MitM your DNS makes you a political actor. Devices you paid for, but don't actually own, will end-run your efforts by using their own hard-coded DNS servers. (See https://pc.nanog.org/static/published/meetings/NANOG77/2033/...)
Though I fully understand I'm in the same camp as oppressive nation states. But until my kids get older I'm in charge, I need to set them up for success in life, which is a complex balance of letting them have freedom without allowing them to make too many bad decisions. Not getting their homework done because they are watching videos is on bad decisions I'm trying to prevent.
So really instead of thinking about this like "parents are acting like nation states" I think it's much better to think of it like "parents are countering corporate nation states."
I was thinking more about embedded devices that people buy but don't own (Chromecast devices, "Smart" home doodads, etc). You can stick them in a VLAN and filter their access to the Internet but they're inscrutable inside and have opaque, encrypted communication with their "mother ship".
I think your goal with your kids is laudable. I do the same thing. It limits the ability to use off-the-shelf devices and software, and I'll get more flak about it as my daughter gets older and is excluded from the "social" applications that I can't allow her to use because they're closed-source and not able to be effectively filtered. I'll burn that bridge when I get there, I suppose...
Not just devices, Jetbrains software has hardcoded DNS too. I've had to resort to blocking its traffic entirely because of the sheer number of servers and ports it tries in order to work around my DNS blocking, now I allow traffic only during license/update checks. I'm sure other large vendors do something similar.
https://intellij-support.jetbrains.com/hc/en-us/community/po...
One day they will do both, but that day is probably far away.
And they are on my network, so if they don't function without their own DNS that's OK by me.
Of course once you finish one youtube video it switches to a "you might want to watch next" which is not the educational content I want them on.
https://gist.github.com/ndriscoll/2f1c98a125c0d4a4f6f993e077...
The event listener might have an annoying perf impact, and if the sites with the embed don't use javascript to build the page, you might be able to leave it off.
For another, some implementations thought they understood name constraints, but had bugs in their implementations. For example, applying name constraints correctly to the certificate's Subject Alternate Name but not applying them to the Common Name.
Like others I went with just having my own domain and getting real certs for things.
But it's long been stuck in a cycle of "CAs won't issue name-constrained certificates because not all clients support it properly" and "Clients don't bother to support it properly because CAs won't issue name-constrained certificates"
And even if today's clients all support it properly - there will always be some users running ancient smart TVs and android phones that haven't received a software update in a decade.
It looks like support is fairly wide now, but you'd probably still need to test and confirm it works with all the tools you want, and there's still some risk to users in case the constraints don't catch everything.
What is the threat model in which an attacker could MitM your internal network?
Police raid on your home/company. Malware on a router. Malicious actor in the server room. Possibilities are endless.
SSL added and removed here ;-)
(this is a reference, look it up if you don't recognize it)
It doesn't even have to be on the router, just the same network segment plus some ARP spoofing tricks (assuming your switch doesn't have ARP spoofing protections or they haven't been enabled) could be enough to MitM a connection.
If you have physical access, TLS isn't much protection against eavesdropping. At that point they can just compromise your hardware instead.
* Browsers will display annoying warning symbols whenever you try to access sites via HTTP.
* If you live in a shared living space such as an apartment you probably don't have control over your home network.
* Even if you have control over your network, a single compromised IoT device is enough to sniff your internal network traffic, assuming WPA2. (Probably not super likely tbh.)
Browsers could stop with their false warnings about password forms being insecure then I'd be happy.
If you have guests in your network, surely they have a different level fo trust.
Anyway: If you trust _all_ devices on your network (including routers, PCs, phones, printers, light bulbs, air conditioners, thermostats, doorbells, scales, TVs, set-top boxes, coffee machines), and the software running on them to be bug-free, unrootkited unhackable, and upt-to-date, and their vendors to be perfectly honest and reliable, and those ones' employees, hardware, and software supply chain to be perfectly trustworthy, forever, then yes, you don't need any form of cryptography in your network.
Otherwise, you need something like TLS for it to be secure.
Using fullest in the context of 'lives life to the fullest' is grammatically correct but English is strange and for this context you'd want the former.
Has everything, except the nigh to impossible DNSSEC-support for LAN; good stuff, nonetheless.
It would be great to be able to get a certificate for an intermediary CA, that is limited to one domain. And then use this CA to issue certs as needed.
Devices would treat .internal as special and would validate that the hinted CA only applied to that subdomain, and would only use that CA when connected to the corresponding network.
Or maybe the DHCP/RA could hint at keys to use to validate DNSSEC for the internal DNS server, and the CA cert could live in a well-known TXT record…
Then you could have all devices work with internal certs out of the box with no config. One can dream…
so why wouldn't something like this work:
- designate sub domain for private network usage (ie, *.internal.example.dev)
- issue certificates using ACME compatible script/program (ie, lego) for devices (ie, dev1.internal.example.dev, dev2.internal.example.dev)
don't have to deal with adding self signed certs to trust stores on devices. don't have to deal with messiness of name constraints compatibilities across apps. just plain ole TLS
I'd rather see something with 90 days and ACME. Note sure why there isn't a simple certificate management tool that does this and maybe even brings a simple UI?