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
    5·
    24 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·
      23 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.

      • Achim :antifa:@mastodon.weindl.biz
        11·
        23 hours ago

        @observantTrapezium

        I just saw your other reply on Lemmy regarding Headscale.

        Headscale should already solve that use case without putting mTLS in front of every service.

        By default, a Headscale tailnet is rather permissive, but you can load a policy and use Grants (or ACLs, though Grants are the preferred direction) to explicitly allow only the connections you want. A phone does not need access to “the whole tailnet” just because it is enrolled.

        For example, each user/device group could be allowed to reach only:

        • the Immich host on its HTTPS port;
        • the CalDAV/CardDAV host on 443;
        • optionally the Matrix client endpoint on 443;

        …and nothing else. No SSH, no databases, no admin UIs, no access to other tailnet nodes. Start with an empty grants policy — which denies all tailnet traffic — then add narrowly scoped allow rules for the relevant source devices and service destinations.

        That also means the client can simply connect when it needs those services; it does not need broad, permanent network access merely because the Headscale app is installed. And if a device is lost, removing that node from Headscale cuts off its network access immediately.

        So I would still favour: private services behind Headscale plus a deny-by-default policy, instead of managing a separate mTLS PKI for several native mobile apps. The latter is viable, but it is solving device/network admission at the application TLS layer when you already operate a tool designed to do it at the network layer. Headscale explicitly supports access control policies for restricting traffic between nodes, and policies can deny all traffic by default until specific access is granted.

        • observantTrapezium@lemmy.caOPEnglish
          1·
          14 hours ago

          Ah, interesting. Looks like using grants does resemble what I envision and probably easier to set up that mTLS. I’ll certainly explore that!