Submitted 3 hours ago by 
observantTrapezium@lemmy.ca to selfhosted@lemmy.world
There are some services that I expose to the internet (using Apache reverse proxy) that really should be accessed by only a small set of devices. Requiring client certificates seems like a great way to reduce the attack surface and prevent brute force attacks (since the attacker doesn’t even get a chance to attempt a login).
I wonder about the difficulty on the client side as well as other practical implications. The clients are smartphones of various makes.
I use mTLS with Caddy to expose some of my services. It is quite manageable, and I only use if for myself and my wife.
We both use Android phones, and I configure access via apps for the services, that use the devices’ certificate store. It seems like the iOS way is to provide the client certificate and password to each app that’s gonna use it. I’m happy we can avoid that.
Big plus side for us is the simplicity of it all, there is no “always on VPN” requirement, and things “just work” with acceptable security.
I also sometimes access the services via Firefox, which is also able to use the device’s certificate store, although I have to keep selecting the same certificate each time.
I use Tailscale for this, with my own Headscale server so that I am in control of everything. It’s a much easier approach that is more likely to pass the spousal acceptance factor.
This. Tailscale just works and has functioning VPN on demand for your networks.
observantTrapezium@lemmy.ca 2 hours ago I’m already running Headscale, and it works great. But to expose individual services to individual devices it feels like an overkill. I don’t actually need all these devices to connect to the tailnet all the time, and some of these devices I don’t even want to be able to access the entire tailnet.
mike_wooskey@lemmy.thewooskeys.com 2 hours ago MTLS is great protection, but the use case must support it. For example, if you want your app to support registration for new accounts or if you have a lot of people you want to have access, that might make mTLS unwieldy to manage.
I host apps behind Traefik reverse proxy, using the d.rymcg.tech framework. It make it easy to protect your apps behind HTTP basic auth, Oauth2, or mTLS(or any combination).
observantTrapezium@lemmy.ca 2 hours ago Ah, thanks for the idea. I’ll look into Traefik, I’ve heard of it, but wasn’t sure what it could do.
I am using mTLS implemented by nginx to access my services like Home Assistant, Paperless, Tandoor, Immich and so on. Clients are Windows, Linux and Android based so no iOS experience. Adding new clients can be tricky if you need to figure out how to provide the certificate first. Once it works, it’s rock solid
achim@mastodon.weindl.biz 2 hours ago mTLS can be a very good extra gate for a small, controlled device set. But “some services”, “smartphones” and “Apache reverse proxy” is not enough to recommend it responsibly.
The decisive questions are:
.p12 be copied around? (Please do not do the latter.)For a handful of your own devices, per-device mTLS certificates can be perfectly reasonable. For a mixed fleet of smartphones without MDM, the operational overhead is often the actual attack surface: secure initial delivery of the PKCS#12 bundle, private-key protection, expiration, rotation, revocation, backups, and users selecting the right certificate.
Also: mTLS is a gate, not a replacement for normal authentication and authorization. I would usually still keep the application login, use individual device certificates with a private CA, short-ish validity, documented revocation, and rate limits. Otherwise you have merely replaced password brute force with “whoever extracted or copied the client private key gets through.”
Depending on the service, a WireGuard/Tailscale-style private network or an identity-aware proxy may be less painful on phones — but that is impossible to judge without knowing the actual services and client workflow. Certificate-based mobile access is feasible, yet the setup and lifecycle vary materially across platforms and applications.
So yes: the missing basics are not a minor omission; they are the question.
observantTrapezium@lemmy.ca 2 hours ago My thinking is to put Immich, Matrix, and CalDAV/CardDAV behind mTLS. So the clients practically do connect via native mobile apps rather than a browser. The devices belong to a small number of users, I don’t manage them, but can distribute the keystores, and plan on doing the PKI manually as it’s really not a lot to keep track of.
Not an authentication replacement for sure, just an extra layer of protection. The goal is mostly so that if there’s a new critical exploit, I don’t have to drop everything I’m doing and immediately mitigate.
frongt@lemmy.zip 7 minutes ago
It’s a good option if you can’t do anything better, like a VPN. Because there is always the risk of an authentication bypass vulnerability. The less attack surface, the better.