New to HE, gave up on Wink. I see there's user security, and the ability to connect via https.
But, there doesn't appear to be any way to disable http, and when you connect https it presents a self-signed cert.
So, the questions are obvious, how do I disable http, and how do I generate a cert signing request so I can generate a cert and have real security (and so my browser doesn't complain)?
Oh, and the cert is only good for a couple of years. I moved off Wink because I wanted local control and didn't want a brick if they went under. If Hubitat simply expects to update the cert with new each new release, I'm not a whole lot better off than with Wink - I'm still dependent on Hubitat continuing to exist and provide updates, at least if I want a somewhat secure device.
IF HE cease to exist then you will have a hub with the latest update, before they disappeared, that will continue to run as it is all local.
Disconnect it from you local network and it is completely secure.
As for your other questions about certificates etc. I don't have a clue about that sort have stuff.
[quote="bobbles, post:2, topic:14357"]Disconnect it from you local network and it is completely secure.[/quote]And back to being a brick for many purposes, like controlling any IP device (of course, most of those aren't secure to begin with).
Yeah. I suppose it depends on your use case.
From my perspective the only thing I will lose is control of my heating through HE and I will have to use the native heating app.
Everything else is z-wave or zigbee.
Hubitat has never said that their focus is anything other than Zigbee and Z-wave devices. Everything else is pretty much a bolt-on (IP devices, cloud integrations, etc).
However, what @bobbles stated is true; Were HE to go out of business tomorrow, your hub would still work for all of your local devices as it doesn't require an internet connection to function. Anything that requires a cloud integration would continue to work so long as those companies stay in business. The Hubitat hub doesn't rely on anything external for core functionality.
As for https and signed certs: This is what @patrick stated a while ago:
The Cert is self signed. But it's largest value to people in this community is the fact that it's an Encryption Key and not in who signed it or the expiration.
Self signed means you have to add an exception to your browser to allow it and therefore stop the warnings. The exact same would be true of an expired cert... you'd get a warning and you'd accept it and that would be that. You could use the expired cert as an encryption key for another 20 years, or 40.
That's not to say that's a wonderful idea, but in terms of "what if" -- it's a nothing. imho
The official "Supported Devices" list shows lots of LAN and Cloud connected devices. That's a focus on "other than Zigbee and Z-wave devices." For example, without a LAN connection all the Lutron stuff, HUE bridge, and AV equipment control goes away.
That's simply not true (in this context, meaning continuing to have a box with even a modicum of security). I didn't say anything about an Internet connection, I'm interested in local control, including for local IP devices.
Something I've never really understood... Really what use/benefit/reason is there for having SSL/TLS on INTERNAL communications? Encrypted, yeah sure... from what/who? If there's already a "bad actor" INSIDE your network you have bigger problems than someone learning that you turned on a light bulb.....
While I agree that a bad actor on your internal network is the bigger problem, you do seem to be missing a couple points. First, it's not just lights: many people have locks on their hub too, something most people would want as secure a possible. (Though enabling code encryption would help here with at least preventing the codes from showing as plain text.) Second, you can enable user logons to the hub, preventing anyone with access to your LAN from also accessing (or, more to the point, administering) your hub. This would be a username and password logon, with a popular recommendation being not to transmit passwords over plain text (as HTTP would). The self-signed cert works fine for me, though I certainly understand the wishes for others to be able to upload their own "real" one. Unfortunately, there are still some HTTPS oddities/bugs, like iOS Safari not updating live logs unless viewed over HTTP (or at least there were last time I tried).
The lock code manager that sets the codes I can see using an encrypted communication for. The locks communication itself is already encrypted.
The hub management aspect perhaps I could see as there is a password.
Yet with each of those scenarios it still requires LAN access... you already have bigger issues as who/what is already inside. Could they be running a rogue sniffer? Probably sniffing the wifi as I doubt they walked in and plugged something into your switch. More than likely it's malware on a machine because someone downloaded that nifty cool new "thingy" they saw mentioned by someone on some site somewhere they were browsing... either way they are now IN your network and have most likely gathered a whole lot more than your hub admin password or lock codes and they really don't care about your lock codes in reality....
No... the real THREAT to hub administration is FAMILY screwing with things!!!! NOW that is a REAL THREAT
True, but that wasn't the "original" HE missive though. The original HE had a strong focus on local only devices. It was only after a lot of feedback from the community that they started adding the cloud services. With that said, many of us have planned our environments to be local-only first. In my setup, the internet can go out for days, weeks, months, years, whatever and I'd still have control over everything (except for my Ecobee and Alexa devices). My AV equipment all runs on Harmony hubs and I can control those locally. My lights, switches, bulbs, motion sensors, everything in my house all runs locally without having any need for an internet connection and that's why I bought the HE hub in the first place.
How does not having an internet connection interfere with your local device control and/or security? Not having a LAN connected is one thing, but not having internet wouldn't interfere with local-only IP devices unless those devices themselves rely on cloud services. A lot of my switches are Sonoffs flashed with Tasmota so that I don't have to have an internet connection to use them.
As for security, how does the HE not have any security when not connected to the internet?
[quote="corerootedxb, post:13, topic:14357"]
they started adding the cloud services.
[/quote]What? I've said nothing about cloud services, and have specifically pointed out that I'm talking about IP devices. I can only assume you're getting confused about the difference.
It's not clear what you're asking here. Perhaps you should go back through the thread, which is about doing proper network security. The Internet has little to do with it.
Hue Bridge, Lutron, and most others I can think of are local, not cloud. They just happen to work over your LAN and not Zigbee/Z-Wave. (Obvious exceptions include Alexa and similar.) I'm pretty sure Lutron has been there from the beginning (can't remember since hearing about how well it worked with Hubitat was what convinced me to get it afterwards; compare the ST integration that does use the Lutron cloud). Hue Bridge integration wasn't there originally but I'm pretty much sure they more or less always had it planned, and it's not cloud in any case.
Which is what I am referring to. Cloud services (IFTTT, Ecobee, Nest (until Google f'ed up on that one), Rachio, etc). I'm not talking about local devices/services.
Why have motion sensors in your house for a security system? It's internal, your outside doors are locked, after all.
But actually you wouldn't believe the number of SOHO gear out there that get hit with zero day exploits every day, with many toy router by and large being used as part of a DDoS botnet. Of course, I wouldn't necessarily need to commandeer a router to MitM any services on your internal network, a gratuitous ARP flood will work equally well. Easily done if some careless individual downloads malware on their PC. Or, perhaps somebody who comes to visit has a rogue app installed on their phone and is none the wiser, then joins your wifi network because for some reason they have bad cell signal. Chances are your wlan isn't segmented from the rest of your internal network, after all.
When you type in that password to log into your hubitat, or whatever else you use internally, capturing it is very trivial so long as I am in the middle of you and what you're logging in to. Good chance you use that password, or some variation thereof, for other internal services, perhaps even external ones if you're extra careless. Nonetheless, there's a pretty good chance I am in full control of your home security system, if you have one. Not that I'll use that information, but somebody will offer bitcoin in exchange for backdoor access to it. And then there are those documents on that NAS that you don't set a password on, or that windows file share that you leave enabled in the "private" profile in your PCs firewall, and again left it with passwordless authentication so it's more convenient to share files.
At some point or another, I'll figure out what websites you commonly use by monitoring your DNS lookups or perusing some of your data, and some of these sites use plaintext authentication so I can glean a few of your usernames. Oh, and then there was that password I snooped earlier, perhaps it will work on your facebook account. Of course, this information is all useless to me, but I can fetch some bitcoin for it, and the chances of you finding out who I am are pretty much nill.
Sorry, couldn't help myself I do this for a living. Or rather, my job is to protect the information within the internal network of the health care provider that I work for. Knowing what "they" are capable of and what "they" will try is how I keep that protected.
And then there's the matter of how I landed here: I use my own PKI on my internal network, and was hoping for a way to upload my own signed certificates (Note: that isn't the same as "self-signed"; there's quite a distinction.) I don't suppose the hubitat developers have thought of it? They did make the effort to enable TLS, after all.
Nice write up and all pertinent for a normal environment. Your points are valid within a point of reason. All of the attack vectors you listed require a bad actor to get on your network in the first place. Which in a "normal" home setup actually is quite easy. Yet if a bad actor was inside then having spotty encryption from a few places while it lacking in others isn't going to help all that much.
Well one other thing that crossed my mind about what you said about being able to see when lightbulbs are turned on or off, somebody could learn your daily routine from it, perhaps knowing when you're home, and when you're gone.
Personally I'm not that paranoid, the main reason I have all of this is more out of hobby and it's just stuff that I like to do for fun. Although, none of the above mentioned vulnerabilities exist in my network, some of them aren't really feasible for the typical person to mitigate against. Segmenting your wireless network for guest and regular traffic is easy enough to do, and most people have equipment that can do it at the hardware level, but the software won't support it without flashing custom firmware in most cases. Protecting against ARP poisoning like I described is one of those things that most people wouldn't be able to feasibly do, but I have an enterprise grade switch and the knowledge of how to use dynamic arp inspection.
I approach SSL/security with my HE Hub the same way I do will all servers/applications on my network. I doubt everyone will go to the trouble to set up an enterprise grade network at their house, but I'm a cloud/devops engineer by trade.
Everything is behind a proxy or load balancer that terminates SSL using signed/trusted certificates. Letsencrypt makes life easy when it comes to certs; they also released wildcard certs not too long ago which makes things even easier.
If you don't have anything like this set up, then self signed certs are probably more than sufficient.
On top of this, I keep everything IOT on it's own network/VLAN and keep that network locked down on the firewall. This means that even if you are on the WIFI or LAN network, you can't see any of the traffic from the HUB.
Securing your Hub with SSL prevents someone that's gained access to your network from seeing login credentials when your browser authenticates. It also ensures all web traffic is secured. This is important, as others have mentioned, because lock codes and other sensitive information is contained on certain pages.
That being said, you can accomplish all this fairly easily using your default modem/router, place it in passthrough mode, and connect it to a pfSense appliance to use as your router/firewall. If you don't have a decent firewall, it's probably not worth using anything other than a self signed cert IMHO.
imho
