Please take this discussion to this post: https://lemmy.ml/post/28376589

Main content

Selfhosting is always a dilemma in terms of security for a lot of reasons. Nevertheless, I have one simple goal: selfhost a Jellyfin instance in the most secure way possible. I don’t plan to access it anywhere but home.

TL;DR

I want the highest degree of security possible, but my hard limits are:

  • No custom DNS
  • Always-on VPN
  • No self-signed certificates (unless there is no risk of MITM)
  • No external server

Full explanation

I want to be able to access it from multiple devices, so it can’t be a local-only instance.

I have a Raspberry Pi 5 that I want to host it on. That means I will not be hosting it on an external server, and I will only be able to run something light like securecore rather than something heavy like Qubes OS. Eventually I would like to use GrapheneOS to host it, once Android’s virtual machine management app becomes more stable.

It’s still crazy to me that 2TB microSDXC cards are a real thing.

I would like to avoid subscription costs such as the cost of buying a domain or the cost of paying for a VPN, however I prioritize security over cost. It is truly annoying that Jellyfin clients seldom support self-signed certificates, meaning the only way to get proper E2EE is by buying a domain and using a certificate authority. I wouldn’t want to use a self-signed certificate anyways, due to the risk of MITM attacks. I am a penetration tester, so I have tested attacks by injecting malicious certificates before. It is possible to add self-signed certificates as trusted certificates for each system, but I haven’t been able to get that to work since it seems clients don’t trust them anyways.

Buying a domain also runs many privacy risks, since it’s difficult to buy domains without handing over personal information. I do not want to change my DNS, since that risks browser fingerprinting if it differs from the VPN provider. I always use a VPN (currently ProtonVPN) for my devices.

If I pay for ProtonVPN (or other providers) it is possible to allow LAN connections, which would help significantly, but the issue of self-signed certificates still lingers.

With that said, it seems my options are very limited.

  • Trainguyrom@reddthat.comEnglish
    5·
    6 days ago

    But supposing you absolutely do not want to tack on additional costs, then the only solution I see that remains is to set up a private VPN network, one which only connects your trusted devices. This would be secure when on your I trusted LAN, but would be unavailable when awat from home.

    Traditionally this would be performed by creating a dedicated network of trusted devices. Most commonly via a VLAN for ease of configuration. Set the switch ports that the trusted devices are connected to to use that vlan and badabing badaboom you’re there. For external access using Tailscale or one of the many similar services/solutions (such as headscale, netbird, etc.) with either the client on every device or using subnet routing features to access your trusted network, and of course configure firewalls as desired

    • litchralee@sh.itjust.worksEnglish
      3·
      6 days ago

      I had a small typo where “untrusted” was written as “I trusted”. That said, I think we’re suggesting different strategies to address OP’s quandary, and either (or both!) would be valid.

      My suggestion was for encrypted L3 tunneling between end-devices which are trusted, so that even an untrustworthy L2 network would present no issue. With technologies like WireGuard, this isn’t too hard to do for mobile phone clients, and it’s well supported for Linux clients.

      If I understand your suggestion, it is to improve the LAN so that it can be trusted, by way of segmentation into VLANs which separate the trusted devices from the rest. The problem I see with this is that per-port VLANs alone do not address the possibility of physical wire-tapping, which I presumed was why OP does not trust their own LAN. Perhaps they’re running cable through a space shared with other tenants, or something like that. VLANs help, but MACsec encryption on the wire paired with 802.1x device certificate for authentication is the gold standard for L2 security.

      But seeing as that’s primarily the domain of enterprise switches, the L3 solution in software using WireGuard or other tunneling technologies seems more reasonable. That said, the principle of Defense In Depth means both should be considered.

      • Trainguyrom@reddthat.comEnglish
        1·
        6 days ago

        Physical wire tapping would be mostly mitigated by setting every port on the switch to be a physical vlan, especially if the switch does the VLAN routing. Sure someone could splice an ethernet cable, which would really only be mitigated by 802.1x like you already said, but every part of this threat model makes zero sense. You ultimately have to trust something (and apparently in OP’s case that’s a third party VPN provider that charges extra to not block LAN access while connected and they remain entirely on the free tier of)

        But at the very least, not trusting everything on the network is a very enterprise kind of threat model, so using standard enterprise practices of network segmentation, firewalling, and potentially MAC-binding and 802.1x if so desired isn’t a bad idea, if for no other reason than it might lead to a career in network administration. And honestly I mostly want to get OP to not think of VPNs like a magical silver bullet and see what other tools exist in the toolbox

        • litchralee@sh.itjust.worksEnglish
          0·
          6 days ago

          Physical wire tapping would be mostly mitigated by setting every port on the switch to be a physical vlan

          Can you clarify on this point? I’m not sure what a “physical VLAN” would be. Is that like only handling tagged traffic?

          I’m otherwise in total agreement that the threat model is certainly not typical. But I can imagine a scenario like a college dorm where the L2 network is owned by a university, and thus considered “hostile” to OP somehow. OP presented their requirements, so good advice has to at least try to come up with solutions within those parameters.

          • Trainguyrom@reddthat.comEnglish
            2·
            6 days ago

            Y’know what that was terrible writing on my part. Where I put “physical vlan” I just meant specifying each port be a specific vlan rather than a trunk port that has multiple clans on in

            I should probably proofread more and write less when tired