Android: Accept self-signed SSL certificate issued by a non-public CA

[dickesW]

I'm using my own CA to sign my home-assistant (and other) SSL certificates. This CA is imported in the androids user "trusted credentials". This works perfect for home assistant via Chrome and other services I use - like nextcloud and their app.

As far as I understand the support of user "trusted credentials" CAs needs to be enabled in the apps security policy:
https://developer.android.com/training/articles/security-config.html

The nextcloud Android App is a working example.

Thx!

[andriej]

I'm somehow against. If I ever connect to AP that will MITM my traffic and will get my certificate SSL traffic broken to get credentials, I wouldn't like to allow such kind of traffic to/from app.
Certificates are there for something... and they are free (with letsencrypt).

[andriej]

Although if there's way to detect if certificate is imported and only allow it when it's there - it's ok. :)

[charlie89]

Letsencrypt doesn't work if home-assistant is only accessible from inside my LAN, but I still want it to connect over https.
I have both my CA and the home-assistant certificate imported to my android phone, home-assistant runs in a docker container with its own network where only traefic connects to. traefic (a reverse proxy) does the https. Still got a blank screen after manually inserting the url in the app.
This setup works perfectly with like 10 other apps (one of them is nextcloud), so i would really appreciate it :)

[BCNelson]

Duplicate of #27 You can look at the discussion there.

[dickesW]

Duplicate of #27 You can look at the discussion there.

@BCNelson as far as I understand these are two different things - That's why I opened the request ;-)
In #27 the client also authenticates to the server via a certificate.
In my request the server just uses a non-public CA. This is quite common if you don't want to expose your application to the internet to get a letsencrypt certificate but want to use https without security warnings.

[BCNelson]

@dickesW My bad thanks for the clarification. I will look in to adding it if @balloob thinks it is within the scope of the official app.

[balloob]

Yeah, this is ok.

[tiagofreire-pt]

Yeah, this is ok.

+1.

My HA instance is not exposed to the internet, so I managed a full HTTPS connection 100% compliant with all the browsers (including Chrome above vs 58) through a custom root CA.

Or, if the HA instance is using a SSL the app could check the website SAN/keys against the custom root CA installed on the android user domain. This should eliminate the possibility for MITM attacks, as, otherwise, both ends should be compromised.

[balloob]

We're not going to roll any custom SSL checks. Too dangerous. As long as we can just tweak a config option to allow own certs installed by user, then we can do that.

[urusha]

Got the same issue, white screen after entering url, in my case url is ip (SAN type is IP), but that doesn't matter, since it perfectly works with Chrome and other browsers.
self-signed SSL certificate issued by a non-public CA - @robbiet480 actually this is wrong wording, since SSL certificate is not self-signed, it's signed by CA, which may/may not(intermediate) be self signed but the first CA in the chain is non-public, certainly. The main thing is that android device trusts certificate's full chain and it's impossible to add such CA without user's approval (entering device password). Since chrome trusts it, I don't think excluding user-added CAs will give us more security, just inconvenience.

[patricf]

Letsencrypt doesn't work if home-assistant is only accessible from inside my LAN, but I still want it to connect over https.
I have both my CA and the home-assistant certificate imported to my android phone, home-assistant runs in a docker container with its own network where only traefic connects to. traefic (a reverse proxy) does the https. Still got a blank screen after manually inserting the url in the app.
This setup works perfectly with like 10 other apps (one of them is nextcloud), so i would really appreciate it :)

You can easily use Let's Encrypt even if your HA is only accessible from your LAN. Just use the DNS-01 Challenge. That's what I do.

[urusha]

@patricf I can do many things easily, but this issue is not about that.
With own CA and IP cert, I don't need LE maintenance (evey 3 month), public(any) domain (no domain tracking). I can create and import CA, get cert and store it on the encrypted drive with full secure boot chain, and destroy CA key (since this can easily be repeated) - what could be more secure.

[ochlocracy]

Just wanted to add my support for adding user Root CA trust-anchors. Those of us that choose to roll our own PKI do so to improve netsec and not rely on third parties. Allowing this won't compromise the end to end encryption.

[poofyteddy]

This is also a big need for me, and would like to see the PR/MR linked to this once done in order to push it to other app dev (firefly-III <3)
As someone who have is Smart home disconnected from the web, i push my custom CA on every device. I would love to see more than a white screen ;)

[diijkstra]

Worst thing is that without support for trusted user Root CA, I'm forced to use http instead https because there is no way to bypass (even for testing) an invalid certificate.

[tiagofreire-pt]

We're not going to roll any custom SSL checks. Too dangerous. As long as we can just tweak a config option to allow own certs installed by user, then we can do that.

Posted PR #177. Closed.

[tiagofreire-pt]

For those who are interested on solving this truly, please, consider submitting a new PR, replacing the #177.

@urusha, I'm open to offer my time and skills on this, as an interested one on the solution.

[tiagofreire-pt]

Forked the project and compiled the app for those who want to test the solution on #177 .

Fork: https://github.com/tiagofreire-pt/home-assistant-android
App: https://github.com/tiagofreire-pt/home-assistant-android/blob/master/app-debug.apk

