> "I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security."
How about what Plex did for its self-hosted media servers?
"First they solved the problem of servers not having a ___domain name or a stable IP (they are mostly reached via bare dynamic IPs or even local IPs) by setting up a dynamic DNS space under plex.direct"
"Then they partnered with Digicert to issue a wildcard certificate for *.HASH.plex.direct to each user, where HASH is - I guess - a hash of the user or server name/id."
"This way when a server first starts it asks for its wildcard certificate to be issued (which happened almost instantly for me) and then the client, instead of connecting to http://1.2.3.4:32400, connects to https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct... which resolves to the same IP, but with a ___domain name that matches the certificate that the server (and only that server, because of the hash) holds."
That's very cool, but it still requires a working and reliable internet connection.
Also these ultra-long URLs are very clumsy and can't really be used directly, so you need to have some sort of cloud frontend that where the device phones home in order to announce its LAN IP, then the user can go through there in order to connect to their LAN devices.
For something like Plex it makes a lot of sense since you're probably going to have an internet connection when you use it anyway, but for my devices it's a deal breaker.
And at any rate, that's a whole lot of infrastructure just to be able to expose a simple web interface.
Yes, why don't we come up with an extremely elaborate scheme to issue more or less faux certificates to these devices that still breaks in practice because it looks like DNS rebinding and requires an internet connection for the device and some VC funded service on the other end in perpetuity for correct operation?
Ultimately, the question is why the fuck my browser needs TurkTrust, Saudi CA or others to authenticate the device when I could do that right fucking now by turning it over and reading a label. No 3rd parties required.
But this requires the manufacturer of the IoT device to provide a central service like Plex does.
Maybe they can't afford it, or the device is expected to run for a very long time, like even after the manufacturer goes out of business. Or as some other commenters have said, it's a personal / hobby project and the "manufacturer" doesn't have the means nor the will to maintain some outside management server.
How about what Plex did for its self-hosted media servers?
"First they solved the problem of servers not having a ___domain name or a stable IP (they are mostly reached via bare dynamic IPs or even local IPs) by setting up a dynamic DNS space under plex.direct"
"Then they partnered with Digicert to issue a wildcard certificate for *.HASH.plex.direct to each user, where HASH is - I guess - a hash of the user or server name/id."
"This way when a server first starts it asks for its wildcard certificate to be issued (which happened almost instantly for me) and then the client, instead of connecting to http://1.2.3.4:32400, connects to https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct... which resolves to the same IP, but with a ___domain name that matches the certificate that the server (and only that server, because of the hash) holds."
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...