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.

  • skizzles@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    6 days ago

    Just out of curiosity, why is your network not a trusted party?

    You could start with an additional firewall and maybe setting up traffic restrictions on it to mitigate what devices can communicate with each other, in addition to setting up a local VPN.

    Yes its possible to spoof mac addresses and such but it really sounds like your concerns could be mitigated by having a more secure network setup.

    If your network isn’t a trusted party then you need to start there. Why isn’t it a trusted party and what do you need to do to secure the traffic to/through it.

    • The 8232 Project@lemmy.mlOP
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      6
      ·
      6 days ago

      Just out of curiosity, why is your network not a trusted party?

      Part of my threat model is essentially “anything that can connect to the internet poses a security risk”. Since networks are the literal gateway to the internet, it is reasonable not to trust them. Routers don’t run as secure operating systems as Qubes OS, secureblue, or GrapheneOS. If a malicious party found a way to connect to the network, all unencrypted activities can be intercepted. If the router itself has malicious code, any unencrypted traffic can be sent to a third party. Those are just the basics, but trying to put band-aid solutions on a fundamentally broken system is a losing battle.

      GrapheneOS distrusts networks as much as possible, so I do too. Even if I own the network, I am not a network engineer, so the chances of fault are high. In the simplest case, the network is a gateway to all activity that happens on the LAN, and it only takes one zero day to make that happen. The best mitigation is proper encryption and no self-signed certificates (where possible).