Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Warning to Users of NurseryCam

cybergibbons.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: A Warning to Users of NurseryCam

#31

Post by PurpleFoxy »

mleonhard wrote: post #30

> 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 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.

Re: A Warning to Users of NurseryCam

#32

Post by userbinator »

mleonhard wrote: post #30

> 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.…

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.

Re: A Warning to Users of NurseryCam

#33

Post by kccqzy »

mleonhard wrote: post #30

> 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.…

> 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.

Re: A Warning to Users of NurseryCam

#34

Post by recursive »

TedDoesntTalk wrote: post #27
TedDoesntTalk wrote: post #18

Earlier quoted context omitted.

> Out of curiosity, why is viewing nursery footage seen as serious? pedophiles can view/record naked infants and toddlers with relative ease.

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?

Re: A Warning to Users of NurseryCam

#35

Post by recursive »

YeBanKo wrote: post #29
jowsie wrote: post #11

Earlier quoted context omitted.

This is a system sold to commercial nurseries, not installed in peoples homes.

Yeah, and in this commercial nurseries children spend a good amount of time. So its their second bedroom.

I don't understand that at all. If I spend a lot of time at Starbucks, is that my second bedroom? Why are other people using the bathroom attached to my bedroom?

Re: A Warning to Users of NurseryCam

#36

Post by bombcar »

mleonhard wrote: post #30

> 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.…

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.

Re: A Warning to Users of NurseryCam

#37

Post by [deleted] »

KaiserPro wrote: post #2

The whole saga is just utterly insane. Its the same people who shipped the "people counting" raspberry pi system with the bruno mars mp3s in them. First they try and report the security consultants to the police, then they claim that they are too expensive to work with. Then even more bizarrely they launch a halfarsed sock puppet campaign using the CEO's wife's account. Then they start publishing reviews on their own…

[deleted]

Re: A Warning to Users of NurseryCam

#38

Post by AdamJacobMuller »

mleonhard wrote: post #30

> 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 exactly trivial but definitely not impossible.

Re: A Warning to Users of NurseryCam

#39

Post by Wowfunhappy »

bombcar wrote: post #36
mleonhard wrote: post #30

> 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.…

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?

Re: A Warning to Users of NurseryCam

#40

Post by Wowfunhappy »

mleonhard wrote: post #30

> 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.
Post reply on HN