Secure communication channel for iOS app

Feature Requests
,
1

Hello,

this post is an effort to convey the interest from the community in having the possibility for securing communications between the iOS app and Home Assistant installations.

The security requirements that such a feature would ideally satisfy are the following:
R1) To be configurable in such a way to impact only the traffic between the app and the server
R2) To allow management of the server-side security not necessarily inside Home Assistant, but also in a separate way
R3) Allow (and rely on) best-practice use of standard cryptography algorithms

The standard technical mechanism that would satisfy all of the requirements is mTLS.
It is already supported in modern browsers and in the Android app, just the iOS app is missing.

A pull request for implementing this has been rejected. I would kindly ask that this decision be reconsidered, or that another way is studied for bringing this feature to the iOS app, based on the following:

  • Reactions and comments on GitHub clearly indicate the community desires
  • The iOS app is the only client which lacks this feature
  • There are no other solutions which offer an equivalent security level, while respecting all of the above requirements

If, for some reason, the implementation/review/maintenance effort for such a feature was deemed to be not sustainable, I would please ask that allowing the configuration of custom HTTP headers in the app be considered as a fallback solution.
For this feature there is also a reference pull request which was not merged.
I think the key point here would for a user to be able to configure authentication headers before logging into an instance of Home Assistant, for being able to have a reverse proxy perform authentication in a transparent way (requirement R2).

2

I’m looking very much for a feature like this. I think I’m not alone who exposed the HA installation via NGinx and Cloudflare. I’m looking for this extra layer of security since years. The maintenance of an extra HTTP header variable or a client certificate shouldn’t be that complicated. If it makes it simpler, this can be a pure client side configuration, then the certificate or header validation can be implemented in the reverse proxy.

3 Likes
3

Pasting part of my comment from the PR below:

A few times and in a few places the maintainers have mentioned a “complexity and maintenance burden.” This is definitely true on some level, so as a community we should try to figure out a way to make that work. There have a been a few pull requests to allow custom headers or certificates at this point but no offered solutions for how to maintain that complexity over time.

@frenck @bgoncal it would be great to get some comments from maintainers on how we can relieve the maintenance burden since this is such a highly requested feature. I think some of the more heated comments on GitHub come from frustration with the way these large and rejected features are handled.

For example, when a PR is closed with comments like “upstream rejected” and then “we don’t want to maintain this” and “move this discussion somewhere else” (where maintainers don’t always reply), that sends a different message than saying “we want this feature but we don’t have a process for maintaining this feature right now, let’s leave this PR open/hold reviews until we do. We are actively discussing how to support this here…” If I am understanding correctly (from past comments from maintainers), the issue isn’t actually the code in the PR or that the feature isn’t wanted–it’s that there isn’t a process to deal with it once it is in the codebase.

Which brings me to the next question: where is really the right place to discuss this? As mentioned by others, the forums often end up as a void for process issues like this if the maintainers are not already actively working on it. The maintainers have made it clear that GitHub code repo issues and PRs are not the place to discuss issues with the processes of accepting features (often close and lock). The GitHub discussions of the iOS repo have been active but have not led to maintainers reviewing this issue. I know that the architecture repo exists, but with this particular issue the maintainers have not directed anyone to post there.

Supporting more authentication methods and certificates are the most voted on features in the iOS repo GitHub (as of writing this post). I think a lot of community members would appreciate some official progress of some sort on this issue instead of the continual shutdowns we have seen so far. This leads to a lot of frustration, and I don’t think it is good for our community as a whole. It is sometimes difficult to read some of the PR and discussion comments, and while I do not condone some of the behavior and comments we have seen, simply locking a thread without progress on an issue does not help to quell the situation in the long term.

I really mean all of this constructively, and I hope it is interpreted as such. I understand that maintaining such a large open source project is a massive undertaking, and of course everyone appreciates where we are and how we got here. There will always be features with maintenance-strings attached like this one, so having a process to constructively find solutions for these maintenance burdens is something that would be very helpful in the long run.

Thanks for your consideration!
Perry

4 Likes
4

Should I tag people?

5

Hello,

I am also interested in this feature, whether through mDNS certificates or by introducing custom headers to enable compatibility with Cloudflare tunnels.

After reviewing the comments in the related PRs, it has become evident that the responses from the developers are not being provided from the perspective of Home Assistant developers, but rather as representatives and owners of Nabu Casa.

1. Lack of Open Discussion

