[Feature]: Support mTLS / Client TLS Certificates in Mobile App

[JabobKrauskopf]

Feature detail

Background
I would like to access my instance of Immich from outside my network. However, the only option I have without exposing it to the internet is to use a VPN, which I would like to avoid. Configuring my reverse-proxy to require mutual TLS / client certificates could reduce the risk of exposing Immich by adding an extra layer of protection.

Proposal
Ideally, the Immich app could access the iOS / Android keychain and use a client certificate that is installed system-wide for any requests to the Immich server.

Problem
After taking a stab at implementing this feature on Android by accessing the native keychain, I ran into the following issue. The Dart HTTP Client supports client certificates by configuring a SecurityContext object with useCertificateChainBytes() and usePrivateKeyBytes(). However, these methods require the actual contents of the private key, but the Android KeyChain.getPrivateKey() API only returns an opaque key. The built-in Dart HTTP client does not seem to support this (see dart-lang/sdk#50669 (comment)).

Apps like HomeAssistant support client certificates because the OkHttp library seems to use native Android APIs (see home-assistant/android#2526).

Solutions
One solution would be to have some kind of advanced options section on the login screen where a user uploads a client certificate. However, this would be less than ideal since we would bypass the system keystore which already provides this functionality.

Another option that might be worth exploring is a custom header that contains a secret token which is sent with every request. Maybe something like this: #1305

I would appreciate any insights/help on how one might approach implementing mutual TLS.

Platform

Mobile App

[stokito]

Why not just authorize by username and password? Then you can remember or use a password manager. A long password gives just enough of protection.

The mutual TLS in practice never worked. It looks similar to ssh keys but lacks of all infrastructure and tools. There is no any reason to use it and that's why it's not supported anywhere.

[JabobKrauskopf]

Why not just authorize by username and password? Then you can remember or use a password manager. A long password gives just enough of protection.

It's not that I don't trust authentication using username and password. But logic bugs can and do exist (not necessarily in Immich but in general) and it is in the realm of possibilities that one might be able to access restricted content using some sort of loop hole or vulnerability in the code.
This matters to me because I want to ensure that my photo collection remains private, due to its sensitive nature.
Being able to secure my Immich instance on the transport layer instead of hoping that there will never be any vulnerabilities in the application layer would be ideal.
Here's an example that these vulnerabilities can exist, even in an established project like Home Assistant: home-assistant/core#13836

It looks similar to ssh keys but lacks of all infrastructure and tools.

Client certificates are created using the same tools as "normal" server certificates.
Regarding infrastructure, common reverse proxies (traefik, caddy, nginx) support requiring and verifying client certificates.

The mutual TLS in practice never worked. [...] There is no any reason to use it and that's why it's not supported anywhere.

I disagree. While this might not be a feature everyone uses, there is clearly at least some demand for it, as can be seen by searching for mTLS or client certificate in the Home Assistant and Nextcloud issues/PRs (see for example home-assistant/android#27 nextcloud/android#603 nextcloud/android#11314).
Even if not implemented using mTLS there is demand for a zero trust solution for Immich by other people as well: #1305 .

[stokito]

If we are talking about loop hole as it was in the HA when logs wasn't protected then this is a bug on app level. It's easy to make such mistakes and in future they may made again, that's true.
You can make an authorization on proxy level e.g. add a basic auth for entire root. The basic auth may work in parallel to cookie based auth.
The mtls has only two advantages:

1. The key is bigger than a password
2. You can reject a hacking attempts earlier on a transport layer.

Both aren't such a big advantage. A long password from three words anyway gives years to brute force. The TLS handshake is anyway slow by itself but still hard to DDoS it.

When I saying that there is no good tools I mean something like ssh-copy-id or just a specified folder where your keys are stored like ~/.ssh/. A lot of things are just missing and you have only a key file itself.
This is not critical but you can't make the mTLS widely adopted.
I remember in old days browsers had a support of mutual TLS and even one website (WebMoney) used it. But today you won't find anyone who use the mtls.

If you have a private instance then a simplified attack vector looks like:

1. Some bot scanner may send known exploits. Here the best protection is to keep the app always updated and additional measures like VPN, IP whitelist or even the mTLS.
2. Targeted attack when some hacker tries to attack you personally. But why would someone interested in you and spent time?
3. Mass surveillance e.g. passive eavesdropping

From one side even if you keep your photos just open that doesn't mean that someone will find them immediately and stole. But from another side you better not to upload sensitive information anywhere in Internet

[bestrocker221]

@stokito I do not agree.

Why not just authorize by username and password? Then you can remember or use a password manager. A long password gives just enough of protection.

In the remote case there is a bug in the app authentication, a password can become irrelevant. And what if a specific endpoint is not properly/mistakenly protected?

mTLS authentication is amongst the most secure mechanism to ensure private and trusted communication between two parties.
For self hosting, mTLS almost certainty ensure that nobody else can access your https endpoint, even before touching the web application (unless the certificate is stolen, or CVE in web server mTLS logic). That is one thing that makes mTLS awesome in self hosted environments where, even if you expose an endpoint to the Internet, you know exactly who can access it. (and also why it was such a requested feature in HA)

Web applications can contain vulnerabilities at any time, which puts your data at risk.
Even if you have setup SSO/OpenID/Proxy auth, which might greatly improve things, bugs in the idp or in the app itself can still be discovered, which makes the whole thing fall apart again. People might trust google photos that such bugs/vulnerabilities would be caught in time and never affect their data, but when self hosting their own NNNk+ private picture and video library it becomes a bigger concern.

I do see a mTLS feature (just to be able to reuse certificates from the keystore would be enough) for the immich app of great use. I wish I could help contributing but JS/android is not my field. In the meantime with vpn works great

That said, I want to add that the project seems awesome and thanks for the development!

[piotrszlenk]

I think you are on the money here. Consuming an external service like Cloudflare adds the missing piece of protection and privacy. You don't need to expose any ports to the public internet and reveal your public IP. Instead you run a reverse tunnels back to cloudflare so it supports dynamic public IPS/CG-NATs, etc.

The only modification that is required is at the Android/IOS app level.

Thanks for all the development so far.

[bo0tzz]

I think it is unlikely that we will add support for this to Immich. A VPN allows for the same level of protections, while working seamlessly without any application changes.

[IMBeniamin]

There are many solutions to this problem, mTLS on immich is one of them.
The security layers in regards to the web application are pretty easy and are fairly transparent.

Issues arise however when using the mobile apps and native clients, because it is no longer possible for authentication to be completely transparent.

Cloudflare has many solutions to this such as Argo tunnels, access, firewall rules, reverse proxies can be configured to require authentication, etc.

Bo0tzz is right in saying that the only solution that does not require code modifications on the clients is using a VPN.

All other solutions, custom headers, certificates, etc have to also be implemented in the mobile apps.

[coxtor]

All we need is an option for the user to enable to send a certificate to the server during initial login, the certificates are usually stored in the devices certificate store once the user has added them. The rest is handled by the server. mTLS would not prevent you of scanning your traffic if you are in control of your network.

[coxtor]

Using mTLS you would protect yourself from zero days as only trusted users could access your server in the first place.

[bestrocker221]

@coxtor

All we need is an option for the user to enable to send a certificate to the server during initial login

Are you referring to a new method of authenticating to Immich via client certificates? that's a whole another story.

The TLS client authentication happens even before touching the Immich application, and is basically only between the end user and the proxy. It is also easier to implement rather than adding another authentication mechanism in the web application, and it would be transparently enforced, for each request, by the underlying infrastructure.

End-user <-- mTLS --> Proxy <--> Immich

The big plus for Immich mobile application would be to support the use of already imported user certificates (imported in the mobile, not in the app).

That way you can then setup your own CA and then intercept / decrypt according to your preferences

[github-cli]

Using client certificates does not prevent attacks, zero trust means you should not blindly trust. The device with the cert can be compromised, you might share it with someone you think you can trust but cannot, etc.
But yes, of course it is much, much more secure than without client cert and no traffic inspection

[german-aksenov]

is it possible to make it like
https://github.com/MarcoEidinger/ClientCertificateSwiftDemo/tree/main

[badzz]

@JabobKrauskopf thanks for bringing this, I just started on immich and my all personal hosting is based on client certificate. So no support for this will be a no go.
I saw in dart-lang/sdk#50669 that somebody did a http native plugin for dart : https://github.com/badzz/native_http_client
Is this a viable option ?

[oziee]

I would like to see mTLS supported in the app too

[r01k]

I concur that supporting client certificates would greatly enhance the security options in Immich.

[piotrszlenk]

Hey, consider a scenario where you put your server behind cloudflare and enable mtls there.

It limits the surface of attack for immich as a valid client cert is required to get to immich api.

It's a common use case for home assistant owners.

[ported-pw]

It also does seem risky to me to run an in-development thing like this without an additional layer of protection, like what either this (using client certificates) or e.g. custom headers using Cloudflare Access/Zero Trust allows (#1305).

[coxtor]

Why is the Diskussion closed?

[faryon93]

Can we please reopen this issue? I think there ist a real benefit to help improve security when the app could provide client certificates to the server.

[piotrszlenk]

Hi @alextran1502, I was wondering if we could reopen the discussion we had earlier. I believe it is important for Immich clients to have this feature.