[mleonhard]

> To make matters worse, the connection to the DVR is using HTTP, not HTTPS. It is unencrypted, allowing someone to eavesdrop on the video feed, username, and password.

What is the proper way to provide certificates to devices with embedded servers?

- Generate a self-signed certificate with the appropriate IP address and train users to bypass the browser's scary warnings?

- Buy certificates for every deployed device. Make each device download a new certificate when its current one expires. Set up dynamic DNS so the user can reach the device at a URL that matches the certificate.

- Make the device use an ACME server to provision its certificate. The device must be publicly accessible so the ACME server can reach it.

- Proxy all device connections through a central server. This could be expensive for high-bandwidth uses like streaming video.

All of these options are poor. Why has nobody solved this problem? Is it because the powerful browser makers (first Microsoft and now Google) prefer lucrative centralized technology? Google will make a lot less money when everyone can easily run their own server to do shared docs and messaging. Or is it because IoT companies prefer centralization so they can sell subscriptions to users and gather user behavior data? Or is it just that nobody has put in enough effort to solve it yet?

[AdamJacobMuller]

> - Make the device use an ACME server to provision its certificate. The device must be publicly accessible so the ACME server can reach it.

Not really. The most common challenge is DNS which doesn't require the ACME servers to be able to connect to the subject via HTTPs.

Probably the gold standard for how to do this is how Plex implemented it: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

Not exactly trivial but definitely not impossible.

[stefan_]

As the Plex docs notice, this is still broken: if your DNS server filters local network IP addresses as a form of some voodoo DNS rebinding "protection", this doesn't work.

[AdamJacobMuller]

Still the best way of doing it IMO, even if not perfect.

And, this wouldn't affect this situation, since, you're doing it with external IPs for external clients.

[Demigod33]

Don't embedded devices fix the DNS-server to a specific one? Worst case the provider fixes it to their own. That has downsides too though.

[AdamJacobMuller]

The DNS queries in question are on the clients, not on the server.

[kccqzy]

> Proxy all device connections through a central server. This could be expensive for high-bandwidth uses like streaming video.

The central server doesn't need to proxy the actual data stream. There are plenty of peer-to-peer video implementations that only require a central server for signaling and connection establishment.

[tgsovlerkhgsel]

> - Make the device use an ACME server to provision its certificate. The device must be publicly accessible so the ACME server can reach it.

This seems like the most reasonable approach given that the need for HTTPS certificates arises from public accessibility.

[stefan_]

Certificates arise from authentication. What does any part of it have to do with public accessibility? I can share GPG keys with my friend by printing them, but when it's a certificate I should really get it validated by Egypt Mubarak CA services, TurkTrust or RussiaRSA?

[tgsovlerkhgsel]

You should get it validated by Let's Encrypt so that the warning goes away.