It is clear that the developers aim to restrict discussions regarding features that potentially conflict with Nabu Casa’s business model. For instance, the unilateral decision to close all related topics without providing an explanation, and merely redirecting users to this forum, is a clear method of limiting discourse. How many users who have already been blocked on GitHub do you truly expect to come to this thread and express their interest or feedback?

While some comments may have crossed the line, the core argument presented in those discussions remains valid. Do you believe that users who have been censored will return here to engage in further discussion?

2. Complexity

If complexity is indeed the justification, this argument could benefit from further elaboration. Why exactly is the implementation of mDNS considered complex? And in the case of custom headers, why is it challenging if the solution merely involves passing the headers forward without the need for interpretation?

By not expanding on these points, it gives the impression that this complexity is being used as a generic excuse, hoping that those without technical expertise will believe that it’s as complicated as stated. After reviewing the PRs, even with limited knowledge in iOS development, the code did not appear overly complex to me.

3. Maintenance Burden

As mentioned before, this argument could also be expanded. The code for these features has already been developed by third parties, given that the team has chosen not to allocate time to it (which is within their right). How, specifically, will this feature impact the maintenance of the app? Updates? Framework changes? Concrete examples would help clarify this concern.

Moreover, as this feature is of significant interest to the community, there are multiple ways to mitigate the maintenance burden. While I haven’t fully explored all potential solutions, one straightforward suggestion could be to request a minimum of three (an odd number) technically qualified community developers to act as contributors for this specific feature and maintain it long-term. With three individuals involved, there would be sufficient capacity to manage the feature, make decisions, and ensure continuity in case one contributor steps down.

The best part? If they fail over time, you will have validation for your argument, and this discussion can be put to rest, serving as a precedent for future cases.

4. Conflict of Interest

Lastly, the separation of Nabu Casa from Home Assistant was meant to prevent conflicts of interest, correct? However, despite official denials, the current situation strongly suggests otherwise, as discussions are being closed and blocked unilaterally.

In an open-source project, I believe the community should have a stronger voice in advocating for features that are important to them, even if the core team is against their implementation. If a significant number of users—potentially millions—need a particular feature, should it be disregarded simply because an individual or a small group of founders disagrees? This does not seem fair or aligned with the ethos of open-source development.

I hope you take this critique as constructive and reconsider the current approach.

5 Likes
6

I agree with the above post totally. I find it disingenuous that the senior members of the HA team are trying to say that it has no relation to commercial gain…

The only thing that I think needs to be added, is that consideration needs to be given the reliability of the Nabu Casa network, there should be other options that also add greater reliability.

7

I that were the case then why do they allow and actively support the use of alternative free remote connection methods?

DuckDNS
Cloudflare
Tailscale
etc…

Your statement lacks credibility.

I do not understand this statement at all. I can count the outages I’ve seen on one finger. It’s extremely reliable.

8

Before the Nabu Casa rework in 2021, it had hiccups. It’s been rock solid since that rework. In 2 years I’ve had 0 outages.

9

I have already commented my viewpoints about these methods on one of the Github discussions, but I’ll repeat them here as well.

VPN
I don’t think that making HA clients use a VPN is at all a suitable or convenient solution. If you chose this option, you must chose one of the following drawbacks on top of the added complexity of running a VPN server:

  1. Always-on VPN - significant battery drain on mobile devices and extra overhead on traffic
  2. VPN to be connected when user wants to use HA - even more inconvenient, more confusing (especially for family members)

Exposing to the internet and using dynamic DNS
This is an incredibly bad idea from a security standpoint. If HA controls devices like your security system, door locks (or even heating!), exposing it to the internet with only a username and password to restrict access is sheer lunacy. Alongside the usual concerns of password cracking,intercepting,etc, if there are any 0-day vulnerabilities in the HA source code then your smart devices are immediately vulnerable and ready to be attacked by anyone locating internet-exposed HA instances using the readily available data from scanning systems like Shodan.

I think that out of those methods listed, the only suitable one would be using Cloudflare Tunnels (formerly Argo Tunnel), combined with Cloudflare’s Zero Trust platform to provide some kind of more secure authentication.

… or even simpler and avoiding exposing decrypted plaintext traffic to a company like Cloudflare - use mDNS. Users are silently authenticated in very secure manner, mDNS authentication is almost universally supported. Client keys can be stored in a flexible manner, allowing for even more secure options to be used (eg: hardware security keys like Yubikeys). Zero days are automatically defended against unless the vulnerability is in the webserver itself. There is very little complexity and little traffic overhead.

