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?
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.
I’m not well enough versed in TLS and certs, I assume a wild card self cert for .local is a bad idea?
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.
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.
I use my own CA root and individual certificates for each of my internal machines that use TLS.
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.
I am afraid that one day web browsers won't let you visit something like
http://10.6.28.128/
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"