feat(mobile): trust user-added CAs #14403
Conversation
|
Label error. Requires exactly 1 of: changelog:.*. Found: |
This PR allows the Android app to trust user-added CAs without skipping SSL certificate verification. It is pretty common that a self-hosted Immich server uses an SSL certificate issued by a self-signed CA, such as a company's internal CA. On Android systems, users can install a custom CA certificate by going to system Settings -> Security & privacy -> More Security and privacy -> Encryption & credentials -> Install a certificate. However, starting with Android N, an app doesn't trust user-added CAs by default unless it explicitly opts in. See https://developer.android.com/privacy-and-security/security-config for more information. iOS doesn't have this issue because it always trust user-added CAs. Even Chrome on Android trusts user-added CAs (https://github.com/chromium/chromium/blob/f65f60551faa7e21c176c951cf874ce98278fd0b/chrome/android/java/res_base/xml/network_security_config.xml#L8) so it shouldn't a security concern.
vfreex
force-pushed
the
trust-user-added-cas
branch
from
35e3059 to
8df62b6
Compare
vfreex
changed the title
|
Hello, how has this change been tested? Can you verify that it works with video? |
|
Our understanding has been that Flutter has its own CA store and there's no way to have it use the system store. If that's right, this change shouldn't work at all. |
You are correct. I solved this issue in another project but haven’t tested this with Immich. I searched for this issue and found it might be possible to use platform native API for https calls with Flutter. I will do more investigation. |
|
I am able to verify this after changing the http engine from dart.io HttpClient to cronet_http as described at https://pub.dev/packages/http. But that requires more testing to ensure nothing will be broken. |
|
A previous attempt at cronet was made in #5869. cc @shenlong-tanwen |
Yes using cronet/cupertino http should fix the issue. I've recently saw few other flutter projects replacing their http clients with the cronet implementation. |
|
Hey @vfreex, we need more metrics to justify this use case. Hence, I am closing this PR. We'll consider adding if we have more requests about this feature. Thank you for the PR. |
It's disheartening to see this feature's PR being closed. From my understanding, last year, a PR related to trusting user-added CAs would have been welcomed, but now that one exists, it's been closed due to lacking requests. Since you mentioned that the feature needs more requests to justify its implementation, what would be the best way to make such a request? |
+1 for the request, which has been bothered me for a while. |
|
+1 |
|
I'm also looking for a way to get my local PKI working for Immich and would really appreciate further effort on this PR 👍 |
|
+1 |
|
+1 Wondering if this will fix the issue I am currently having with the android app connecting to our server, which is behind mTLS signed by our own CA. |
This PR allows the Android app to trust user-added CAs without skipping SSL certificate verification.
It is pretty common that a self-hosted Immich server uses an SSL certificate issued by a self-signed CA, such as a company's internal CA.
On Android systems, users can install a custom CA certificate by going to system Settings -> Security & privacy -> More Security and privacy -> Encryption & credentials -> Install a certificate. However, starting with Android N, an app doesn't trust user-added CAs by default unless it explicitly opts in. See
https://developer.android.com/privacy-and-security/security-config for more information.
iOS doesn't have this issue because it always trust user-added CAs. Even Chrome on Android trusts user-added CAs (https://github.com/chromium/chromium/blob/f65f60551faa7e21c176c951cf874ce98278fd0b/chrome/android/java/res_base/xml/network_security_config.xml#L8) so it shouldn't a security concern.