Most active commenters
  • ndsipa_pomu(3)

←back to thread

Just want simple TLS for your .internal network?

(github.com)
246 points nh2 | 23 comments | 18 Oct 24 06:10 UTC | HN request time: 1.475s | source | bottom
Show context
ndsipa_pomu ◴[22 Oct 24 08:36 UTC] No.41912342[source]▶
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): >>41912368 #>>41912827 #>>41913126 #>>41913387 #>>41913720 #>>41913826 #>>41916306 #>>41917079 #>>41917804 #
1. DandyDev ◴[22 Oct 24 08:42 UTC] No.41912368[source]▶
I do this as well, but be aware that these external names you're using for internal devices become a matter of public record this way. If that's okay for you (it is for me), then this is a good solution. The advantage is also that you run no risk of name clashes because you actually own the domain
replies(7): >>41912424 #>>41912505 #>>41912544 #>>41912570 #>>41912671 #>>41912732 #>>41919325 #
2. xfer ◴[22 Oct 24 08:53 UTC] No.41912424[source]▶
Or use a wildcard cert for all internal certs.
replies(3): >>41912563 #>>41912669 #>>41912935 #
3. magicalhippo ◴[22 Oct 24 09:08 UTC] No.41912505[source]▶
I decided to try split DNS to avoid leaking the internal IPs, but it turned out a bit more fragile than I imagined.

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.

replies(2): >>41912693 #>>41913504 #
4. ndsipa_pomu ◴[22 Oct 24 09:15 UTC] No.41912544[source]▶
> be aware that these external names you're using for internal devices become a matter of public record this way

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.

replies(3): >>41912767 #>>41912874 #>>41922694 #
5. ndsipa_pomu ◴[22 Oct 24 09:18 UTC] No.41912563[source]▶
That could be a good idea, though it means that the certificate/key has to be well guarded.
6. ◴[22 Oct 24 09:19 UTC] No.41912570[source]▶
7. project2501a ◴[22 Oct 24 09:38 UTC] No.41912669[source]▶
Please don't. Technical debt accumulates by force of practice.
replies(1): >>41912757 #
8. prmoustache ◴[22 Oct 24 09:38 UTC] No.41912671[source]▶
you can use a wildcard of type *.internal.example.com or use names that do not relate to the service name if you want to obfuscate the tech stack used.

The only thing public is that you may have an internal network with nodes.

9. Hamuko ◴[22 Oct 24 09:43 UTC] No.41912693[source]▶
I use CNAME records and it works on everything except Windows, where it works sometimes.

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.

replies(1): >>41914430 #
10. Eikon ◴[22 Oct 24 09:51 UTC] No.41912732[source]▶
Shameless plug:

https://www.merklemap.com/

11. qwertox ◴[22 Oct 24 09:55 UTC] No.41912757{3}[source]▶
It's working good for me. My technical debt is to always make sure that I'm able to renew a certificate and that the distribution occurs successfully.

I don't see how other solutions are less problematic.

12. qwertox ◴[22 Oct 24 09:57 UTC] No.41912767[source]▶
You don't need to publish the IP addresses publicly if you use an internal DNS server. I think even Pi-hole could do this.
13. dspillett ◴[22 Oct 24 10:19 UTC] No.41912874[source]▶
> If someone is trying to infiltrate my home network

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.

replies(1): >>41913199 #
14. pridkett ◴[22 Oct 24 10:30 UTC] No.41912935[source]▶
This is exactly what I do. After seeing how much of my internal network was exposed in certificate transparency logs, I noped out and just do a DNS challenge for a wildcard for almost everything.

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.

replies(1): >>41914833 #
15. xena ◴[22 Oct 24 11:23 UTC] No.41913199{3}[source]▶
That's why you have an internal domain that's not related to the company. Something like "packet-flinging.ninja". Everything's a tradeoff though.
replies(1): >>41914129 #
16. capitol_ ◴[22 Oct 24 12:17 UTC] No.41913504[source]▶
Split DNS causes lots headaches, it also makes it really hard to root cause analysis of failures when they involve DNS.
17. deltaburnt ◴[22 Oct 24 13:37 UTC] No.41914129{4}[source]▶
It seems really easy to associate a company with its internal domain though? Unless the company treats it as a secret only known between machines.
replies(1): >>41917487 #
18. ebb_earl_co ◴[22 Oct 24 14:06 UTC] No.41914430{3}[source]▶
This seems like a good technique. What DNS software do you use?
replies(1): >>41914479 #
19. Hamuko ◴[22 Oct 24 14:10 UTC] No.41914479{4}[source]▶
I just use the one built into my UniFi router. Public DNS side is Cloudflare, which allows easy DNS validation for Let's Encrypt.
20. dopp0 ◴[22 Oct 24 14:45 UTC] No.41914833{3}[source]▶
> fairly robust DNS setup that consists of not only giving A records to all my hosts

looks nice, can you give more details on this? tks!

21. dspillett ◴[22 Oct 24 18:57 UTC] No.41917487{5}[source]▶
> It seems really easy to associate a company with its internal domain though?

Especially as people will talk about it as a “you'll never guess what…” when talking about places they work or have worked.

22. js2 ◴[22 Oct 24 22:20 UTC] No.41919325[source]▶
Using a wildcard cert doesn't leak anything much. I went with `*.home.example.com` for my internal stuff.
23. GoblinSlayer ◴[23 Oct 24 07:29 UTC] No.41922694[source]▶
If your services work through http(s), they can be accessed from your browser.