Hubitat over HTTPS/SSL using Apache

I look forward to seeing what improvements you have planned. I know dashboard access management is one aspect that could use some love in my book. One approach I use to secure systems at work is to leverage conditional access - basically rule machine for access:

You would define something like this:

  • User(s): All
  • Dashboard(s): All
  • Location: US Only
  • Method(s): Local & Authenticated Device (ie: Hubitat App)
  • Result: Allow Access

I'm sure implementing something along these lines would take bit of work, as it does allow for a wide range of configuration options. That being said it allows users to poke smaller holes in their security defenses.


There are different kinds of security that should should be discussed, such as HTTPS/SSL. If we are serious about keeping our hubs secure we should be discussing them all.

HTTPS/SSL - This is transport security, and only protects information when it's being actively transferred between systems. This would be a good thing to have implemented, but I would place it lower on the list. Unless you are logging/logged into your hub it has no benefit. Even then the benefit is somewhat limited as the connection is local to your network.

The main risk here is malicious activity on your device/network, where it would be possible to capture and decrypt the traffic. If this is the case you have bigger issues that need to be addressed.

Device Encryption - This can be considered data-at-rest security, and focuses on protecting the data where it lives - your hub. Once again this would be something good to implement, but does have other implications. What happens if the device experiences a failure and needs to be recovered? Where is the encryption key stored, and how do you recover a headless device? You can't connect a keyboard/monitor to enter a recovery key. This would require a lot of effort to implement correctly, and have minimal benefit. If someone has physical access to a device they have total access to the device. Any security can be compromised given enough time, and let's be honest your bank account is more interesting than you home automation.

Remote Access - This is perhaps the biggest issues right now that does need to be addressed in some manner. The two main approaches people seem to take are 1) Setup a VPN 2) Configure Port Forwarding.

If someone is taking the time to setup a VPN for controlling their hub, that's a somewhat secure option. Depending on how it's configured the connection is secure from your device, to your home network - at which point all the same risks exist as not having remote access configured. If your VPN isn't configured well this could be a giant hole into your network, but this isn't a Hubitat issue specifically.

The more concerning approach is uses configuring port forwarding. It's just a giant hole for anyone who finds your IP address to walk right through to access your network. Or more specifically the device you configured in the forward. This is where device and transport security matter more, as the hub is now responsible for the security of your network. If I crack your hub I can use it to attack the rest of your network.

The best thing Hubitat can do here is just communicate the risks of configuring remote access and making it clear they are not responsible for the end results. If you the power user is configuring remote access, you should be taking steps to improve your network security. How can you create a more secure connection to your network - as that's ultimately what you are doing.

Device Security - I think this is the area Hubitat could focus on some. One of the basic security principles drilled into everyone's head is to keep your devices updated. Given we lack access to our hubs, we are entirely dependent on Hubitat to implement security best practices. How is the underlying operating system updated, how is SSH access secured, how is the system accessed, etc. Yes - Hubitat provides updates, however I suspect these are largely focused on the software itself. If they are also updating the underlying operating system that could likely be better communicated.

In short, there is work that can and should be done to improve security. That being said more of the work falls on us - the users. Hubitat can certainly take some steps to help, but most of it falls outside their hands.

This discussion is very interesting. However, it misses a very fundamental consideration.

When I was a kid I had heard the word "engineer", and sort of had an idea about what it meant. But one day I decided to look it up in a dictionary. What I found had a profound impact on me. Paraphrased, the definition I found was "an engineer is a person who applies the principles of science and technology to practical problems with a view to their economic impact".

An engineer could design a bridge that would withstand every conceivable load. But, without doing the actual engineering analysis of the real world loads the bridge would be subjected to, the bridge would cost too much to build. This idea that the economic impact is the responsibility of an engineer to consider is a central aspect of technological advancement. Without it, there is only cool stuff in a lab.

Listening to you security engineers, one would get the impression that all of our engineering budget should be diverted to address your concerns. As a business man I say 'nonsense'! We have to apply this principle of engineering to everything we do, to allocate scarce development resources with a view to the economic impact. That's what every business does. That involves making judgement calls on the relative importance of a variety of risks and potential rewards.

Perfection of security has a cost, and failing to perfect it poses a risk. There are thousands upon thousands of hubs in use with no reports of any security related breaches. At the same time there are dozens of posts about theoretical security weaknesses. What is the business to decide? How is that decision to be made? Which one of you who know so much about security is prepared to weigh all of the competing demands and risks, not just the ones you know about?

We move ahead, assessing all that we know, coping with the pressures of the real world as it demands our attention and resources. If you think the risks of using Hubitat Elevation to automate your home are too high, you would not use it -- but wait, you are using it, right? Hmmm.

4 Likes

I completely agree. When I took one of my Fundamentals of Computer Security classes years ago, I remember the professor saying "Imagine you have $50. That's your life savings. You want to keep it safe. Which do you do, hide it in a drawer? Or buy the world's best safe for $1000?"

