this post was submitted on 09 Apr 2025
47 points (77.6% liked)

Selfhosted

46685 readers
656 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

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

Main contentSelfhosting 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.

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 1 month ago

I'm not taking this to lemmyml

[–] [email protected] 1 points 1 month ago

You can also add a second network interface to the computer that needs to access the jellyfin server over LAN.

[–] [email protected] 4 points 1 month ago (1 children)

If you are willing to swap to mullvad then you can also install tailscale. You can then choose to connect to your jellyfin server (over LAN) or (over tailscale-wireguard tunnel over LAN) while the rest of the traffic flows through mullvad.

[–] [email protected] 1 points 1 month ago (1 children)

Why not just skip that and just use a wire guard tunnel?

[–] [email protected] 1 points 1 month ago (1 children)

a wireguard tunnel over a forced NordVPN tunnel will mean that all his traffic will flow all the way to the NordVPN node and all the way back for a LAN connection.

a properly configured wireguard tunnel is harder to configure than a tailscale network with a mullvad exit node. (I think)

a wireguard tunnel can only connect one device to the Jellyfin Server (or router if it supports it)

[–] [email protected] 1 points 1 month ago* (last edited 1 month ago)

WG Ez worked fine for me? Basically just VPNs me right into my LAN.

OH I'm an idiot, I forgot I connect to my domain for the wire guard connection lmao

Though I did mean just tunnel into the Lan then the vpn is applied on outbound connections on the Lan using something like Gluetun or w/e

[–] [email protected] 1 points 1 month ago

Your options are only as limited as your imagination and complexity of your requirements.

If you're only using it on your network, just use HTTP with mdns (or have static routes from your router or something, but you said you don't want that) so you don't have to remember IP addresses. If you want TLS, you can borrow someone else's domain with a service like FreeDNS.afraid.org (5 free subdomains). Or if you control the devices completely, you can make a root CA and add that to each device's trusted CA list, and then sign your own certs and eliminate MITM attacks.

You have options, and most are overkill. The simplest, secure solution is HTTP on your local network or over a VPN you trust (if you have a publicly accessible IP, just host your own WireGuard server on/via your router).

[–] [email protected] 0 points 1 month ago

So you want a self hosted jellyfin instance that you only plan to access at home, as secure and simply as possible?

Buy an HDMI splitter.

[–] [email protected] 2 points 1 month ago (1 children)

You're overthinking. Just host it on any server with a domain name and use let's encrypt certs if you want to access it from anywhere. TLS offers good encryption, I don't get how you need a VPN on top of that.

For local access only, I'd just host it on a machine over the lan, self-signed certs for TLS, hell I would even settle with http in this case. As for your VPN app preventing you to access a local resource on your lan, if true, you should get rid of that nonsense.

[–] [email protected] 16 points 1 month ago* (last edited 1 month ago) (2 children)

I applaud your accomplishment as a penetration tester. I am disappointed at your lack of understanding regarding non-public networking.

Move your VPN to your router. Don’t bother with HTTPS on anything not exposed to the Internet.

If that does not satisfy your concerns, you may want to give up using electronic devices.

[–] [email protected] 3 points 1 month ago

No reason not to have both. Things like vaultwarden do warrant an extra layer so setup wildcard domain for internal services x.local.example.com and then normal certs for external stuff like y.example.com.

To get internal stuff you then need your vpn as well to access it. You can now easily choose what risk you want on a per app basis.

Technotim has a good video on this

[–] [email protected] 1 points 1 month ago (1 children)

There is a huge reason to use HTTPS inside the LAN - so many browsers and other client software show HTTPS connections as more secure, with a nice padlock. For me, this was worth the minor inconvenience of setting up DNS-challenge with let's encrypt with a domain I already had.

[–] [email protected] 1 points 1 month ago (1 children)

Your huge reason is the padlock in the browser bar? I’m not against TLS internally. I do it myself with my own CA. For this particular instance and the unique requirements, it seemed easiest to avoid TLS.

[–] [email protected] 1 points 1 month ago

Yes it is. I got so annoyed by seeing it unlocked.