The cleartext option was set to "false", on the network config file.

[urusha]

@tiagofreire-pt works exactly like it should with CA, and no connection (white screen) without CA. Thanks!
One thing is that if CA is removed after login, app prints a connection error and it's fine, but I haven't found a way to change addr/login, except clearing app data. Anyway this is another issue, I don't think it's related to TLS error, it's seems to be about any connection error.

[poofyteddy]

Thank's @tiagofreire-pt. it bother me that i still can't put this on my mother phone because it will not auto-update, but i will have a working version on mine to test :)

I really don't understand what more than the official google doc is needed to have this merged in, someone to dig in android source code to see if it do more than what google claim ? Oo

[tiagofreire-pt]

@urusha and @poofyteddy , thanks for your support.

The patched app is refreshed with the commit fdd71ce from the upstream repository. I'll try to recompile it every other day. Stay tuned on my repository. :)

[ochlocracy]

@tiagofreire-pt Your fork is exactly what is needed.

I think the issue at hand is informing everyone of what this change actually does. Those of use that maintain our own CA know this is no different than trusting a public CA. I could argue that trusting my own CA provides more privacy/security than trusting the list of Root CAs your OS says you should. e.g. The whole Symantec fiasco or the Lenovo Superfish thing or the eDellRoot certificates I could go on.

I'll put on my WebAppSec hat and play devils advocate to admit, allowing user trust anchors for an app such as this; where the domain name or certs of each users instance can't be configured in the network-config, would allow for _any_ user trusted Root CA to "secure" the connection to their home assistant instance.

Therefore, _if_ a malicious actor or company/organization has been able to install and trust a Root CA on the users android device for the purpose of intercepting traffic, allowing this setting would allow that actor is intercept HA traffic, whereas only trusting the system CA would drop the connection like it is now.

If this scenario were to occur the user has already been compromised beyond just communication to their HA instance. Taking this further, beyond just a user trust anchors, when an android device is compromised with the intention of intercepting communications, the device is usually rooted, and the certs are placed in the system trust, and there is background process running to circumvent certificate pinning. No app policy is going to stop that.

Is it the responsibility of the HA developers to protect you from these scenarios? That's for them to decide, but these are both beyond the scope of HA itself, so not likely. Furthermore that whole scenario is like using a "cannon to kill a fly" since clear text communication is currently allowed!

I'll continue working on outlining the security/threat model of what this change entails and present it with a PR.

[poofyteddy]

@ochlocracy I would validate that if android didn't lock it down for a long time already.
On most device ( won't say all since i can't check all devices. But all of the one i know at least) you have to enable complex lockscreen.
To put it against the user will you eather need to know his lockscreen passcode, or to set one up and give it to him. Plus you have a never dismisable notification telling you that "your network might be monitored"

I think it's fair to say you won't easily enable it without user consent... And i personally don't thrust CA on my Huawei devices anyway.

[tiagofreire-pt]

@tiagofreire-pt Your fork is exactly what is needed.

I'll continue working on outlining the security/threat model of what this change entails and present it with a PR.

Please, @ochlocracy. If you're able to open that PR, compliant with the requirements from the main developers, just do it! :D

This change is that much needed and we're at least 1 month out of service with this app (since its beginning), not allowing configurations on https (with custom root CA). This is a configuration proposed by the HA documentation.

Even so, nothing stops MITM hypothesis to happen even when the user connects to its HA instance through a pure browser (strange argument, as this app reports itself that is based on Google Chrome 79...). MITM attacks, as you already stated, are way beyond the HA scope. It seems to be more about the OS itself.

[roseaxl]

I agree with everything outlined so far. I've opened a request but it seems it's not accepted as well.

Plus if one wants to execute MTIM its not that hard even with Public CAs especially on a mobile app.
The whole reasoning from the HA devs against enabling this option because of security concern is unjustified to me.
But may be if more people request/need this, eventually it would made into the official app.

[ochlocracy]

Plus you have a never dismisable notification telling you that "your network might be monitored"

@poofyteddy That persistent notification is only for certificates marked for WiFi use. Roots installed for VPN and app use, do not generate that notification.

I agree with you that android makes it extremely difficult for either of those scenarios to happen. But, I outlined them for transparency because it's common for users to have CA Roots for Work or School installed in the user certificate store for the purposes of intercepting TLS traffic for inspection. Therefore the connection to your HA instance could be proxied for inspection while on their network if user certs are trusted in the app security policy. This is probably the most likely scenario that would compromise a users privacy to their HA instance. But again, the user choose to accept this, when they installed those certificates, and choose to use that network. If the user trusts their Work or School then this shouldn't be an issue. Or they don't trust them and never use the network; again not an issue.

@tiagofreire-pt I'll do what I can but it's ultimately up to the HA owners to decide. I'll layout the realistic security implications of what this change will do with a PR since I think that's ultimately all they are asking for in order to make their decision.

[tiagofreire-pt]

The #194 seems to have the same code proposed on #177. Lets see if this is the end for the issue. 💃

[tiagofreire-pt]

@JBassett , thanks for your PR!