If someone wants to do that it would be great! I run everything on VMWare at home and so I just have an ubuntu server vm that runs all my exposed-to-the-internet stuff. Maybe someday I'll catch up with the future and switch to containers
Thanks for putting this together. I followed your guide and most things appear to be working. The one thing not working for me is the local dashboard links. If I click a dashboard item, nothing ever happens. Viewing the source I see this:
If I go to this url directly (https://myhubitat.mydomain.com/apps/api/6/xxxx), it loads the the dashboard window where I can click on a dashboard - which now works. I thought it might be because it was in an iframe and I might be blocking that via some chrome extension, but also verified it wasn't working in Safari either.
There is an issue with the dashboard iframe. It seems to only load as an http iframe even when called from the https site. I suspect this is part of the issue. All of the links to local dashboard from within the hubitat management interface go to an http dashboard.
People have been asking for better https support for over a year. And many people are defending HE for not having it. I cannot believe the solution to this is to build your own reverse proxy, when in reality https for local access should be an easy option to turn on
I’d rather they didn’t waste the time myself. I already had a reverse proxy for several things and further instead of some kind of user name password I use much more secure client certificates. They got plenty to do without adding features that are less secure that what a few hours provides.
From reading over previous attempts to raise security issues I am not surprised this is your (or any one else's in the community) response. There seems to be the consensus that the current security( or lack there of) is enough. The reasoning always seems to be that it will confuse the common user, thus drown the company with support request and that if you want something more you should be able to build it yourself.
While I know I am not the only one who knows that there are numerous vulnerabilities that should be mitigated, it appears that the community would rather have more features than things that are considered the baseline of modern security. From a security standpoint it feels like this device was developed in 2008 not 2018.
I think what is most frustrating to me is that most of security features that I am looking for seem to be halfway implemented. Enough has been done and shown that I know the platform and developers can do it the right way, yet it seems to sit in this state of 70% correct.
While I cannot know what the future holds for this device, the larger the footprint the more likely it is going to be seen as an attack vector. I sincerely hope that security becomes a focus as they continue to grow.
I truly like my device features, but I do know if it is something I can recommend or continue to use on my own. Certainly not the dashboards or mobile app as they stand today.
Can you please provide some of these vulnerabilities that would allow for attack vectors through LetsEncrypt ssl server certificates and ALSO custom client certificates? Both sides are identified by very strong cryptography. Being able to use them is specifically why I don't want lesser security from them at the expense of their time.
I despise FUD. With no security at all HE isn't an attack vector because HE isn't natively visible to the internet. If you choose to make it so then you are responsible for its security. YOU not THEM.
Ideally it and other internal service/device made visible should be shielded by a product designed to be secure instead of baking security into each piece individually. DRY (Don't repeat yourself).
I am not saying there are vulnerabilities with your setup. However that is a very complex and customized solution.
In an effort to not repeat myself, I am not going to speak to the fact that HTTP on a local network or that your gateway should protect you is not good security practice in 2020. However I will say that loading an HTTP iframe inside of an HTTPS site is.
Log into any hubitat via HTTPS on the local IP address and click on dashboards and then click on any dashboard link. It won't work. because no modern browser allows code execution from a HTTP iFrame within a HTTPS window. This fixing this issue should be one that anyone finds reasonable.
Let say you share a PIN secured cloud dashboard with a friend staying the night. You are going to change the pin after they leave. However when you give them that URL
All they need to do is change the Dashboard number (174) to validate and check for any non pin protected dashboards. While cloud dashboards have HTTPS and an access token that token is the same for every site and every session until you manually change it. More than that the token is held inside of the URL. By granting access to one dashboard you have given access to all of them.
This is known as security thought obscurity and it is not a valid security practice for 2020
The fact of the matter is WiFi routers used to be sold with no encryption turned on and terrible default passwords. But times have changed, people have learned that there is a certain level of stupid things that users will do. At some point you need to apply a level of reasonableness to what expectations you have of the device vendor.
A quick search on Shodan shows a number of users who have port 8081 open to the internet on their hubitat. Is that hubitats fault. No. Should this web interface have some basic level of security applied to it. Absolutely.
I do believe that there are issues that need to be fixed. Maybe I am the only one.
This topic is frequently misrepresented. As with all things software, all of this is quite doable. We aren't lacking in understanding of these issues. However, we don't have infinite development resources, so of necessity things get prioritized and we work down that list, doing the most important things first. For some people, they are up in arms about our "lack of security", or our failure to go completely to https. What you find is that people who want to use our hub beyond its original target use model are the ones demanding better security. If this population represented a large segment of our customers no doubt these requests would have higher priority. But, the reality is that this is a pretty small segment of customers.
As much as it pains us, and sometimes you, we can't do everything TODAY. If you watch Hubitat evolve over the next few months you will see why. As we grow, more and more of these things will be filled in, we will get further down the list. Eventually, tomorrow does become today.
But ultimately large portions of the community may not understand the risk. Who wants to change the oil and buy new sparkplugs when you can upgrade the stereo. These things are necissary and to see post about the same vuberability from a year ago, with a user base who seems to think that its a wasted effort because there are more fun things to see is really discouraging for me to see as a security professional.
I have seen these sorts of venerabilities pop up in very basic scans and frankly should have been resolved before leaving beta. However it is not my company or software.
Whats more discouraging is the number of people who basically write this off as it wont be a target, it doesn't have the value. It doesn't need to be safe because other things are more unsafe and more valuable. Or there should be something else in place to protect it.
Fact of the matter is every device needs a good secuirty foundation.
I can get off my soap box now. I hope and wish the best for hubitat. Maybe what will come out in the next few months, will have all the wiz bang features with a good secure foundation.
What would be much more valuable than a soap box is for you to articulate the risks you see -- not it terms of it should have https, or it should have this or that design, but in terms of real world actual threats of compromise. You have a device behind a firewall that is only reached from outside via secure links through our cloud.
The vulnerabilities you describe above, correct me if I'm wrong, are ones within the LAN, within the household. (Clearly, people can do dumb things like open port 80 on their router.) So please describe the kinds of exploits you think are realistically of concern, that warrant this being higher on the priority list.
Giving up the UUID of a device that from what I can tell doesn’t even change via a complete reset and an oauth token that will allow you access to every dashboard until you reset it and have to rebuild any and all dashboard links.
You have a portal that has login capablility. This could be utilized to get an oauth token with a refresh token. Which would typically be stored in a cookie and not exposed directly as part of the URL. Which could keep a season logged in for a very long time. This would also provide sessions that could be revoke for dashboards.
The system as it stands now allows no ability to revoke access without then granting access back to everyone with access it also will not grant partial access unless everything is secured by a separate pin
If you read the post that started this all it is about a usablity issue in the dashboard menu that has been know about for over a year
The cause is the mixed content which almost every modern browser is blocking.
If these are not specific enough thn please reach out and i can provide further documentation.
Yes, you're right about this issue. Dashboard improvements is on our list of upcoming projects, with fairly high priority. We have been working with a per-user Dashboard feature that allows for the creation of revocable tokens for a specific user's access to a specific Dashboard. This would specifically address the concern you have raised.
I very much agree this is problematic, though it doesn't affect me as I don't give out dashboards to anyone other than my family members (who have physical access to the devices anyway). But, this problem isn't related to the claim you made that we need HTTPS over LAN. To @bravenel's question, what kind of realistic threats do you see lurking within our LANs that HTTPS would resolve?
By using http on the lan the assumption is that every other device on the land is always trusted and cannot be compromised.
Let say you live at home with a teen who wants to be able to disable the alarm to sneak out of the house. It is possible to sniff the password sent to the hubitat at login, over the lan, or sniff the pin to the dashboard. Or browse to :8081 and shutdown the device.
It is clear from this of this post and other post that exist with similar topics and from running a shodan scan that people are using https. Additional the device can run custom code in the form or drivers and app. If an attacker gains access to the lan. Adding addtional apps to the hub can be used to gain a backdoor back into the network.
security is about layers and the ask is not for some bleed edge new technology. This is technology anyone would expect to find in a modern network device
I think that's a bit of an edge case that can be better resolved other ways. I set my alarm to beep when disarmed. Problem solved. Let us not forget that the weakest point of any system is the people involved. It is more likely that this malevolent teen figures out mom and dad's password than it is that he's going to setup a network sniffer to find the password.
Coming from a security background myself, you do balance the likelihood of the attack vs. the impact if said attack occurs. What are the odds that the teen in your scenario does what you described vs. what we all did as children and lie about sleeping over a friends house? That's why I'm asking if you know of a real world likely scenario. Are there any attacks you're aware of that scan for 8081 and shutdown devices? Or that actively scan a network to inject Groovy code into an HE? I'm not saying it's impossible, I'm saying, do such things actually exist, or are we in the world of theory at the moment?
Edit: Being in the world of theory doesn't make it an unimportant suggestion, it's just a very different thing if exploits are in the wild.
We are in the world of theory as far as injecting code goes. Everytime someone says no one will take the time to do something some 14 year old in China does.
Something that scans the local network to find further attack vectors absolutly happens. And to find an unprotected page that says wipe this device is a large threat. Even a code on the bottom of the device that would require physical access to the device would be acceptable. And quite honestly I could write a 1 line curl command that anyone could run on any network to reset any local hubitat.
If I didnt think I would get banned I could probaly write a link and put in in this post that would reset the hubitat of anyone that clicked it thanks to mDNS.
Cyber security is about the edge case 99% of the users are going to use it as intended and its OK. But the fact that 1% can use it to do something you shouldnt is bad.
Finding flaws in implementation that are know bad design from a decade ago is concerning
sarcasm emplied 
