I don’t believe that’s his role as a moderator.
1 Like
Please understand that we are here to moderate, nothing more. The Nabu Casa team or volunteers are not obligated to reply on feature requests. Please understand this.
2 Likes
Hi. I spent the last two days going through discussions, denied pull requests, documentations and so on, trying to find ANY way how to securely use companion app outside of LAN and without VPN. By securely I mean some additional layer other than HA’s own authentication.
I know about the official cloud support and Cloudflare tunnel, but both options have the same issue: when (not if, but when) there is a security hole that allows an attacker to get into HA without an account, the only thing protectecting me is the obscurity of the domain name. And because the domain is visible both during a DNS request and initial stage of TLS, it can appear in some logs and escape, to be abused later.
Cloudflare tunnel at least allows me to limit the access to certain countries, but this is far from ideal. So I wanted to add some additional layer to help at least a bit. Doing it for the web interface is easy, the problem is with the companion app. What I tried, without success:
- Client certificate / mTLS. This seems to be doable on Android, but doesn’t work on iOS.
- Custom headers - no go, the companion app doesn’t allow setting them up.
- HTTP Auth - not supported, doesn’t work.
- sub-path (https://ha.domain.com/some-secret-path/) - not supported, not planned, and essentially just a workaround to have “at least something”
All those options have been raised, some even had a PR that were denied. Only mTLS is showing any sign of being somewhat usable, the Android and WearOS side sees some activity that’s accepted, but the iOS side is deadlocked as this thread shows.
Is there any other option that I missed or there is simply no way than an always-on VPN or hoping for no bad stuff happening? 
(As for the repeatedly mentioned things like Nabu Casa not having a motivation… They could offer this higher-level security as a paid option if needed, and one bad zero-day would make lot of ugly media articles → hitting their bottom line. So I don’t think that they don’t want to, it really is complicated to make it work reliably for everyone as oposed to hacking something together for my particular usecase.)
8 Likes
“They have already addressed”
“I dont like and I wont do it, k thx bye”. And closing the discussion because they know the community will keep insisting for it.
That is not a mature answer for a project this size being very honest. But as said, no one can gunpoint them to accept a merge into the codebase (which for me is the weirdest part as the code IS already done)
2 Likes
Please stop replying to me. I don’t care and have unsubscribed from this topic.
4 Likes
Also very interested in this feature. The often referenced pull request in the thread stated that this forum was the place to voice our opinion and suggestions, so I’m hoping with enough supporters, this can gain some traction.
5 Likes
I’m also very interested in having support for secure client certificate authentication (mTLS) in the iOS app. While I understand that there are alternative solutions like VPNs or Cloudflare Tunnel, mTLS provides a unique layer of security by enforcing device-level cryptographic identity in addition to traditional authentication.
It would be great to have this as an optional advanced feature for users who want to run their Home Assistant instance with stricter security policies, especially in self-hosted setups where exposing services externally (even through secure tunnels) may not be ideal.
That said, if full mTLS support isn’t feasible, even a smaller feature like support for custom headers would be a very welcome addition.
Both of those configurations could be tucked away in an “Advanced Configuration” section to avoid complicating setup for less technical users, while enabling power users to inject additional security tokens, device fingerprints, or custom authorization headers for backend validation. This could offer a good middle ground between security and usability.
I really appreciate the work being done on the app, and I understand that implementing mTLS or advanced header controls adds complexity. Still, having the option to opt into these features would significantly expand the flexibility and security of the iOS client for those of us running hardened environments.
7 Likes
To why they didn’t want to do it, Frenck answered here:
These methods add complexity and maintenance burden to our project for a quite complex feature, a niche/lesser wide spread in use
Who would have thought it’s such a niche use-case to have your home automation platform not become part of a chinese botnet…
My current perception is that HA seems to recurringly not dedicate time to security practices that prevent potential security issues from having impact.
As for the maintenance burden, AFAICT we’re talking about 300 LoC in files that are touched once every 2 years, which in my experience is not significant, but I may well be mistaken on that that’s all there is.
There are alternatives that do work, including VPN, tunneling, port forwarding, or Home Assistant Cloud. Therefore, we’ve decided not to support this case.
So let’s have look at these alternatives.
Port forwarding
I understand this suggestion as “Just open HA to the internet by forwarding the port on your router”.
I tried that for two weeks. It only took days before logs of chinese bots trying to get into my HA instance, both on the login page and SSH, showed up.
In the light of security issues like this one:
It is clear that just opening HA to the internet and relying on its login page is not acceptable given the amount of sensitive information that the HA instance has access to.
If it means anything else than "Just forward the port on your router” (or any other similar un-authenticated port forwarding such as Cloudflare), then I’m having a hard time seeing how that would be distinct from “tunneling”.
Tunneling
Via SSH is hardly going to be possible (or practical) on an end-user device. So I assume you mean by VPN? In which case this means the same thing as just “VPN”, and it’s unclear to me why it’s present as a distinct suggestion.
VPN
VPN requires your device to join a whole new virtual network just to access one actual service (HA), is annoying to maintain on end user devices (extra apps…), you can’t run several at the same time, you need to be concerned about routing of regular requests not going to there, some devices will disallow VPN…
Overall, it just seems overly intrusive and complex a setup to have on every device that needs to connect to HA.
I have 9 devices I regularly use HA on, Linux, Windows and Android.
Asking to set up and keep running the distinct VPN app on each of them just to be able to connect to HA every once in a while is very impractical, compared to just being prompted for certs on the first use of HA, and then never again.
Can you imagine if for every quality-of-life app you install you had to make sure you were connected to their dedicated VPN before you open it?
Home assistant cloud
I’m going to exclude this one because it’s claimed that they are not otherwise preventing secure connection in order to sell HA cloud.
mTLS
mTLS is a one-shot setup. You’re doing HTTPS anyway. Just provide client certs as well during the TLS handshake.
Immediately deny any unauthorized connection directly on the battle-tested nginx instance before it’s even forwarded to python code that’s potentially vulnerable to authentication bypass or even DOS issues.
It’s just the simple clean secure appropriate technology for this problem.
The main issue left
AFAICT the main actual issue left is this:
Additionally, we know it will not work for all use cases, basically dragging along “known bugs” (like background sessions).
which is also mentioned in the PR description:
Client certificates do not work with URLSession background sessions – this may be a dealbreaker, especially on Watch or eventually in Widgets
which would cause support burden.
I would however argue that most people who have an iPhone don’t also have a watch, and that getting the app working is more important than getting the widgets working.
To cite the above comment:
Anyway just my two cents, if they don’t want to give us mTLS at least fix the security issues found with quick scans by open source tooling so not having mTLS is less of a concern.
I would reverse that. If you (understandably) cannot dedicate the time it takes to review every security issue that is brought in by all the dependencies of the project in addition to HA’s own potential vulnerabilities, then just allow users to put an mTLS layer on top so that whatever these vulnerabilities are they aren’t exploitable.
Boy I sure am glad that I have an Android device…
A glimmer of hope
https://github.com/home-assistant/iOS/discussions/3676#discussioncomment-13582849
3 Likes
I’m also really looking forward to this feature being added to iOS at some point. It’s a shame the pull request was closed. I really don’t think such a standard feature could bring about much maintenance burden, only needing rework if the corresponding platform reworks its networking stack. I also don’t see how this could hurt Nobu Casa’s remote UI product, since it operates at the TCP level. Client certificate authentication support would only enhance its security stance. In fact, this feature is one of the main reasons I don’t want to expose my HA instance to the internet through their cloud product and instead just use a VPN to home - I don’t want the login page to be the only layer of authentication to software that controls so much…
1 Like
Here to support this feature. The other proposed alternatives have worse tradeoffs for my use case.
1 Like
It’s not as good as mTLS, but an easier alternative is to add a custom HTTP header in the requests sent from the iOS app. The value of the header would be a random string generated on first app launch and shown in settings. Then Cloudflare, nginx, or even HA itself could be configured to reject requests without specific value(s) of that header.
An example header:
Home-Assistant-Client-Id: M4HLZwRLcp0QMteDoiRCg3fj7XiZmu44
It’s not mTLS, but it might just be good enough.
5 Likes
I second the suggestion to add the ability to allow users to add a custom header. This would be a dramatic improvement on the current security posture whilst - I believe - fairly trivial to implement. Happy to be corrected on that, but seems to work well for other applications.
I’m also very interested for mTLS. I wanted to add it to my HA stack before reading this. It’s sad that it exists on Android and not in iOS.
I understand that adding mTLS to the code add complexity, failure points, support, tests… but the code become also more and more complex, and one day someone will find a breach.
I’m still thinking about exposing HA on internet (with reverse proxy, TLS…), maybe with a WAF in front ?
I remember spending half a day trying to get mTLS working on my iphone. I’d seen some claims that it worked (obviously from “Android people,” but I didn’t know that). I finally found peace of mind with a VPN, but only after all the following conditions were met:
- a static public IP address
- VPN support on the router
- right VPN program (Wireguard) that connects instantly, stays connected for hours and supports iOS profiles to automatically turn VPN on/off
So yeah, the option to strengthen default security would be very welcome.
any news about mtls in ios? for remote access i’ve set up a subdomain to my home assistant in nginx proxy manager with mTLS and works perfect in safari. but i can’t use that access in my iOS HA app.
1 Like
hope this 8 years dream could come true…
1 Like
Also voicing my support for this.
For all the above mentioned reasons, my current setup requires mTLS for external access. As an unfortunate side-effect, Homeassistant is not reachable externally through the app by iPhone users in my household.
1 Like
Apparently Feature requests been moved to Github, so the new link that we can vote there
1 Like
I’ve resorted to uninstalling the companion app and using HA as a WebApp. At the very least, this gives me mTLS + notifications, but it’s clearly not going to be sufficient for many users.
did exactly the same. after trying to create some decent security through cloudflare and mTLS I ran into this issue on the companion app. Stuck on the web browser only now. The more effort I put into HA, the more security is needed. I don’t see another comparable method that is as secure and simple to use.