I develop broadcast TV equipments which are often rented all over the place for short amounts of time, often don't have any direct internet access etc...
I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation.
For network you control your solution makes a lot of sense though.
That's quite a cool hack, but as I mentioned elsewhere in this discussion it's still a lot of infrastructure to let a user connect to a device on their own lan, and it still presupposes that the user will have a robust internet connection when they need to use the device.
That makes a lot of sense for Plex, but it's really not applicable for my equipment.
Interesting. I’m currently working on an “IoT” device and this seems like it could theoretically work. One concern I have is that there’s an initial step where the device creates an access point so that you can enter wifi credentials that it will use to connect to your home network. In this case, the device connecting to the local server will not have internet access, and would not be able to resolve the plex.direct domain. Maybe I can rely on the browser dns cache, but that seems pretty sketchy...
Perhaps you could distribute an Electron style client that has a self-signed certificate pre-configured and ask your clients to interface with the equipment via that?
If you were using Electron you wouldn't have to worry about browser support either as you'd just have to target Chrome/Blink.
Just brainstorming ideas here, someone will probably shoot me down.
DNS validation can entirely be done by a server on the internet, which does all the stuff necessary to get the certificate, and then gives the certificate to your end user device.
All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.
I think the more frustrating point is that you need all this internet infrastructure (with running costs) at all - even if your device has nothing to do with the internet at all.
If the vendor of your dumb device goes out of business, you can just keep using the device until it breaks down.
If the vendor of a "smart" device - or now anything with a modern web interface - goes out of business, the device will have a broken UX at best and at worst turns into a brick 90 days later.
In the end, browsers are now a platform and you have to register and pay a subscription fee to make use of them.
> All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.
I'm no expert on long-tail use cases, but I'd imagine that most networks either have internet connectivity or they don't. I can't think of many situations where you'd only have internet once every 90 days.
Of course one could argue that 90 days long is enough so an employee could go around with a memory stick and manually copy the certificate to every device - which is theoretically possible but sounds like a ridiculous thing to do just to keep a web interface workable. (And even then, you'd somehow need a unique certificate for every device)
I can't think of many situations where you'd only have internet once every 90 days.
Having worked in broadcast news, I can think of hundreds.
News doesn't happen in the newsroom. It happens in the field. And very often in places without internet access. Sometimes for weeks or months at a time. (Think siege at Waco, plane crashes, hurricanes, etc.)
I work in broadcast news. Specifically in connectivity in the field. I can’t think of any time we’d be without some form of Internet for more than a couple of days, depending how you define China as Internet.
There’s not much point in doing broadcast news of you can’t file, and you can only file if you have an IP connection (we do have some non ip satelite but without IP you wouldn’t be able to do much in the way of production - no production system, no email, no phone)
Covering natural diaaaters is why we have bgans and generators and MREs and water cleaning kits. Internet access is as essential as any other high risk safety equipment, and there’s no point deploying if you can’t file back.
I worked in embedded radios for the broadcast industry and SCADA applications for a spell and dealt with the same problems that the GP is describing. Many of these systems are composed of networks built on top of radio modems. It is very common that these devices can't reach the Internet...
I've literally never seen anybody use a domain name to address my devices, only
a simple IPv4. That already makes it a nonstarter, but let's entertain the idea. Maybe I can convince my clients to change the way they work, they generally love that.
Just going through the trouble of having the customer mess with their OS's DNS
resolver to connect to the device is ludicrous. Can you even do it on Windows
without having to deal with the hosts file manually?
Then they need to remember to update it when the IP inevitably changes because
they've moved onto a new project with a different address plan, and they'll
invariably forget to change it or forget how to do it or do it wrong and then
call me to help them.
And on top of all that, no I can't really expect my devices to have internet
access, not even once every 60 days. It's not uncommon for broadcast operations
to use costly and critical satellite links for internet access, and they're not
going to let random devices use that without a good reason. More generally, even
if there's an internet connection available they're likely not to configure the
gateway correctly, then complain when the night of the big event their browser
refuses to connect to my equipment, saying that they're about to be h4x0r3d.
My use case is certainly a niche, but I think it's probably a significant niche
given that everything and anything has web interfaces these days. Cameras have
web interfaces for configuration, middle end smart switches and routers have web
interfaces, I've even seen power plugs with web interfaces...
There are a couple of possibilities here, given that we're talking costly and critical satellite links.
1. You set up a private PKI using a private CA. AWS will sell you one for $400/month. Install the public root in the trust stores of the clients and then issue 5 year private certs for either IP addresses, or for .local and use DNS-SD.
2. You create a private domain at private.example.com. You get letsencrypt to issue a wildcard for .private.example.com. Then you set up private DNS for that zone. Server cert needs to be updated every 90 days. That involves downloading a single PEM file from your internal network.
I don't think Let's Encrypt is going to be the right use-case for you then. I think your best bet is to work with another CA to get your company an intermediate cert that you can use to issue longer certs that include ip addresses in the SAN.
Then it's just a matter of the devices connecting to the internet at least once a year and doing a very simple "Hey, I'm $device and using $address. Issue me a cert plz."
> work with another CA to get your company an intermediate cert
I'm no expert, but wouldn't that make GP's company effectively a delegate CA? This seems like it would need a very close relationship with the original CA - and all just for a simple web interface.
> include ip addresses in the SAN.
Not sure if this may be different with intermediate certs, but you won't find any public CA that will add private IP addresses as a SAN - as this would undermine the whole security model. If any CA did this, Chrome would likely ban them quickly.
I'm sceptical a CA would let you do that with intermediate certs if there is any danger the leaf certs get into the wrong hands (e.g. because the devices are sold, someone reverse-engeneers one and manages to talk to the back-end service)
I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation.
For network you control your solution makes a lot of sense though.