I would really urge the maintainers to reconsider on mTLS and bring Home Assistant remote access up to 2024 security standards.

4 Likes
10

Personally I find the entire lack of security awareness concerning by the home assistant leaders. Multiple fumbles of the security ball from the LAN vs. WAN account disclosure issue in 2023.12 to the fact that the codebase itself does not contain a strong set of code security scanning tools (CodeQL is the only one mentioned that frankly has minimal support for python code)

I am very much of the opinion that home assistant needs to more strongly consider compensating controls that better protect their platform and ultimately if they more heavily invested in security tooling I’d be less inclined to care about mTLS.

For example, why does home assistant not have:

  • Comprehensive SAST scanning
  • Compressive DAST scanning
  • Well defined and published OpenAPI spec for schema validation
  • Container scanning (current Trivy/Grype results below)
    Trivy:
homeassistant/home-assistant:2024.11.0 (alpine 3.20.1)
Total: 28 (UNKNOWN: 2, LOW: 4, MEDIUM: 12, HIGH: 6, CRITICAL: 4)
Grype:
 Scanned for vulnerabilities     [133 vulnerability matches]
   ├── by severity: 17 critical, 61 high, 47 medium, 3 low, 0 negligible (5 unknown)
   └── by status:   105 fixed, 28 not-fixed, 0 ignored
  • SBOM generation and vulnerability assessment
  • Third party auditing of security posture and practice of both the codebase and Nabu Casa

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.

2 Likes
11

I think in terms of client certificate auth support there are three slightly different factors/integrations at play:

  1. The most basic is home assistant mobile app allowing client certificate auth. Note, according to the brief review you would need to install this certificate in the system store in addition to the standard one to get background network connections to work (that is at least as of 2022 per: Passing NSURLCredential in XPC con… | Apple Developer Forums ). Further it may be impossible to install it for background use without home assistant adding the code to register the certificate per: Technical Q&A QA1745: Making Certificates and Keys Available To Your App Again both resources are from years ago so it is possible things might be easier now.

  2. More complicated adds the ability for passphrases to be entered for client certificates. Not sure how many people need this feature given the annoyance to the user every time the passphrase is needed. I doubt this is a huge portion of the people desiring certificate auth.

  3. The ability to use the client certificate identity to automatically log someone in to home assistant. This is a nice feature but adds more logistics in terms of custom authentication options on the server. It might be possible that if #1 was done a 3rd party could (at least via HACS) write the auto-authentication side of it. Still given the fact you can configure long life sessions for home assistant logins the fact the user would have to install the certificate on their device and login once doesn’t seem like a massive headache.

I think the big benefit of optional client auth is the fact home assistant isn’t required to be doing the initial auth layer from a server POV. With client auth the proxy server handles that, making the potential attack surface much much smaller. Obviously VPN is an alternative where you also then bind home assistant to the internal VPN ip only but certainly far more overhead and install requirements than simple client auth.

Given the fact a PR was put together previously and rejected due to not wanting the maintenance requirements I would focus on #1 most of all. It isn’t clear if the dev team would accept something scoped to that or not in terms of a PR.

12

I was replying about the validity of DrSpaldo’s conspiracy theory, not the validity or otherwise of your request.

13

Sorry, my mistake! It’s just that those methods seem to be the “valid alternatives” quoted every time the PR for client certificates is swatted away, and I wouldn’t actually say that they are valid from a security/convenience standpoint :frowning:

14

Yeah its quite sad the direction this has taken where it looks like motivated community members are just ignored for reasons which are not fully understood.

I can at least report that with iOS 18 the client certificates work very well if you add your Home Assistant instance URL as a WebApp to the HomeScreen.
Sadly this cannot provide all the features the App has like e.g. CarPlay, NFC, location tracking or updating the phone sensors in Home Assistant.

For some of these it would be possible to build workarounds like using an alternative notification method but others are harder and I’m not sure if that’s worth the effort.

As a positive example I can for example mention the iOS Paperless App which some time ago added just this feature to add additional headers so you can add a second protection layer in-front of your own server.

Sadly it’s not so easy on the iOS platform to just fork the App and add those features due to stricter requirements by Apple for certain entitlements like CarPlay.

1 Like
15

As @ttobias mentioned, the implementation by the Paperless app is great, he listened to our requests to add the additional headers and it is working great for me

Apologies @tom_l, my humour missed the mark. It is alright if we don’t agree on everything, I still very much appreciate the work you do for Home Assistant and the community.