Ask HN: Is it time for a home network TLD with TLS?

15 points by CaptainJustin 4 years ago | 13 comments

Just watching Jeff Gerling's video on home automation and it struck me:

If we want to simplify accessing things with IP addresses we use DNS. If we want encryption at transit we use TLS. Is it time for the tech community to make having a domain name for home networks with proper TLS on everything more trivial? I've achieved something like this with Nginx-Ingress, LetsEncrypt, DNS and NAT but that's a little too involved for the average home. Is it time to "Dropbox" home DNS and TLS?

patwoz 4 years ago |

I'm using Tailscale HTTPS for that

https://tailscale.com/kb/1153/enabling-https/

eternityforest 4 years ago |

Yes, it is 100% time fot that.

Mozilla FlyWeb was close, but didn't handle remote access. It could have been extended to, but they dropped it.

I wrote a proposal here for how this could be done with Bluetooth-like pairing, using URLs that embed a certificate hash, a random sequence as an extra security layer, and a lookup URL that one can ask where to find the host for a service, for access over the WAN.

By using a URL instead of normal non-HTTP DNS, the lookup URL can be another web service self hosted using the same TLD, or a Data URI if one is hosting from a static IP.

No part of the URL besides the key is used to determine the origin for CORS and local storage, so you can change discovery methods and the random string freely.

Initial connection is by directly sending a link, or by LAN discovery.

Unless discovery is enabled and you are on the same network, it should be impossible to connect without already knowing the URL, so even if your home automation hub is very badly coded, they can't even start hacking it till they find your URL, which can't be found just by sniffing(Because of that random string).

Clients track the "last seen" address of servers, so even if lookup goes down, access still works until your home IP changes.

When nodes connect over LAN, the server sends it's "Find me on the WAN at" IP. So even with no discovery server at all and no static IP, it creates a very convincing illusion of "just working" 99% of the time.

Which means that if you buy a device that uses a cloud lookup service, and they drop that service, your device will still be remote accessible, most of the time. Which might be good enough, or at least good enough to get by until you can find a more permanent solution.

Proposal:

https://github.com/WICG/proposals/issues/43

And a partial implementation of a very close version(Lookups always use OpenDHT in this), plus a notetaking app based on it.

https://github.com/EternityForest/hardlinep2p

I really think this is one of those critical missing technologies that would really enable a lot of amazing things.

samwillis 4 years ago |

Well there is already .local, so I suppose what you are asking for is a simple way to do TLS with .local?

I’m not well enough versed in TLS and certs, I assume a wild card self cert for .local is a bad idea?

https://en.m.wikipedia.org/wiki/.local

nonameiguess 4 years ago | |

Link-local mDNS only works within a single broadcast domain, and a single home LAN can have many broadcast domains. The ask here is to have a reserved TLD that can be resolved by an actual DNS server, but only locally, and that public CAs will recognize as a valid TLD.

Many home router software right now that includes a DNS server will automatically add .localdomain entries for all hosts on that router's LAN, but I think the issue is public CAs won't issue you a cert for something like "wiki.localdomain" because many people would be asking for the same name, so you're forced to stand up your own CA and add it to the thousand different trust stores that all applications on all of your devices use.

It'd be nice to have a TLD in which no one can ever own the names, so many people can be issued the exact same certificate, with a guarantee that no resolver will ever go beyond its own LAN to return an address.

toast0 4 years ago | | |

> guarantee that no resolver will ever go beyond its own LAN to return an address.

How do you define that boundary, when it's not the broadcast domain. Even if it is the broadcast domain, I'm not sure that makes a reasonable boundary for people at a coffeehouse, etc.

If there's consensus that for some domain, certificates don't actually mean anything, because anyone can get a CA to issue it, there should also be consensus to accept self-signed certificates for that domain.

ryandrake 4 years ago | |

I thought .home.arpa[1] was the preferred TLD for internal residential home networks now, not .local

I use my own CA root and individual certificates for each of my internal machines that use TLS.

1: https://datatracker.ietf.org/doc/html/rfc8375

PaulHoule 4 years ago |

Are you talking about the scenario of communications inside the home or from the outside world to the home or both?

CaptainJustin 4 years ago | |

Exclusively within the home network

Jaruzel 4 years ago | | |

I'm going to get flamed for this... but why would you need TLS/https on services that are ONLY accessible from inside your home network? If you have bad actors on your network, you've got bigger problems than un-secure websites.

Anyhoo, if you must, then roll your own CA, get it to generate certs, put the CAs root certs on your clients, and you should be good to go. This route also means you can have something like .myhouse as your TLD if you so wished.

PaulHoule 4 years ago | | |

I have thought about the right way to do local DNS for my home network, one that works without a lot of trouble on different desktop OS, tablets, game consoles, etc.

I am afraid that one day web browsers won't let you visit something like

   http://10.6.28.128/

which is the kind of URL I visit to see the "control console" for my smart home and other services on my home server.

bryan_w 4 years ago |

Maybe like a dhcp option to point to a "self-signed" CA cert for use exclusively on that network

aseipp 4 years ago |

I'm not sure you can trivially "dropbox" TLS because unlike dropbox, every application you use TLS certificates with needs to be aware of how to load and find and (potentially) acquire/renew them in the first place. Unless you are going to "dropbox" literally every TLS-enabled FOSS app you could want to run, and automate their deployment and renewal. Or you could centralize on a tool like like stunnel to literally terminate all TLS connections but this comes with its own flaws (e.g. annoying protocols like IMAP upgrade the connection from plaintext to TLS "in situ" via STARTTLS.) But if you just use a single TLS terminator and wrote some glue for it, sure, it might work for a reasonable amount of stuff. "Dropboxing" the whole stack is basically just another way of saying "I am going to make a turnkey software appliance" and most people won't want it.

Someone else proposed things like DHCP servers announcing a local CA and self-signing. Aside from circling around to where you started at (how do you know the DHCP server is not hostile a priori without landing back at stage 1?) it would also require massive extensions to all kinds of software to work. You're going to get pushback on this without extremely good reasons, even if it wasn't a shitload of work, so it's practically unviable. (Alternatively you have people who actually believe things like "Just typing in a 40-character base64 pubkey is _obviously_ the solution" or whatever when most people just want a nice fun hostname for themselves.)

Here's what I do. Just put your local (firewalled) network IPs in an set of records on a zone you own, and then use LetsEncrypt's DNS challenges to issue a cert for them. Then put the cert where-ever you want. Done.

e.g. enter an A record for service1.a-domain-i-own.dev that points to 192.168.1.XXX (or 172.X.X.X, or 10.X.X.X, whatever) which is a local-only subnet. Issue a DNS challenge to LE for this record using whatever tool you like. It does not need to contact the service, it only needs verify a corresponding TXT record. Then you can just take the resulting certificate and put it on your router, your server under your desk, whatever. Use the domain name as usual while on your home network. Viola, you're done. This lets you piggyback of the existing public LetsEncrypt, DNS, and CA systems with minimal effort and time, and you don't need any software at the subnet level to manage anything, and even your appliances/game consoles/whatever (that can resolve DNS names and handle TLS) will work fine.

You can do all of this with Traefik today in, like, 10 lines of configuration, not a joke. You don't have to fiddle with anything at all, almost.

I use this technique on a ZeroTier network I share with many (non-technical) friends and it works completely transparently; I can just hand them a link and it's as if it was any other website, and they are oblivious to the fact it's actually "on the local subnet"