[–] [email protected] 46 points 1 month ago* (last edited 1 month ago) (2 children)

Hi. I am a software engineer with a background in IT security. My girlfriend is a literal network security engineer.

I showed her this thread and she said: don't bother, just use http on your local network.

Anyways, I am going to disengage from this thread now. Skepticism against things one doesn't fully understand can be healthy, but this is an insane mix of paranoia and naïveté.

You are not a target; the things you are afraid of will never happen; and if they did, they would not have the consequences you think they would.

Your router will NOT magically expose your traffic to the internet (what would that even mean?? Like, if it spontaneously started port forwarding to your Jellyfin server (how? By just randomly guessing the port and IP???), someone would still need to actively request that traffic, AND know your login credentials, AND CARE).

Your ISP does not give a shit about you owning or streaming copyrighted material over your local network. It has no stake in that.

Graphene is not an ultimate arbiter of IT security, but the reason it "distrusts networks" is because you take your phone with you, constantly moving into actual untrusted networks (i.e. ones you do not own).

Hosting Jellyfin on Graphene will not make it more secure, whatsoever.

If every device is assumed compromised, and compromising devices with knowledge that you watch media is a threat in your model, then even putting an SD card with media in your phone and clicking play is dangerous. Which is stupid.

If you actually assume your router is malicious, then please assume that when you initially downloaded your VPN client, it was also compromised and your VPN is not trustworthy.

The way I see it, you have two options:

  1. educate yourself on network security to the point of being able to trust your network setup; or
  2. forget about hosting anything
[–] [email protected] 1 points 1 month ago

Regarding the ‘taking your phone with and joining untrusted networks,’ you can set up WireGuard to auto join your vpn on any network you haven’t whitelisted, including your cellular network.

[–] [email protected] 2 points 1 month ago (1 children)

I'm interested in you and your girlfriend's thoughts on my new post about this issue.

P.S. She's a keeper. Marry her already!

[–] [email protected] 8 points 1 month ago

Hi again. Sorry for being so rude yesterday. Your new post actually clears the situation up a lot.

We might have an idea for you, will comment on the new post.

[–] [email protected] 8 points 1 month ago* (last edited 1 month ago)

This is one of the funniest posts I've seen here so far. Thanks for that! I unfortunately don't otherwise have anything to add that hasn't already been said, just wanted you to know that I enjoyed it a lot :)

[–] [email protected] 5 points 1 month ago* (last edited 1 month ago) (1 children)

After reviewing the entire thread, I have to say that this is quite an interesting question. In a departure from most other people's threat models, your LAN is not considered trusted. In addition, you're seeking a solution that minimizes subscription costs, yet you already have a VPN provider, one which has a -- IMO, illogical -- paid tier to allow LAN access. In my book, paying more money for a basic feature is akin to hostage-taking. But I digress.

The hard requirement to avoid self-signed certificates is understandable, although I would be of the opinion that Jellyfin clients that use pinned root certificates are faulty, if they do not have an option to manage those pinned certificates to add a new one. Such certificate pinning only makes sense when the client knows that it would only connect to a known, finite list of domains, and thus is out-of-place for Jellyfin, as it might have to connect to new servers in future. For the most part, the OS root certificates can generally be relied upon, unless even the OS is not trusted.

A domain name is highly advised, even for internal use, as you can always issue subdomains for different logical network groupings. Or maybe even ask a friend for a subdomain delegation off of their domain. As you've found, without a domain, TLS certificates can't be issued and that closes off the easy way to enable HTTPS for use on your untrusted LAN.

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 untrusted LAN, but would be unavailable when away from home. So when you're out and about, you might still need a commercial VPN provider. What I wouldn't recommend is to nest your private VPN inside of the commercial VPN; the performance is likely abysmal.

[–] [email protected] 5 points 1 month ago (1 children)

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

[–] [email protected] 3 points 1 month ago* (last edited 1 month ago) (1 children)

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.

[–] [email protected] 1 points 1 month ago (1 children)

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

[–] [email protected] 0 points 1 month ago (1 children)

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.

[–] [email protected] 2 points 1 month 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

load more comments
view more: next ›