To all users exposing their openHAB runtime through MQTT, please check out this talk:
A specific example of what we can see and do is a home automation system we discovered. We got a list of every sensor and its status. Furthermore, we got exact GPS coordinates from the mobile app used to control the home automation. So in this case, not only were we able to control the system, we even knew when the owner was away.
I hope that all of you are always talking care to use fully encrypted and authenticated communication, so that these guys wont mention openHAB as the “home automation system [they] discovered”!
It will be interesting to see their talk and/or read their paper. I’m not sure I can yet agree with their conclusion though.
This is an old protocol from 1999. Its fast and reliable, but its missing security.
MQTT isn’t missing security. It can be configured to be relatively secure (enable TLS, apply ACLs, etc). It’s just that those are not enabled by default and require a good deal of work to set up and maintain.
Yeah, this is also what I expect: They show that many users don’t properly secure their system. It is not that MQTT as such is flawed. But this is why I ask the community here to make sure that they alway use it safely
If you connect to the public brokers around the place (i.e. test.mosquitto.org) you will see hundreds (probably 1000’s!) of devices/people publishing sensitive data, most likely completely unaware. These test brokers are great for playing around and testing but the fact people hook up live systems shows that they really don’t understand the nature of MQTT and why they should be running their own broker!
FYI - Owntracks now supports [encryption] (http://owntracks.org/booklet/features/encrypt/) so that you can theoretically use a public broker for publishing your location data and no one can decipher it. This hasn’t been implemented in the MQttitude binding yet but is on the wish list!
Awesome! Though just to be clear it now supports end-to-end payload encryption. It has always (as long as I’ve known of it) supported connection level encryption through SSL/TLS. And connection level encryption is currently supported by the apps and the Mqttitude binding.
This is a far broader problem than just MQTT. There are databases, remote desktops (e.g. TeamViewer, VNC, RDP), poorly secured ssh servers, unpatched home hosted web servers, routers with default passwords configurable from connections not on the LAN, and more all exposed to the Internet. The problem has less to do with people not understanding the nature of MQTT and more to do with the fact people don’t understand how communication across the network works in general.
It’s a very hard problem because creating these things to be secure by default drastically raises the barrier to entry for new users. This security stuff is arcane, highly technical, difficult to get correct, and when it isn’t correct difficult to figure out why and how to fix it. When you are talking about our particular technical space this problem becomes even more pronounced because of the myriad of disparate technologies involved, each with its own unique security posture and limitations.
It’s no wonder Securing the Internet of Things is such a hot research topic right now.
Wouldnt it be better to just prevent/force only encrypted protocols for anything IOT?
What would be the impact if Openhab only supported encrypted protocols? I guess certain bindings may need to use insecure communications if their end device doesnt support them - but the binding could advise the user of this.
Such simple blind and blanket solutions rarely if ever actually work in practice. Good security is designed into the system from end-to-end and top-to-bottom. This is not something that OH can solve by itself. Encrypting the communication is only a tiny part of problem. And doing this wouldn’t really solve much of the security problem at a great cost to usability and ease with initial setup and potentially even utility of OH.
For example, if OH and the MQTT broker are running on a LAN and well firewalled from the Internet, what good is forcing the traffic between OH and the broker going to do? It addresses no actual risk but greatly complicates the initial setup and configuration.
But I do like the idea of informing the user about what sorts of risks might be introduced into their system when they take certain actions (e.g. opening a port in the firewall) and ways that can be mitigated. At least this way more people can make somewhat more informed decisions. But honestly, those who are interested enough to read such documentation either likely already know what the risks are and how to mitigate them. Most would ignore it and do what ever is easiest.
Other ideas I like are creating secured OH instances (VMs, Containers, etc) with some good security practices baked in. But like I said, OH can’t solve this problem on its own. The biggest risk factors right now are the things outside of OH that OH touches to get things done.
However, unless and until IoT technologies with strong privacy (encryption of connections, messages, and data at rest), good authentication of devices, configurable authorization (this is potentially something that OH could do, ACLs to only allow certain Items or rules to interact with certain other Items or rules which would prevent someone sneaking in through, e.g. a hacked MySensors network and opening your zwave door lock), integrity of messages and data, and non-repudiation (i.e. ensure there isn’t a man-in-the-middle changing messages on you), it will really be impossible to build a really secure HA system.
The ACL idea though might be something worth pursuing sometime down the line.
Here is a good overview of the types of security available in MQTT. Some is specific to the site’s product, but most of it is general security features of MQTT.
Ha! I was planning to actually attend this talk for the exact reason of seeing how many people are using this in a non-secured faction. I’m a security guy, so that’s always been my first steps is how I can block and tackle ensuring only I am able to get access to OpenHAB and it’s supporting services.
Probably worth a separate thread, but I would suggest also looking at setting up LetsEncrypt as a binding perhaps? That can functionally process rotating the SSL cert with a secured free SSL cert for communication. This can help reduce the possibility that someone grabbing MQTT details, finding the domain, scanning and finding the open port serving OpenHAB, and then being able to MiM attack those users.
Oh look my house is armed, the doors are locked, and the lights are off, good. Meanwhile, malicious actors are currently looting your home. Pretty extravagant example, but helps illustrate the point.
Not sure that a binding is the right choice but I have had on my list of things to try getting a LetsEncrypt cert working with OH.
I’ve not had time to do more than think about it yet and there are lots of other things that are higher priorities for me right now (like getting back to work some OH 2 documentation).
At a minimum a tutorial on how to get it working would make a great page on the wiki/article in the OH 2 docs.
@rlkoshak I would tend to agree. That was what came to mind as an easy understandable way for folks who aren’t security minded. But yes, a how to, or some alterations to make it easier (with the whole requiring an open 443 for easy renewal while OH runs on the same port). I did stumble upon this though: https://gist.github.com/dfraser/e5710fb84c6d35aa0743 - though I haven’t gotten to test it out yet. Sounds like a good idea, provides the basis for getting this done.
