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.

  • Achim :antifa:@mastodon.weindl.biz
    2·
    4 hours ago

    @observantTrapezium

    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:

    • Which services are we talking about: a normal web UI in a mobile browser, native apps, APIs, WebDAV, SSH-like administration, something else?
    • Are those personally managed devices, or devices belonging to multiple users?
    • iOS, Android, both — and which browsers/apps?
    • Is there MDM, or would certificate enrollment, replacement, revocation and renewal all be manual?
    • What happens when a phone is lost, reset, sold, or its private key leaks?
    • Does each device get its own certificate, or would the same .p12 be copied around? (Please do not do the latter.)
    • Is the real goal “no public login page”, “device authentication”, or simply private remote access?

    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.caOPEnglish
      2·
      4 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.