Please let the mobile app users type in their hub address instead of going on IP in the app settings.
Makes the mobile app use cloud for dashboards and not much else works.
Not to be redundant but, as of now I use my domain certificate and private dns; (https://hubitat.mydomain.com), and the mobile app becomes quite useless.
This should be quite easy to program into the mobile app.
If private address specified, use that instead of detected address
I support this as well. I want ssl on my hubitat! I've got my own domain and would put a let's encrypt cert on it in a heartbeat.
You can already have it but it just makes the mobile app useless.
Effectivly that means it's not usable:-)
No, you can still use everything from the mobile web browser. Even Https calls for the Maker API work.
Also, any developers of the SSL for Hubitat should also let us specify the issuer for the trust chain.
I use alphassl, but that leads to GlobalSign. The browser needs that trust chain, in most cases.
I second this. Currently I have it behind a nginx reverse proxy but hubitat breaks ssl in such a way I cant include my own cert. Quite annoying and unacceptable in 2020. My other apps work just fine but for some reason hubitat will not work with any sort of ssl frontend I throw at it.
Just found that using SSL won't allow local dashboards. I guess I have to disable it for now.
Everything else seemed to work fine.
This needs to be priority 1 for everyone in the dev team assigned to web and security development.
You can still access the local dashboards... just not via the dashboard menu...because something in that dashboard menu is broken..
This is why custom SSL is still a beta feature
I know that 2.2.4 is supposed to have some much needed security updates for dashboards.
I have been screaming about security on this forum for 8 months now...it is coming but much slower than a lot of security guys want
How, pray-tell do you use the dashboards? Is there a secret URL that is passed inside Java? The URL looks the same on the URL bar.
That's odd, I just tried that and it didn't work.
Just read this further. If you are using the app exclusively to access dashboards, then yes HTTPS will break this.
The only reason I see to use the app for dashboards would be for cloud and local dashboards. But honestly even with HTTPS there are enough vulnerabilities in dashboards in general that I don't use the cloud ones.
Its local HTTPS only for my dashboards.
Just out of curiosity, what threat vector do you feel like you're protecting yourself against with SSL on the hub's UI? Is packet interception a concern for you at home?
I'm in the security field, so pretty aware of the risks, but I've just never personally felt a strong desire to push for SSL.
SSL will protect the URL from being sent in plain text. The dashboards only protection is a static token in the url. Which is the same token used for cloud dashboards.
The dashboard app in general uses an endpoint which does no validation against the dashboard ID to control the device. So by exposing the token you expose the entire system.
While I don’t suspect there are too many open threats today. IoT is one of the biggest attack vectors into residential networks. Here we have a device that can take groovy and run it at will from the UI. It really could be a great botnet if user base gets big enough.
I am going to reply again .... for reasons. I like many others here work in infosec. Mostly in the API space.
I just looked over some of the history and we have had this conversation before as well. The conversation has usually come down to the level of RISK. The damage that can be done and the likelihood it can happen.
In regards to Dashboards and SSL the damage that could be done is quite large, near total device control. (I will have to find the article about the guy who rigged a bunch of smart outlets to click on and off so fast the eventually caught fire)
The likelihood is very low. thugs aren't going around sniffing wifi to get into house to take the flat screen. Nor are there any bot/virus/malware attacking smart homes that I know.
However I feel the mitigation for something like SSL implementation, on a modern device with all the libraries out there should be relatively small.
High Impact, Low Likelihood and small mitigation cost. In my world that means go ahead and do it. But info sec is different for every company and individual.
Bruce has basically admitted that the dashboard was something they didn't have that they needed to compete and it was rushed into production. I am not in beta but from what I heard/seen/read. A handful of those issues will be fixed in 2.2.4. And now with SSL being effectively an unsupported feature, I think hubitat is on the right path.
I am still not a fan of their cloud implementation. Its easy enough to block the hub from the internet and only let it talk where and when it needs to.
Other IoT devices in the house spying, such as NSA spying.
Simply and parranoidly put.
Google Will NOT allow you to use VLANs. So, that is a big one right there.
This has definitely come up in the past and I've probably engaged in discussions on it too.. what can I say, I like to be contrary on occasion and have a bit of a discussion 
Yeah there isn't anything you've said that I disagree with, you are on point, and I very much agree with your above assessment.
My professional life is centered around more of the infrastructure/end point/network security aspects and very little around anything appsec focused, so some of that may color my thought process.
Now for my opinion, to take advantage of the lack of SSL, an attacker would have to compromise some device that is capable of network sniffing and be positioned appropriately on my network to pick up on such traffic. Which really is what depresses that likelihood assessment for me personally. I'd also suspect that many IoT devices don't even have the necessarily functionality built-in to their underlying OS to even facilitate packet capture.
When I think of SSL in the grand scheme, outside of just the world of Hubitat, I'm not sure I can think of any attacks that I've responded to, investigated, researched, read about, etc where a lack of SSL had any sort of impact (that's not to say it hasn't, I'm sure it has, I've just never encountered it). It's just not generally the path that the majority of attackers go down in my personal experience. If you're a target of sophisticated attackers, there's also much better places to spy on you to capture useful information then capturing your Hubitat's HTTP traffic. Don't think the NSA (or any government entity) is really going to care about our home automation stack.
Now all that being said, definitely should implement it on the hub. It's low cost, adds some level of protection, and is the right path to take for modern security conscious products (and especially considering things like Hubitat dashboard).
But in the context of this thread, what it comes down to is I personally don't feel the need to go out of my way to utilize a beta feature. It has some bugs and hasn't been worked on heavily recently (as far as I know). Given it's status as unreleased/unannounced beta feature at the moment, so I would anticipate some bugs until it once again becomes a priority. One day when it's released, I'll use it because why not!
But that's just one random guy on the internet opinion and isn't meant to detract from those who want to make use it.
My big issue is we have all of this new security capability in Z-Wave with S2 join etc, but even if I set a username and password on my hub it's sent in plain text on my network...
Security is a compromise of convenience. In order to have HTTPS you cant rely on the app for dashboards.
My recommendation is to not use the mobile app for dashboards. get a cert install it using the "Extended beta"
then just use a browser to access dashboards. I have a main menu dashboard that is mostly links to other dashboards. I share that out to the family and the can access what they need.
I don't use the cloud dashboards. (In fact I don't let my hub talk to the Habitat cloud.) We only use dashboards for a few minor things anyways.
If I really need to do something while away. I have VPN.
[Sorry, this touched a pet peeve...]
In regard to sniffing, the weakest point in your network is your switch or router itself. Many home devices of this nature can be simply summarized as a security disaster. Even reputable devices like Cisco have had important security vulnerabilities. Most all of these devices have some form of SPAN or Port Mirroring.
Ripple20 is a good recent example. It hit a lot of switches. The higher reputation companies have been forthcoming, saying "yes we're vulnerable, and we're working on getting fixes out." Many of the lesser companies have simply been silent on the issue. Not a good indication.
And of course until just a few years ago, many devices of this nature were engineered with a "recovery" backdoor builtin. Lot of those devices still out there.
Network Security Rule #1: Always assume a bad actor has access to raw network traffic.
End to end encryption is your friend.
Download the Hubitat app
