The way the Companion App supports CA Signed Certs is quite complex: you have to install a CA, generate a cert and install it in HA, and then install the CA cert in your phone. It’s not that’s impossible, it’s that this is too much for the average user, they just don’t do it, and this is forcing http to be the default.
Agreed! But the point is that, for authentication, the https+no-cert-check is still (much) higher standard than http.
There I disagree. VPN provides you with good encryption until the VPN endpoint, which is (most likely) not the HA host. From the VPN server to the HA server, the stuff goes in clear-text if you use http. Moreover, if you don’t check certificates on your VPN connection (which the client allows, BTW, unlike HA Companion ), authentication is equally bad, but still better than no certificate at all.
Yup, but it also provides authentication at the VPN endpoint, so you get an extra layer of protection and a VPN software is nearly always security over convenience and often also limited to just this purpose, so the code reviews are easier.
The issue with HTTP communication from VPN endpoint to HA is still better than just HTTPS directly to HA, because there is a better authentication in an extra layer, and it can still be fixed with the normal options for HA, if need be.
VPNs have many options and you can also run with client certificates if you want, which I think is a bit harder to set up with HA.
this is actually common android practice, the reason why it feels unique to the HA app is because the users provide the servers and are ultimately responsible for their network setup and SSL etc… Most apps who provide their own server they do all that dirty work for you but teh HA app must allow users to import their CA as that is the only way it will work.
which is exactly why nabu casa exists to make it easier on them but to be honest there are lots of automated methods to make it simple and free now that existed before NC was created.
The most widespread VPN server, OpenVPN, does not do any of this. It will accept a non-checked certificate; it will show you a warning, but will go with it. Same with Synology Drive, just a warning if it can’t check the cert. Same for DavCal, same for ownCloud. Same for Firefox, Chrome and all browsers in the world: they see a non-verifiable certificate, they warn you, and they allow you to browse. The only notable exception is the HA Companion App, that would rather have users go with http than https without a verifiable cert.
No sorry, it’s not common practice. I am an advanced user and android developer myself, and the only time I had to install a cert in my phone was for checking taxes. Apps can’t do it without the user permission, and I’ve never been asked for such permission.
for our app it is as the servers are the user’s responsibly and there is a big variation between installations and networks etc… As Google’s recommendation we accept user imported CA’s
Please read it again; Google is not recommending you to accept user-imported CAs, but they give you an instrument to explicitly allow it if you insist. The github code you point to is exactly this: it’s Android’s way to allow for that exception. If you don’t put this piece of code (as in any Android app by default) the mechanism you suggest won’t work.
Interestingly enough, if you scroll up a bit, the first sentence of the developer .android .com website you refer to reads “Client-server encrypted interactions use Transport Layer Security (TLS) to protect your app’s data”. HA Companion App is not following this recommendation. From Android 9 (that’s a few years ago) you have to enable an exception in the app’s manifest in order to avoid an exception if you connect to an http-only url. Please check this website:
Obviously, HA Companion App has this non-recommended ‘usesCleartextTraffic=true’ flag enabled, otherwise it would not work. You can find this exception in the HA Companion App code in the same github link you pointed to.
In a nutshell: The companion app uses an insecure exception to allow http-only traffic, and another exception to allow user-defined certs.
Please don’t get me wrong: getting this thing perfectly right is difficult, and for a home server it’s even more difficult. The best is to work with verifiable certificates, and the worst is to work with no SSL at all. What we are asking here is to please allow us to work in the middle.
Think about it: once the Companion App allows this feature, the HA server can start using https by default in all installations, with most clients with the no-check-cert exception and few with the real certs… because requiring real certs everywhere is unthinkable, but deploying new installations automatically with self-signed certs is not) and then nobody will be without SSL. And once HA server uses https by default, you can disable the ugly usesCleartextTraffic=true workaround in the companion app. Wouldn’t this be good for Home Assistant?
but again its up to the server(user) to set it up, the app supports it
we have to, default HA server is http when you install it, SSL and the rest is added later but it is not part of default config which we need to support.
Not by default. The app supports it only if you are an expert user and use an exception almost nobody else uses. If you have a valid cert (e.g. letsencrypt) but the DNS does not resolve it right (because of LAN access) the mechanism doesn’t work, but I’m sure it doesn’t in many other cases. And of course, the standard user will not use it because it’s not enabled by default.
Well, then instead of pointing fingers to the HA server, why don’t you give them a path to change the default? If the companion app does not support unverified certs, they won’t be able to move to https either (and point the finger at the companion app)
I just got myself a Home Assistant Green wanting to replace the crufty Loxone and KNX hybrid in my home.
After being dumbfounded that in 2024 any app would use HTTP by default (even if LAN only [1]), this discussion here seriously gives me a pause.
For myself, yes, I could go mess with automated DNS challenges, but I truly feel like I should not have to just to banish HTTP from my LAN. FWIW, I’ll use wireguard for remote access - thankfully also without any signed certs.
I think this feature really needs to be implemented. I don’t understand why it still has not been considered valid by developers.
What several people in this thread (me included) are asking for is different from what the HomeAssistant app currently supports. Previous messages tend to show there is a misunderstanding about that.
Currently there are three options regarding TLS:
Use a certificate signed by a “public” CA, i.e. already installed in most devices.
Pros: Limited configuration needed; provides encryption and authentication.
Cons: Requires a constant Internet connection to automatically renew your certificate.
Build your own CA, trust the root certificate on your device, sign a certificate for your HomeAssistant server.
Pros: Provides encryption and authentication.
Cons: High-maintenance; complicated; increases the attack surface of your device (if your root certificate is compromised, any app that trusts user-installed certificates is exposed to MitM attacks).
Accept HTTP unencrypted traffic to your server.
Pros: Well… It’s easy? I guess?
Cons: No encryption or authentication; just terrible security.
I voluntarily keep any option involving VPNs out as it only shifts the problem in addition to being very high-maintenance and (I believe) inaccessible to most users.
The fourth option expected here is:
Use a self-signed certificate and have the HomeAssistant app let you accept or refuse it.
Pros: Limited configuration needed; provides encryption and authentication.
Cons: Moderately complicated; not as good as the first option security-wise.
I have also been using my own CA for many years. I have tried to set it up according to the documentation. Unfortunately, it only doesn’t work in the Home Assistant app. I therefore had to switch to an unencrypted Auth. The server is only accessible via VPN, but it’s not nice.
), authentication is equally bad, but still better than no certificate at all.