No no I got the wrong end of the stick and am agreeing...... unlikely to be a target of a criminal ( very unlikely )
1 Like
Hi
I just joined the forum and this was the first conversation I opted to view why? because security is a big deal. Please do not back down from your point - HE needs to implement the ability to restrict traffic to TLS1.2 if this product is to be taken seriously. I am very new to the product so I don't yet know if it does support https access and it wasn't clear in the discussion.
With all due respect, I have noticed quite a bit of deflection by the proponents of HE when any of the shortcoming are raised. It's unacceptable to say that the point you raised isn't a major concern because it is. We cannot assume that all implementations will be in a single family basic configuration.
Here is an example of a hypothetical scenario: you may be using HE to implement automation for a shared set of apartments or rooms or some other configuration that neither of us are thinking of. In such a scenario there is nothing stopping one of the tenants from running wireshark and viewing the clear text traffic between your http session and HE.
What is the most that can happen? Well he/she can use that information to manipulate access HE and gain access to another tenants unit and I can go on but I think you get the picture.
The suggestion of restricting access to a particular VLAN is good compensating control in some situations but, as the name suggests, it is just compensating for a shortcoming that really needs to be addressed. Also a person may not have the ability to perform more than basic routing and set up VLANs either due to lack of knowledge or infrastructure limitations or both. Therefore it is best to address the issue at the source so that the device itself ensures encryption in transit for all communications. This should not be a long discussion in my view.
1 Like
No, it's really not unacceptable to say that. People are commenting on their view of the risk - just as the OP is.
Yes, maybe they should have prefaced their opinions with "To me the risk isn't a major concern", but I think that is implied any time someone gives an opinion on a forum post.
No different than to the OP, or maybe you, it would be "To me the risk is a major concern".
See? Not mutually exclusive.
I'm a cybersecurity director for a Fortune XY size company, I have this discussion probably 10 times a week. As I stated earlier, it doesn't matter what anyone besides the OP things anyway, and he/she did the right thing by submitting a formal feature request.
1 Like
Those comments are likely also moderated by personal views on what Hubitat's priorities should be.
1 Like
I fully expect they are.
Hubitat is developer and resource constrained (although that's kind of a dumb statement as every company is constrained when you think about it - some constraints are just bigger than others).
So of course people are going to temper their enthusiasm for a change they don't have high value in, as it takes resources away from implementing a feature they do have high value in.
That's just the nature of customer bias.
1 Like
It may be unacceptable to you, and you are absolutely entitled to your opinion.. But it's pretentious to dismiss others viewpoints as "unacceptable" as they are no more or less valid than your own. The community has spoken about what is important to them, and that's the beauty of the community.
As a neighbor, what's to stop me from sniffing your Zigbee network keys with a $30 USB dongle and wireshark to potentially gain access that way? It is fairly easily done. Someone who has the skills to sniff a wireless network also possesses the skills for this. The point is, it's a false sense of security to think adding self-signed certs to the hub somehow hardens it.
Also, nobody here has explicity spoken out against this, but the general feeling here is that there are other priorities right now, and if implemented, it has to be optional as it will probably break some integrations.
2 Likes
Sorry but I don't think that I am the one being dismissive and it certainly was not my intention. It was quite the other way around to the original poster from my perspective. I meant unacceptable in the context of the big picture of product viability. https/TLS 2.1 is currently the minimum requirement as of approx a year or so. Ultimately the market will determine if not implementing it acceptable or not...
This is the kind deflection I am referring to 
. I never that it would completely hardens the device, there will always be vulnerabilities but the objective is address them as effectively as possible. Ensuring https communication at least creates a higher hurdle to jump so it is not false sense of security, it increases the security posture by some degree even if it's a small one which is the idea. I didn't think that there was a need to get into the $30 dongle and zigbee hacking...
I get that there may be different priorities but it wasn't coming over in the overall dialog in my opinion. I felt that the original poster was sort of backed into a corner which may not have been intended. Anyway I expect that the industry will make demands on the priorities especially regarding the security of the device. Cheers.
Not to mention a self-signed unverifiable cert is susceptible to MIM attacks.. You would never know, unless you analyzed the cert each time you logged in
2 Likes
point taken! Cheers.
1 Like
Here is the thing really, this is a consumer level product being bought by many different types of people .... most are going to be point and click type of people who would expect what ever products they buy be secured particularly ones which they have an intimate relationship with (lighting is an intimate thing ) .... most of these users don’t understand what an IP address is let alone what a firewall is ( it’s unreasonable to expect them to be able to asses the risk ).... for these type of users ( who will be the majority ) the position should generally be well secured and easy to use thereafter allow users to customize and adjust as required ( this does not mean it won’t be hacked just that the basics are covered ) .... what we see here is open from a security perspective with no warning or notice.. which may be how the community want the device... now if Hubitat is happy with this then it really should spell out to the general purchaser the the device is not secured and it is the responsibility of the consumer to secure the environment around the device .... which is not a hard thing to say if you believe and impossibly hard to say if you don’t
It’s about being transparent ....
Regarding ssl/tls.... that approach probably won’t work. Private CA would needed to operate the framework ... not really a runner me thinks .... or maybe it is and the hub during setup would dial back to Hubitat ... user does the proof of purchase thing and certificate provided ... over simplification + architecture wise a sea change as I’d bet some integrations on unfettered access ... that said it would have its positive from a theft and usage perspective ..... for Hubitat
PS am not giving up just toning the conversation down 
.... bunch of great and talented people up here
I quite agree that there are many talented and knowledgeable persons on here which baffles me as to why the suggestion wasn't embraced more. From my end I am not looking for a fight in any way, just thought that your suggestion is a very valid one. I have always looked at security as a priority in all relevant technologies of which this is one in my opinion. Cheers
Exactly. In an ideal world, Hubitat would have a staff of hundreds working with unlimited budgets. Unfortunately, that is very much NOT the case. So, while it's great to have a wish list, we all need to be realistic about how likely it is that any particular item make it to the top of that list and ever actually be completed. No one is discouraging people from voicing an opinion, just to have realistic expectations given the constraints hubitat is under.
The issue is that I don't see people doing this. I see people thinking that their very esoteric request should be the #1 priority and they don't want to even discuss workarounds or other methods to accomplish it. They want what they want and that's it. No one is going to tell them different. That is not a very realistic or appropriate attitude, IMHO.
1 Like
Agreed and as long the methods are reasonably accessible and realistically achievable to the general owner ( I’m thinking of most of the people I know who are not techs like the wife, my best friend and fairly much ever one else I know ! )
Ps I asked a question, got an answer , posted a request, opened up a conversation, prioritization is not a thing, basic security is fundamentally important to any modern day solution particularly in the consumer space
It’s just the way it is .....
2 Likes
I’m not sure sure that’s true. I recall seeing more than one article where it’s been stated that most users never change the default password on their routers nor update firmware to patch vulnerabilities. A quick Google search pulls dozens if not hundreds of references to this.
So I would postulate that warning customers about plain-text http does nothing.
It won’t work. Web browsers are making it increasingly difficult to accept self signed certificates with out a ton of warning messages, and usually elevated access. It's even more difficult if you use a mobile app that needs to connect to a service with a self-signed certificate. On iOS, due to it’s inherent security, you have to load a profile that requires special tools to create. Bottom line, as it stands today this very concept precludes usability by all but the most experienced users. Which we tend to be
But it'll be so frustratingly difficult, a majority of users will not turn it on.
I say majority.. Because I also do not believe we represent the core market. The SmartThings staff has often repeated that a huge majority of their customers never install community code or even join the community. I would not be too surprised if the Hubitat demographics aren't too dissimilar.
Again, it's impossible since you cannot have a signed certificate on a private IP address. It will always fail browser validation, no matter who the CA is.
Point is... There's no clean, nor user-friendly way to do this. It is also one of the reasons many companies have adopted a cloud-first architecture as it completely avoids all of this, while providing a reasonable level of security.
As I said in my original post... I am absolutely okay with Hubitat supporting the use of self-signed certs.. I would just want to see it as an optional thing, and prioritized correctly against other needs of this ecosystem.
1 Like
You'll find out that of the many great qualities this community has, the big bad quality it has is those same exact "talented" people don't take kindly to ANY criticism of the platforms downfalls and failures. And once one does do this objective criticism publicly for others to see, it brings out the community cheerleaders (pom poms in all) in droves and the army begins their coordinated attack to silence the dissent of the platforms short comings.
Good to have this kind of conversation here. Hopefully HE staffs reading this and make their decision accordingly. It's a slow process but eventually we will get there. Took a while just to have the UI user/pass implemented but they do listen and read our requests.
2 Likes
Lol I was active in a few auto build sites ... u want to see the fan boys there .....
Users not doing what they should to save themselves = their fault
system not allow a user a key functionality ——— ///////
This is a good platform really good ( I’ve tried them all ) and has the potential to be a field leader from a market share perspective ... IMO..... The problem is the approach ( which is the platforms strength ) is probably why no one else runs locally = it’s hard to secure .....
Hubitat in its current state is a perfect secondary entry point for taking over an entire network.
As a hacker you can view the password sent via http plain text (or brute force your way in since I imagine it doesn't throttle login attempts). After that, forget about hackers turning lights on and off, even worse a hacker can use the UI to execute CODE. And from there it's over. They can start using your IP to break the law, possibly camp out to steal your identity, or whatever they want.
Your network is only as secure as your weakest device. And this device essentially has no security. I want to see Hubitat succeed, but I hope they take a more aggressive stance on security before some lawsuit bankrupts the company.
How are these hackers getting onto your home network to the point that they are sniffing traffic to grab the UI password off the wire? If you’ve gotten to that point, you probably have bigger issues at play then your home automation hub. The hub should not be publicly exposed or have port forwarding setup.
Don’t get me wrong, security is important, but I think the threats your suggesting are a little overstated. Realistically something serving up content via plain old HTTP on your home network should definitely not be in your top 10 home information security concerns, at least in my opinion.
1 Like
