Live data from Hacker News

More awful IoT stuff

mjg59.dreamwidth.org

171–180 of 245 posts

Re: More awful IoT stuff

#171

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…

This is a genuine question, and I think I've come to the opposite conclusion as you. You write: >I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. and >I also want it to be upgradeable, So let's be super-super clear. You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you…

>mom, grandmother, girlfriend,

But MEN can update things themselves, right.?

Re: More awful IoT stuff

#172
post #147

Earlier quoted context omitted.

Don't even need to make it yourself, Itead sells the Sonoff for $4.85 + S&H. It's an ESP8266 connected to a relay, with integrated AC-DC power supply and a properly designed, physically isolated PCB. Two caveats are that it doesn't directly have a USB plug. The serial header is exposed and you can reprogram the device with your own firmware to make it report whatever you like, but you do need a USB-Serial cable and m…

This is exactly what I've been looking for. Where can I pick up some cheap adapters to get an outlet on one end and male plug on the other?

Get a power strip and a electrical enclosure from the hardware store or you can get a replacement appliance cord+wall outlet+electrical box. Also get a outlet wiring tester to make sure you wired it correctly (eg: didn't get hot/neutral/ground mixed up)

Make sure to put a 10A fuse in series, use wire rated for 10A and pass the ground wire through.

Re: More awful IoT stuff

#173
post #130

Earlier quoted context omitted.

I think you nailed it: hackers don't want to write blog posts saying "damn, this thing was pretty well made". Perhaps an open-source effort to document & track what work has been done, even if it's just pulling firmware images and taking a look around. Maybe some kind of gamification to motivate researchers to pull things apart and report what they see.

It's not just that people don't want to write about it, it's that people don't want to read it either. You'd never see a post on the front page of HN about how IoT device X was well designed and is generally secure, but you see (and will continue to see) them top out about how awful they are. Just look at this thread. Half the answers to "what are some good IoT devices" is "lol there aren't any"... The HN crowd doesn…

People don't want to read it, otherwise the front page of HN would be carpeted with astroturfed 5 star reviews of bad products. (See also: most Amazon reviews)

Re: More awful IoT stuff

#174

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…

We're working toward some IoT developer products designed to allow global p2p connectivity for IoT devices over networks the user can control: https://www.zerotier.com/

ZeroTier already runs fine on embedded Linux, which is a large subset of IoT, and we've researched a lightweight port to FreeRTOS.

Re: More awful IoT stuff

#175

Earlier quoted context omitted.

It's absurd that an IoT device contacts a server hundreds of miles away when I'm inside my house turning on my lights via wifi.

Apparently this is kind of a hard thing to handle. I battle with this and PS4 Remote Play -- about 80% of the time, RP will give up looking on my local network and go out to the internet to find my PS4... which is right here on the same network. If I cancel it and retry a few times it always ends up seeing it but man what a pain.

We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4.

"Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken.

Here are some of the characteristics that would label a network as endpoint hostile:

- "Device isolation," which prohibits local LAN device communication. This is common on some WiFi networks. It's forgivable on a public WiFi but not elsewhere.

- Symmetric NAT

- Multiple levels of nested NAT e.g. consumer routers plugged into consumer routers. It's important to note that this makes everything flaky due to weird interactions and timeout behaviors. In our experience it's disturbingly common. We talked to one person whose company had at least five levels of this, requiring things like "ServerAliveInterval 10" in ssh_config.

- Lack of support for NAT hairpinning. (NAT can't NAT-traverse with itself.)

- Short NAT/firewall stateful connection timeout (120s is the RFC recommendation, but 30-60s is common and we've seen 15.)

- IPv6 absent (assuming it's available upstream) or deployed in a silly way (e.g. IPv6 NAT).

- Lack of support for local multicast or broadcast

- Aggressive edge firewall rules that prohibit UDP, non-standard TCP ports, etc. or that DPI traffic and attempt to block anything other than HTTP, SSH, and SSL.

- Badly implemented NAT ALGs for things like FTP and SIP that break other traffic.

- Lack of uPnP or NAT-PMP support.

- Mandatory proxy configuration.

- Middle boxes that modify traffic in general. This includes things that bork TCP in a misguided attempt to "optimize" it, things that inject HTTP headers (or worse JavaScript), things that modify DNS to strip A/AAAA records for "private" IPs or strip TXT records, etc.

Some of this stuff is just stupidity or brokenness, but much of it is implemented for "security" reasons.

I personally consider reliance on network edge controls for security to be a borderline-obsolete cargo cult practice, since the vast majority of today's vulnerabilities and attack vectors are unaffected by it and involve things like cloud services, e-mail, web, app updates, etc. I've worked in netsec/infosec and have seen a number of intrusions, and so far I have yet to see one in the past 10 years that was mitigated in any way by the presence of a firewall. Yet a generation of IT people thinks "firewall equals security" and I'm increasingly thinking this generation will have to just pass along.

Re: More awful IoT stuff

#176
post #115

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…

Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level. What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background…

[deleted]

Re: More awful IoT stuff

#177

Earlier quoted context omitted.

This is a genuine question, and I think I've come to the opposite conclusion as you. You write: >I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. and >I also want it to be upgradeable, So let's be super-super clear. You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you…

>mom, grandmother, girlfriend, But MEN can update things themselves, right.?

I've changed the phrasing, thanks. Men and women are enthusiastic users of technology.

Re: More awful IoT stuff

#178

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…

I'd argue that these guys are actually supplying. Just firewall it out to a specific network segment for these devices, have one box that interacts with it and modify it to your own liking, you have root on it afterall. They're dirt cheap, they work, and you get root so it's completely upgradable and hackable. Can't beat that really if you have decent security practices outside of the device. It's definitely an inves…

heh, that's actually what I kind of do now with a couple of devices. Then I ban that vlan from the internet. I'm speaking more in general though: Too many IoT devices require cloud access to work properly. I don't want to put a hacky solution together, I'd rather things would out of the box. I don't like the idea of having to be defensive against my own equipment.

Re: More awful IoT stuff

#179
The principal reason devices need to be connected is so that business can hold your devices ransom and charge you money to use them.

Turn on lights with a phone? No need for Internet.

Open doors with a fingerprint? No need for Internet.

An auto-adjusting energy-saving thermostat? No need for Internet.

A fridge that knows the milk is low? No need for Internet.

Charge people money to use their toaster? You need the Internet for that.

Re: More awful IoT stuff

#180
post #150

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be up…

I have that, based on zwave devices. Can be bought off the shelf, requires some tinkering to set up usually when you want to do something that's not trivial, but is as flexible as you want it to be. Can run on raspi, there are diy sets for it etc. Ppl bitch about zwave being 'proprietary' but it's open/documented enough to be hackable to your heart's content.

Personally, I don't want to invest into a closed platform. Hackable solutions are nice, but I've purposefully avoided zwave because they aren't open source. Maybe I'm naive, but I'm holding out for something that actually is open-source, not seems to be open source.

Having never used zwave though, it sounds like your point is valid.

Post reply on HN