Allow supplying client certificates #2144
Conversation
zacwest
force-pushed
the
master
branch
2 times, most recently
from
a931580 to
ddc0982
Compare
|
@zacwest are there plans to drive this forward some time soon? Apologies, I am unable to contribute personally, however this would be highly advantageous functionality for bolstering security for HA when exposed to the internet. |
|
@zacwest Thanks you for your job. |
|
@zacwest do you have any information when its planned to get that feature? Thanks in advance. |
|
I would definitely benefit from this feature as well! Client side cert is a solution much easier to deal with when you need to secure your public ha endpoint |
|
@zacwest I found a very promising demo: https://github.com/MarcoEidinger/ClientCertificateSwiftDemo/tree/main |
|
Anny plans to integrate this in the near future? |
|
Upstream rejected |
|
Any comment why? |
|
Additionally: What upstream is meant? Can we please have a link to the relevant upstream issue/feature request/PR/...? :) |
|
We have decided not to include support for client certificates in this case, as we also didn't add support for other custom auth methods. These methods add complexity and maintenance burden to our project for a quite complex feature, a niche/lesser wide spread in use. Additionally, we know it will not work for all use cases, basically dragging along "known bugs" (like background sessions). There are alternatives that do work, including VPN, tunneling, port forwarding, or Home Assistant Cloud. Therefore, we've decided not to support this case. |
|
Can you support external login pages with cookies? This would let me use CloudFlare tunnels with regular auth:
This would be much simpler, and would add a lot of flexibility for security. |
That is not related to this PR. If you want to request a feature, I would recommend opening up a feature request on our community forums. 👍 ../Frenck |
|
Why is it working successfully in the Home Assistant Android app with mtls, and is it not supported in the iOS app? Why this feature discrepancy? |
Also wondering if that means it will be ripped out of the Android app. |
Unfortunately, that was added in the past. However, decisions made in the past do not define how we look at things today.
Unrelated to this PR; however, there are no direct plans for that. ../Frenck |
|
Just adding here as well as the other discussion about mTLS: Someone was suggesting a HTTP basic auth header that could be added as an alternative authentication method to mTLS. The header would still be sent inside the HTTPS connection, and therefore reasonably secure. Both of those sound really good - obviously the HTTP header is less desirable as less secure but still much better than just having the instance exposed out to the internet! I know that VPN tunnel is always quoted as the viable alternative to mTLS, but it really isn't that practical to have a VPN tunnel running on all of my family members devices 24/7 (less reliable, more maintenance, faster phone battery drain). I personally couldn't care less about the Apple Watch functionality, etc. that I would lose and would happily forgo this for the greatly enhanced security. Really hope that the developers will give these options another look! If the only way to have this working without a VPN is just exposing to the internet, I would hesitate to give homeassistant access to anything more than a smart lightbulb, let alone unlocking my front door, etc! |
|
Basic auth is not possible in combination with the Bearer auth already in use. Custom headers were proposed (and closed) in a different PR: #2596 |
|
That's unfortunate that the proposal for basic authentication headers was rejected - I wonder what the reason was? I don't think there would be an issue with the bearer token auth that homeassistant uses, as I think most people are wanting to get their reverse proxies to check this HTTP basic auth header, rather than getting homeassistant itself to check it. Therefore the HTTP basic auth header would just be yet another header in the request that homeassistant will just ignore, will it not? If there is really an issue with homeassistant being presented with this header, the reverse proxy could just strip this header before it proxies the request. I feel like the only barrier here is getting the app to send the basic auth header with its requests. Sorry if I've missed anything here - only just started using homeassistant! |
|
@lriley2020 PR #2596 is for additional custom headers, not Basic auth. Basic auth is not possible due to a technical limitation. Home Assistant uses HTTP Bearer auth for its existing authentication. HTTP Basic auth makes use of the same header used for Bearer auth. Technically both are supported simultaneously in the HTTP specification but practically nothing supports it (clients, Nginx, etc.). See more discussion here: #193 (comment). Client certificates (this PR) or custom headers (#2596) would allow for an additional and separate authorization/authentication layer. |
|
Ah right, thanks for clarifying :) I can maybe understand the reluctance to introduce client certificates to HA as they break some features and it sounds like Apple hasn't made it the easiest task in the world. However, custom additional headers seem quite do-able - I wonder why the PR (#2596) got rejected? |
|
Hi @frenck, can you confirm whether or not this PR was rejected due to commercial reasons? I am of the belief that this PR was rejected not necessarily due to code reasons, but because it could potentially abstract revenue. |
"There are alternatives that do work, including VPN, tunneling, port forwarding, or Home Assistant Cloud. Therefore, we've decided not to support this case." ^-- don't think he could have said it any clearer. |
|
I doubt that the idea was rejected due to commercial reasons, although I would say that Home Assistant Cloud is the only solution on this list that offers both a "plug and play" style solution and also has decent security. The other solutions mentioned fall short in one of these categories (ie: VPN/tunnelling adds more complexity and will be less reliable and many VPN protocols blocked by public networks - therefore not very "plug and play", port forwarding is very insecure if the page sitting behind the exposed port only requires username/password authentication and there may be undisclosed 0 days in the software - therefore falling short on the security aspect) |
I would argue that Home Assistant Cloud is essentially the same as opening the ports on your router, with a frontend for a HTTP based proxy with rules that will redirect a hostname that is essentially is a hash like No one's gonna be able to guess your domain, but if someone does manage to enumerate it, you're still screwed. |
|
Ah, my mistake! For some reason I thought there was a better security model on the HA cloud option. So a custom HTTP authentication header or mTLS would definitely be the best possible options. |
|
It's a shame that neither mTLS nor custom auths (like adding customer headers for CF tunnel bypass) are accepted. |
|
For iOS devices there is this workaround. I tested with CloudFlare ZTNA and email code verification. |
|
@frenck @bgoncal after 6 months, is it possible to reconsider the decision on this? @lriley2020 has greatly explained how mTLS would be superior to using a VPN in terms of reliability. |
I'm sorry to hear you believe that. It isn't the came. That statement makes about 0 sense, considering we support A LOT of possibilities out of the box that does not need the cloud services by Nabu Casa at all.
There are currently no plans to reconsider this decision. This is also not the right place for these discussions. This is a pull request that has been handled and closed. If you want to discuss possible features or drop feature requests, please use our community forums instead. There is a dedicated forum there for discussing features and wishes. ../Frenck |
This comment was marked as abuse.
This comment was marked as abuse.
|
@alexandre-leites while there is clearly a lot of push for this feature (myself included), please do not make this personal or an attack. There is never constructive output from that. 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. Personally I would argue that client certificates are a better solution than headers since there are fewer ways to use it (i.e. not a million auth provider possibilities) and it is already usable for the Android app. Maybe something that would be helpful is if someone created a library or layer external to the Home Assistant app that could be included as a resource for uploading and maintaining the certificate list. This would take some burden off of the maintainers here. That is the main feature that Android gives you out of the box (by comparison). |
|
@frenck I thank you for the quick reply, sorry for using the wrong channel. I've opened a post in the forums, and tried to give my best arguments for the need of this feature (or a fallback like custom HTTP headers), I leave the link for those reading: https://community.home-assistant.io/t/secure-communication-channel-for-ios-app/785129 Cheers! |
|
Ok, I've locked down the conversation here. There is nothing left to do on this PR. It is closed. Hints to my personal profile also absolutely do not fit here, especially as it is fitted and came across to me as personal and definitely not needed here. We all, including myself, put our souls into this project, and there is no reason to play such a ball. As pointed out, this is not the right place for discussions like these. If you would like to discuss this, please use the places we created to discuss features and wishes. Doing it outside of those places, will not help the process at all. You don't have to agree—that is fine. But I've been very clear about where to go with this. BTW, thanks, @scristalli for steering this into the right place ❤️ ../Frenck |
TODO:
Summary
Continues the credential threading of #2131 by prompting for client certificates when the server requests. There are 2 kind of client certificate requests:
ASWebAuthenticationSession doesn't support customizing networking, so this also implements a (pretty simple) wrapper around the login flow in an in-app web view. This has the upside of not doing a second certificate trusting screen for self-signed certs too.
Screenshots
Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#
Any other notes