Of course the world's best safe is the safest option. But do you spend $1000 to protect $50? Of course not! The cost of the security outweighs the benefit when you're protecting $50. If I had $1million, sure that $1000 is worth it's weight in gold!

A big part of computer security is Risk Analysis. How likely is a situation to occur in the real world. So for me personally for my own HE setup, I don't foresee my wife (the only other person in my house) hacking my LAN to gain access to our Hubitat. Is it possible that one of my neighbors hacked my wifi, is using airsnort to sniff my wifi traffic, and has sniffed my HE password? I suppose it's possible. However, since my neighbors are people who as soon as they found out I'm a developer had me come over their houses to setup their wifi for them... probably not likely.

Right now, honestly, my biggest security weakness (I've mentioned it a couple of times so I won't beat a dead horse) is that I hate that as MQTT is becoming an internet protocol, not a LAN protocol (both Azure and AWS have cloud based IoT hubs using MQTT), that I am sending OAuth tokens over the internet in plaintext because MQTTS isn't supported. That's much scarier to me than stuff on my LAN. Still, I accept the risk and do it because I say to myself "the reward outweighs the risk."

We all take risks every day, every time you get in a car it's a risk. But we decide it's worth it (most of the time) an accept the risk. Computer systems are no different. Now if @bravenel said "all we have to do is Https=true but we refuse to do it!!!" then I'd agree, bad decision. But I'm sure there is a lot more work involved than something so simple. You have to build a UI to enable/disable https, provide a means to upload certs (and manage when they expire, a huge problem with certs that almost no one does well!), implement mDNS to provide a DNS entry for the hub instead of just an IP... all that takes time.

2 Likes

I put about 200 hours moving my house in its entirety from x10 to zwave/zigbee on hubitat. Then I started to find flaws. I guess thats my fault. I should have searched for the security issues first. Based on the reaponces from the community I guess I will need to refer back to something I learned when I was younger. "Dont hold onto a mistake because you spent a long time making it"

My issue isnt that you build a bridge to not withstand an unimaginable load. Bit that the bridge was build with a decades old design from the start.

I don't think that's fair. As we've already agreed, most CONSUMER devices, to this day, are built with the same level of security as HE. It's not a decades only design, it's a very common design for LAN. As I said, HIPAA, FERPA, PCI, and I believe Sox, none of them require LAN to be encrypted. LAN traffic being unencrypted is, for better or worse, industry standard. HE is not some oddball here. I'm not saying adding HTTPS at some point is a bad idea, I'm saying, as someone who is a business person myself, is it the wisest use of resources? Probably not. I suspect sales are not won/lost because of the lack or presence of a LAN based HTTPS solution.

Edit: I also don't think @bravenel said "no" so much as "likely, not now"

1 Like

This is precisely the point.

Choice (a): Invest x dollars in a feature that gets y new sales.
Choice (b): Invest x dollars in a feature that gets 1 new sale.

Which would you do as the CEO of the business @Hasty1? Now, cascade those decisions over time, toss in security experts buying the product as a result of having made the right choice (a) at some point along the way, and discover them saying, wait, you should have made choice (b).

there's also a subpoint... y new sales lead to z new dollars which gives you more resources to eventually do (a), (b), and (c) and (d).

1 Like

Yes, and making choice (b) puts you out of business with not enough sales. Thus it goes, round and round...

3 Likes

I am going to take a beat here after reviewing everything that has been said.

First of the response from Hubitat has actually been acceptable. Security bug noted, We'll put it on the list. However I feel like I have to defend this from a mob of people who this that this it not worthwhile.

Statements like the ones above do get under my skin, (sorry @LostJen you just happened to be the one in this thread, there are many here who share your view point) it makes me feel like the consensus is security is the end users responsibility and the platform has no responsibility in it. From my viewpoint the community in large is not as concerned about the security of the platform as I am. So I will start taking concerns direct to support and not post them in the community.

So, Hubitat has bugs and issues. The support team seems to be taking them into consideration. The community at large doesn't want to hear about it.

The only other issue that I have is the timeline. Finding what seems to be small bugs and finding a post from over a year ago where a staff member mentioned it was being looking at and still having the bug exist today is a bit disheartening. However it also seems that Hubitat would rather focus effort on releasing "Product 2.0" a year later than spend 10-40 hours to patch "Product 1.1.0" that has said bug.

@dman2306 the above quote was a targeted jab at the design of the cloud dashboards. The URL being the locator and security was considered insecure a decade ago. Am I glad to hear about the new version, you bet. Do I think the old version should have made it to production. Hell No. But that obviously hasn't stopped sales.

@bravenel My primary issues here doesn't actually seem to be with Hubitat's response to security issues, it seems to be with the communities ability to instantly shoot them down as not an issue that needs looking into because they feel safe enough. That said there are security issues that exist that should have been caught and corrected before feature release (again dashboards)

