41–50 of 75 posts
Earlier quoted context omitted.
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.
I don't think that will work on an end-user device though, right?
> 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 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 exact…
> 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.…
This seems like the most reasonable approach given that the need for HTTPS certificates arises from public accessibility.
> 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.…
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.
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.
> 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 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.
Earlier quoted context omitted.
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.
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 c…
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).
Earlier quoted context omitted.
Not sure why I’m trying downvoted. Maybe the mere mention of pedophelia disgusts people. This is a real threat, but honestly I’m not concerned... and I have a toddler in a facility that uses a system like this (not the same one).
I have a toddler in a facility too. But I'm not at all convinced that this is a real threat. I'm having trouble even imagining it as a theoretical threat. Pedophiles are bad for sure. But internet people watching nursery footage doesn't seem to make that any better or worse. I expect roughly all of nursery footage to be uniformly boring. Even if a pedophile got access to it... then what? Where's the threat?
On average, yeah, nothing bad will happen. But that’s true for someone leaving their front door unlocked too. Eventually you are likely to get fucked.
Earlier quoted context omitted.
I have a toddler in a facility too. But I'm not at all convinced that this is a real threat. I'm having trouble even imagining it as a theoretical threat. Pedophiles are bad for sure. But internet people watching nursery footage doesn't seem to make that any better or worse. I expect roughly all of nursery footage to be uniformly boring. Even if a pedophile got access to it... then what? Where's the threat?
They get attached to specific kids and grab them in the park after they see the kids are getting ready for their daily trip? On average, yeah, nothing bad will happen. But that’s true for someone leaving their front door unlocked too. Eventually you are likely to get fucked.
Earlier quoted context omitted.
> - 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 exact…
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.