They could also do the same thing sitting outside your house. And they wouldn't have to hack anything to do it either.
1 Like
Right, but this approach doesn't require the whole "why has some shady lookin dude been staring at me with binoculars all day every day this week?" part. Passive data logging sight unseen will do.
Yeah, cause no one was able to learn your routine before Smart Lights came around.
As with computers and identity theft. As technology advances, so do the ways of doing old things.
How is learning when my smart lights go on and off going to give anyone any information that would be worth something? You do realize that there are much, MUCH easier ways that people get their identity stolen. There's a reason that phishing attacks still go on. THEY WORK. No one is going to hack into your smart lights so they can break into your home to steal your identity. You need to take off the tin foil hat my friend.
1 Like
Hmm...perhaps I'm not getting my meaning across. In any case, there isn't a need to be defensive. We're not saying that you have to deploy TLS certificates, we're just saying that we want to.
This Thread has been going on for 6 months, roughly. With 9 participants and 9 likes. Let's imagine that this is half the people interested in a solution, that would get their own Certs and deploy them and the root properly, anytime in the first 3 attempts.
You have no idea how much I hope that under 20 people is 0.1% of the Hubitat user base. The solution to this problem for all 20 people is quite large for a tiny development team.
Despite the fact that I could USE this solution, and would, I sincerely hope it is far down the priority list. I know that Hubitat recognizes the need, but the solution will just burn through too many hours with the solutions available... (none)
A solution that applies to 100% of the manufactured hubs is needed. A means to generate and install a unique cert on every hub either during manufacturing or as part of the registration process.. a means to invalidate and reacquire a cert, which again points back to the registration'ish process... with a root CA that is known to all browsers... Extensible to be replaced with self-signed CA and cert.
Solving this for 20 people, vs solved for ALL Hubitat customers, should be the goal.
...in my opinion.
2 Likes
Well I don't really need all of that, I just want to use my private root CA, in fact I would specifically prefer it not be a public root CA. I'm sure when it generates its own self-signed certificate and private key pair, it stores it somewhere. All I'm really asking is to be able to replace that with my own.
1 Like
The paranoid amongst us put our hubs on a separate (non wireless accessible) vlan and use enterprise grade hardware to configure and secure this 
However, I do understand your request to use your own ca auth.
But has been mentioned before, I would prefer that HE limited resources be employed elswhere.
Andy
3 Likes
Well, there's paranoia and then there's pragmatism To me it's basically economics, namely an opportunity cost. If you already have the knowledge and equipment, then the opportunity cost is low enough to make the benefit well worth it I didn't need 10 motion sensors, but the cost difference between 5 and 10 was basically nil when I bought mine, so now my house has 10 motion sensors installed
I would be happy with being able to change the port to access HE from the internet. Ex. my_ip_address:33443
I use a stand alone firewall that I would like to isolate HE access to when I am away with out the need for a cloud.
That's off topic for this discussion. But the proper way to access HE externally is NOT to do NAT port forwarding, but to get a router which supports a VPN connection.
2 Likes
Actually my firewall does support VPN. I disagree. VPN is to connect to an encrypted private network. I only need to connect to this device of which port forwarding would work perfectly. I think I could work around the HE limitation by forwarding an obscure port to Hubitats 443 through my firewall's inbound traffic. Not sure why we can't update the listening port for Hubitats web server and to disable http port 80 altogether.
Using a random port is security by obsecurity and the reality of that is that is simply not security. Fortunately you mention port 443 which i think means you also would want to setup SSL/TLS with a certificate that you would need to maintain. Most people won't do that. Even if they do because we dont have full access to manage the HTTP server we can't ensure it is hardened/setup for vulnerabilities or ensure it is updated to prevent new ones as they come out. Lastly even if we hardened the HTTP server the app interface could be subject to vulnerabilities.
Probably the biggest problem is that the folks at hubitat have said more then once it isn't a hardened device and should never be placed directly on the internet.
The reason the VPN is the prefered method of security is because the premise of the VPN is as you stated to secure your remote device back to your home private network. Then Hubitat never is exposed to the rest of the world for people to try to get through.
If you absolutely insist on putting it out there and don't care about the risk, probably the best method if you dont use a VPN would be to use a hardened reverse proxy like Nginx with a long secure login password in Hubitat. Atleast then you can ensure it is using SSL and not worry directly about the webserver on Hubitat. That is a best of bad ideas though.
2 Likes
Ok you sold me I will set up VPN access. Thanks Mikes.
1 Like
Most bowsers are insisting to go HTTPS otherwise will give you a warning the connection is not Secure. This are not HE issues.
Also, if you want to remote your HE, most likely you will want your data secure. If you have a lock, will not be nice if someone open your door or drapes in the middle of the night.
If you are only local: not a big deal.
Perhaps you now that IPV6 is here.... and extra risk. Some routers allow you to connect directly to your units, firewall free!!!
As someone who has worked in computer security, this thread disturbs me greatly. Yes, of course you should not allow access to your Hubitat Evolution directly from the Internet, and yes, a VPN is the right way to provide access. But that's not enough. You also have to ensure that traffic over your LAN to/from the Hubitat Evolution is encrypted. Why? Even on a secure home network it's very easy to get eavesdroppers. Just consider a guest asking to connect to your WiFi (or worse, one of your kids' friends). Assuming you know them, they aren't likely to do anything malicious, but who's to know what is running on their device. It may not happen immediately, but at some point you are likely to have some malicious code running inside your network. And yes, even if you have them connect to a guest wifi, it's all too easy to have misconfigured rules that allow the malicious code to sniff packets going to your Hubitat Evolution. And that is gold, since no HTTPS means no password encryption. And as soon as that is captured, they have full control of your house, including your locks.
There are a set of mitigations that you can apply to the scenario I outlined above, but you will end up making impossible trade-offs, e.g., requiring a local VPN to access the Hubitat Evolution so that the IOT network can truly be isolated, is a usability nightmare - sorry dear, just give me a second to get the VPN connection so I can control the lights, etc.
And doing so gets increasingly more complex, fragile, and further away from the mainstream.
So, please, for the love of everything you hold dear, add HTTPS/SSL support, even if you just use a self-signed certificate - most browsers won't complain about this too much if it's on your local network.
1 Like
@Hubitat_Staff .... Any update on this?.. also the built in hubitat cert expired on Apr 2021 !
I think if hubitat cannot update the certificates, then atleast they should allow users to use their own (domain/ self signed certificates ).. it is definitely better than expired certificates !!
When you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
| Site | 192.168.xx.xx |
|---|---|
| Certificate CN | |
| Certificate Authority | Hubitat Elevation |
| Certificate Validity | Not Before: Jan 10 21:29:33 2019 GMT |
Not After: Apr 14 21:29:33 2021 GMT|
|Certificate Chain|-----BEGIN CERTIFICATE----- MIIDizCCAnOgAwIBAgIEdyCgxjANBgkqhkiG9w0BAQsFADB2MQswCQYDVQQGEwJV UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2N.........
2 Likes