That being said I will probably move away from Hubitat when time once again allows. For now it will just be removed from the cloud and the app removed from all devices and dashboards uninstalled.

Respectfully

Let’s make it even easier. If you don’t like http lan then there is this magic 4 letter acronym (vlan). Guess what the teen can’t even see it now. (Just a side note but if you have to resort to locks to keep children in line you’ve already failed. Neither our 20 yo or 16 yo would even consider that. So maybe we should use a more real example)

Now further if the cloud dashboard are insecure to you don’t use them. I’m not a security or even network engineer. I was a high level dev and some past teaching, almost no network admin. My system isn’t complex. It was built from how-tos and other guides. Buy a raspberry pi, read the right documentation out there on ngenx, certbot, and client cents and you could have that setup in well under a week in your downtime / professional development time.

Encouraging people NOT to use the product generally isn't the best way to see the product succeed. @bravenel gave a very well explained rationale of their business perspective. Why do people get into a "well if you don't like it, don't use it" mindset? Don't you want to see HE get better than it is? It's great, but not perfect. This is a super helpful community, but I agree with @Hasty1, when people make suggestions on how to make the platform better, people get super defensive, "like it the way it is or don't use it" Why?. While I don't personally want this suggestion to be #1 on the list, I certainly think it is a good idea.

Security is part of their mission statement.

2 Likes

Thank you @dman2306!

  1. Pointing out a vunerability and saying add it to a list of things to consider, should be as simple as that. If it is a known venerability, I shouldn't have to justify the attack type.

  2. Seeing a tutorial on an advanced setup and saying people have an interest in this wouldn't it be nice if the basic workings of this were availabe natively shouldn't bring negative feedback.

Many of the community users have a high skill level with technology. I have seen other post where someone has mentioned that x feature shouldn't be added because you can go get this other hardware and other software and some cloudsevice and then boom its done. And while many of love to tinker. Many don't or can't. Opinons on my free time and professional development not withstanding.

1 Like

You cherry picked my quote and took it way out of context. I offered the alternative of a secure way to use the local dashboard.

Edit: in fact one could argue that my suggestion IS keeping it at home and secure more than cloud access

Back on to the original topic.

I don't want the hub to expose things over HTTPS. It would be really handy if it behaved better through a reverse proxy though. Just having the JavaScript use window.location.host and window.location.protocol when generating self links would be enough.

I'd actually prefer to do my own certificate and authentication, as my original post shows I'm using Google OAuth. I trust the security of my Google account WAY more than essentially any other auth option out there.

I just need the hub to play nice when being served on a different domain/port/protocol than it is aware of which isn't terribly hard for a web application to do.

1 Like

At the risk of sounding defensive (hey, it is our baby!), this is not a supportable description of what happens.

If you look through our past release notes given with each release, you will find there is always a mix of new features, devices supported, app features, and numerous bug fixes, Most bugs are addressed promptly. Our focus it never solely on releasing "Product 2.0". There is always a balance.

And, there is always more to do. Your 10-40 hours is multiplied times over by the breadth of what Hubitat supports. We scramble as best we can to resolve weaknesses in the platform, and don't release things that may have, in your view, security weaknesses, mindlessly, without good reasons. It isn't perfect, it's not a perfect process, but it's better than any of our competitors do. We will always strive to improve Hubitat Elevation to the best of our abilities.

I predict that you won't leave Hubitat when you have more time, because you won't be able to find a better home automation platform to move to. At least, that is our ambition and goal.

1 Like

I can respect that answer Bruce. And I do think in a lot of areas you guys have been great.

You in particular have helped me solve a few problems pretty quickly.

A roll your own soltution with something like HASS was something I was trying to stay away from. But if I need to roll my own reverse proxy and build system to sent SMTP emails and get the other features I want I suppose that might be where I go.

From some other post I have gleamed there are bigger changes coming in the following months.

We shall see if those are enough to keep me around.

Sending emails from the platform is the sort of feature that is more likely than less to be addressed.

If you had to choose between sending emails and having HTTPS, which would you choose?

This wording confuses my brain. Are you saying it’s likely something you’d add? I’d love to natively be able to send emails!

Ah, brain confusion -- I know it well!

Yes, we think sending emails is a cool thing we'd like to add.

2 Likes

Yes that is something I would like to see. I would like to see the cloud dashboard secuirty first.

And honestly if SMTP was available I would use it for notifications over things like the app. Which makes HTTPS less of a problem for me because with the app gone I can stop people from going to HTTP dashboards. Even if I cant control the cert a switch to force HTTPS redirect would be great start.

And hey you have file upload working. Whose to say that cant do cert management later on.

As I said the support team isnt my issue. It took me some time to seperate that out from the community members saying they don't want these things.