4 ms·

Oh yes. I talk greatly about that on my blog, crankylinuxuser.net All in all, there are open standards in which IoT devices could communicate: MQTT(mosquitto),

by kefka 11y ago

Oh yes. I talk greatly about that on my blog, crankylinuxuser.net All in all, there are open standards in which IoT devices could communicate: MQTT(mosquitto), CoAP(Californium), AMQP(rabbitMQ) to name a few. Yet, none of the major vendors will touch these technology stacks, precisely because of lock-in to their special-snowflake database servers. There are solutions, of which only 1 is palatable. 1. Don't buy. (Dumb house, but at least you control it.) 2. Only buy company offerings that support the above standards. (Good luck.) 3. Build it yourself. I'm going down the path of "Do it yourself." I already have a gateway controller acquiring data from sensors and sending data to things like wirelessly connected Neopixels (ws2811 strands). The radio I'm using is a mesh network chip called nRF24L01+ and the Arduino library is MySensors. Things just work, and work well. I have data dumping into a MQTT Mosquitto instance and processing logic resides in Node-Red. The other part of the Corporate "We hold your data" policy is the main reason they give: so you can control your devices from anywhere. Sounds great. Our solutions are to use things like No-IP.org , but you end up with a max 4 device limit. Not to mention, they also have a draconian ToS. So what else can you use? TOR. ..? What? The essence is that you install TOR on your machine, and edit the /etc/tor/torrc and turn on a hidden service to SSH and HTTPS. Reconfigure Node-Red to use self-signed certs and enable authentication. Now you have access to the GUI to create flows as well as webpages within the flow. I have a nice discussion how to do everything from hardware on up here: https://crankylinuxuser.net/2015/10/17/so-you-wanna-iot-a-howto-on-internet-of-things-1-of-many/ https://crankylinuxuser.net/2015/10/17/so-you-wanna-iot-a-ho... https://crankylinuxuser.net/2016/01/05/so-you-wanna-iot-a-howto-on-internet-of-things-2-of/ https://crankylinuxuser.net/2016/01/05/so-you-wanna-iot-a-ho... But in a nutshell, TOR isn't just for anonymizing, secure internet. It's also great for punching holes in firewalls and NATs and stuff to provide a service anyone can get to. Just be smart about it, secure the open ports down, and keep your onion site hidden as well. I've been railed against before for my unpopular opinions regarding this topic. But things are only going to get worse with every company who decides to reinvent the wheel, so they can have your data. And not to mention pilfering your data, does the idea of "No Internet, no House automation" sound like a good idea?

throwaway7767 11y ago
All good points (though to me, option 1 is more preferable to option 3 :) I'd like to point out, if you're not aware already, that tor additionally supports authentication for hidden services on the network layer. You can put a "HidServAuth" line in your torrc, which will then create a key line you must place into your clients torrc. Only clients with the key can connect to the hidden service. You could use that either in place of or in addition to bespoke web app auth and SSL. That way you also prevent people enumerating tor hidden services from knowing what's running behind your service.
- kefka 11y ago
  Oh, of course option 1 is the most palatable, until everyone gets their shit together regarding standards. No, I know I'm going down the "Here ye be dragons" path of making my own IoT infrastructure. It's been one hell of a wild ride, seeing this and that offering, and how they fall flat on 'If internet is down, you have a doorstop'. I show people at the hackerspace and other tech groups, and they really see value in it. I'll certainly have to look into the HidServAuth option. However, I've been watching to see if Ca.Cert is going to get off their collective asses and revoke the "Only EV2 certs can be provided for .onion addresses" rule. My biggest problem with certs on .onion is that they fail to work. Ideally, I want a LetsEncrypt cert on all of my services (Node-Red, Mosquitto via MQTTSSL, email). And just be done with it. I'm certainly trying an orthogonal way of setting up IoT vs the Corporate way of remote data centers and oppressive data handling techniques. :)
pjc50 11y ago
I favour (1) myself, being happy to walk across the house and press a button whenever I'm excessively hot or cold, but I like your idea about putting the house as a Tor hidden service. Are these "enumerable" or scannable? (like people scan the IPv4 range looking for targets)
- kefka 11y ago
  At the most unidea circumstances, you can scan the whole space of "{16 alphanumeric characters}.onion" at a space of 36^16 or around 7x10^24 addresses. That's not feasible. The other attack I've seen is turning on HSDir flag in /etc/tor/torrc and then logging all hidden service descriptors you receive. This method is obviously passive, but it does get the job done according to : http://donncha.is/2013/05/trawling-tor-hidden-services/ http://donncha.is/2013/05/trawling-tor-hidden-services/ Admittedly, I'm relying on my hash.onion for a security via obscurity. And I'm OK with that. Because behind that obscurity is key based ssh and a Node-red configured with https and authentication. Obscurity can be an effective part of overall security, as it lowers the surface area of attack.

by kefka 11y ago

throwaway7767 11y ago

All good points (though to me, option 1 is more preferable to option 3 :) I'd like to point out, if you're not aware already, that tor additionally supports authentication for hidden services on the network layer. You can put a "HidServAuth" line in your torrc, which will then create a key line you must place into your clients torrc. Only clients with the key can connect to the hidden service. You could use that either in place of or in addition to bespoke web app auth and SSL. That way you also prevent people enumerating tor hidden services from knowing what's running behind your service.

kefka 11y ago
Oh, of course option 1 is the most palatable, until everyone gets their shit together regarding standards. No, I know I'm going down the "Here ye be dragons" path of making my own IoT infrastructure. It's been one hell of a wild ride, seeing this and that offering, and how they fall flat on 'If internet is down, you have a doorstop'. I show people at the hackerspace and other tech groups, and they really see value in it. I'll certainly have to look into the HidServAuth option. However, I've been watching to see if Ca.Cert is going to get off their collective asses and revoke the "Only EV2 certs can be provided for .onion addresses" rule. My biggest problem with certs on .onion is that they fail to work. Ideally, I want a LetsEncrypt cert on all of my services (Node-Red, Mosquitto via MQTTSSL, email). And just be done with it. I'm certainly trying an orthogonal way of setting up IoT vs the Corporate way of remote data centers and oppressive data handling techniques. :)

pjc50 11y ago

I favour (1) myself, being happy to walk across the house and press a button whenever I'm excessively hot or cold, but I like your idea about putting the house as a Tor hidden service. Are these "enumerable" or scannable? (like people scan the IPv4 range looking for targets)

kefka 11y ago
At the most unidea circumstances, you can scan the whole space of "{16 alphanumeric characters}.onion" at a space of 36^16 or around 7x10^24 addresses. That's not feasible. The other attack I've seen is turning on HSDir flag in /etc/tor/torrc and then logging all hidden service descriptors you receive. This method is obviously passive, but it does get the job done according to : http://donncha.is/2013/05/trawling-tor-hidden-services/ http://donncha.is/2013/05/trawling-tor-hidden-services/ Admittedly, I'm relying on my hash.onion for a security via obscurity. And I'm OK with that. Because behind that obscurity is key based ssh and a Node-red configured with https and authentication. Obscurity can be an effective part of overall security, as it lowers the surface area of attack.