Secure communication channel for iOS app

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).

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

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

Should I tag people?

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

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.

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.

Also the technical reasons for not implementing the PR were given by Frenk in the PR. Do not be surprised if this FR is closed as “Wont implement” for those reasons.

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

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.