The reality is that you either push the button (get the key certified), or bad things happen (users get warnings and - for the average user - simply can't use encryption). Pushing the button also doesn't have significant negative effects, and while you can lament alternative proposals at length, there is _some_ reason behind the status quo.

So you should push the button.

[londons_explore]

Issue a proper HTTPS certificate for each DVR. Do it with the DNS validation method, so the DVR company can set up the necessary DNS TXT records to obtain the certificate, and then the device can retrieve that certificate and use it.

Set the DNS A record to either be a publicly routable IP (if UPnP has worked) or to a local IP (if It didn't).

Sure, an internet connection is required. But most users have that. Now all users get HTTPS with no custom setup required.

All users can now connect to https://bobsdvr.dvrcompany.com/ from inside their wifi and see their DVR. If UPnP or port forwarding has worked, they can visit https://bobsdvr.dvrcompany.com:1234/ from outside and it works too.

If all this is too much complexity for the users, you can still run a proxy server for the low volume traffic (status pages, etc.), and use the above method behind the scenes for the expensive video feeds. This has the benefit you can show a proper "Your DVR is offline" message rather than a generic error page.

[jjav]

> Sure, an internet connection is required.

It's much worse than that. The existence of the company and their servers is required. So when those disappear, the customer-owned hardware is bricked? No thanks.

No customer-owned hardware should ever depend on the continued existence of the company that sold it.

[londons_explore]

> So when those disappear, the customer-owned hardware is bricked? No thanks.

Yes please. If the company that developed some consumer networked hardware goes away, I don't want botnets of that hardware sending spam...

Software updates for security are now the norm for internet connected things, and if a piece of hardware can't be supported anymore, it will probably be exploited and siphon your private data to the highest bidder. It's far better to disable unsupportable hardware than keep using it.

If companies going bankrupt starts harming consumers, government could step in and force companies to contribute to a "support fund" for continued support of their hardware after bankruptcy if necessary.

[LocalH]

Thank you for advocating for the continued erosion of user rights with regards to hardware they own. How about we stop tethering devices to manufacturer servers and reserve that for optional, over-the-top features?

[alisonkisk]

The right to swing your fist ends at my nose.

Internet connectivity is an optional over the top feature. You don't deserve the right to be on the shared public internet using a computer someone else made if you can't be cut off for antisocial behavior.

You can make your hardware from raw components if you want.

[LocalH]

That's a pendulum that swings both ways, however. Disabling a manufacturer's entire fleet of product when they go out of business is a little bit far on that scale, IMO. Like you said, the right to swing your fist ends at my nose.

That's why I said "how about we stop tethering devices to manufacturer servers" implying that their basic functionality should always be standalone. Why should we be increasing long-term waste by bricking such products?

[userbinator]

I'll go with the first one, because it is as you said: the authoritarian security industry, and the corporate types in general, love centralised control, and HTTPS-everywhere is their attempt at grabbing more of it.

Honestly, as another commenter here noted, I don't think this is that big of a problem --- and is comparable to all the other open webcams out there.

[thayne]

Another option is you could use dynamic DNS on subdomains you control for the devices, then use ACME to provision certificates for those subdomains, and then have the DVR devices fetch the certificate for itself over a secure and authenticated channel.

> The device must be publicly accessible so the ACME server can reach it.

My understanding is that these devices are publicly accessible so that parents can access the DVR without being on the local network.

[bombcar]

What I do is request a wildcard cert from Let's Encrypt on one of my public-facing servers, and then copy that to all my other machines.

[Wowfunhappy]

I don't think that will work on an end-user device though, right?

[technion]

It'll "work" but the cert will be considered compromised as soon as an end user pulls the device apart and obtains it.

[Wowfunhappy]

Right, so I'd count that as "not working." :)

[bombcar]

Ah I see that the request was for a "generic" SSL cert for all router.lan type addresses - not your particular install of such a beast.

[Wowfunhappy]

Putting aside all of NurseryCam's other security issues for a moment, I do think using http is reasonable under the circumstances, perhaps with an option to enable https via a self-signed cert (or a user-provided cert) for advanced users. This is the approach taken by basically every router.

[stefan_]

HTTP is an unhappy medium, just like an Open WiFi: we could have perfect forward secrecy encryption alone, but instead we have to choose between "no encryption, no authentication" and "encryption and authentication".

Now we would still like both of course but as the GP correctly states, Google et al have no interest in any of that. They are much better off when both the device and the app just connect to the vendor cloud where they can happily vacuum data. Local network is a not use case at all.

[Wowfunhappy]

I think we're saying the same thing—it would be good if such a standard existed, but it doesn't. So of the available options, simply settling for http seems like the most reasonable to me.

The only real alternative I can think of is to make the entire device dependent on a cloud service of some sort. Which IMO would be clearly worse for a whole host of reasons (among them, now your device is useless if that service goes down).

[thayne]

https without certificate verification still leaves you vulnerable to MITM, as long as the attacker can intercept, and manipulate, the session negotiation. However, I do think there is value in a trust-on-first-use (TOFU) model for trusting self-signed certificates. The biggest challenge is how to educate users on when it would be appropriate to accept the risks of TOFU.

[PurpleFoxy]

This kind of highlights the problem with these kinds of products. They are extremely difficult to do properly and expose the user to quite a lot of danger. Really we should be settling for “well it is quite hard so we will let these faults pass”. The product should simply not be allowed to be sold if it can not be done properly.