How do I host Jellyfin in the most secure manner possible?
How do I host Jellyfin in the most secure manner possible?
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.
You're viewing a single thread.
Just run it on the LAN and don't expose it to the Internet. That's 99% of the way there. HTTPS only secures the connection, and I doubt you're sending any sensitive info to or from Jellyfin (but you can still run it in docker and use caddy or something with Let's Encrypt).
The bigger target is making sure jellyfin itself and the host it runs on are updated and protected. You could use a WAF too.
Just run it on the LAN and don’t expose it to the Internet.
This would require paying for a VPN to allow LAN connections, which is an option but not my preferred one.
HTTPS only secures the connection, and I doubt you’re sending any sensitive info to or from Jellyfin
This is a matter of threat model, and I would prefer not to expose my TV preferences unencrypted over the network.
but you can still run it in docker and use caddy or something
Does Caddy require a custom DNS in order to point the domain to a local IP address?
The bigger target is making sure jellyfin itself and the host it runs on are updated and protected.
This is easy with securecore, since it updates daily. The rest of the semantics for the actual hosting side aren't too difficult.
You don't need a VPN for LAN connections. You're already on the LAN. You'd only need it for access from the WAN.
If you're using Let's Encrypt, you should probably purchase a domain. I don't think they support .internal domains. Or you could set up your own CA and run it however you want, even issuing certs to access by IP address if you wanted.
You don’t need a VPN for LAN connections.
ProtonVPN by default blocks LAN connections, and can only be changed using their paid tier.
For that aspect, I would recommend changing to a provider that doesn't have such ridiculous restrictions.
I kind of get it from Proton's POV. If they have a free tier that allows a limited number of devices they'll want to make sure you don't tunnel all you devices through that one.
The only other providers I would use are Mullvad VPN or IVPN, both of which are paid.
I agree it is ridiculous.
Wait you're seriously using a free VPN?
Being concerned about security while using free VPN sounds like an oxymoron.
Is there any reason to think the free Proton VPN is somehow insecure?
Not "insecure" in the sense that they're shoddy with their encryption, no. But being free could possibly mean their incentives are not necessarily aligned with that of the free users.
In security speak, the CIA triad stands for Confidentiality, Integrity, and Availability. I'm not going to unduly impugn Proton VPN's credentials on data confidentiality and data integrity, but availability can be a legit security concern.
For example, if push comes to shove and Proton VPN is hit with a DDoS attack, would free tier users be the first to be disconnected to free up capacity? Alternatively, suppose the price for IP transit shoots through the roof due to weird global economics and ProtonVPN has to throttle the free tier to 10 Mbps. All VPN operators share these possibilities, but however well-meaning Proton VPN and the non-profit behind them are, economic factors can force changes that aren't great for the free users.
Now, the obv solution at such a time would be to then switch to being a paid customer. And that might be fine for lots of customers, if that ever comes to pass. But Murphy's Law makes it a habit that this scenario would play out when users are least able to prepare for it, possibly leading to some amount of unavailability.
So yes, a holistic analysis of failure points is precisely what proper security calls for. Proton VPN free tier may very well be inappropriate. But whether it rises to a serious concern or just warrants an "FYI", that will vary based on individual circumstances.
But if you don't plan to access it anywhere but home (your words), then it doesn't have outside access, and putting it on your LAN is done.
Edit: if you do want to access it from outside, running a wire guard vpn locally is pretty easy to do.
I still want security in transit, no matter where it is being broadcast from.
You don't trust your home network?
You do‽ I know the person who runs it and they’re completely inept! /s
Yeah, but the user is also inept, so it evens out.
Honestly though, they could run a pair of docker containers, one with jellyfin one with wire guard and only have access to the jellyfin instance when logged into the micro sized vpn? (I think docker will let you play with networks that way, I'm experienced enough to be dangerous but not useful)
You could do a vpn hosting by yourself.
Meaning your server is basically a vpn tunnel server and you can connect from the Internet to it. Once you are in the encrypted vpn connection you have access to the local network.
If you have dynamic ip you need dns though. But no one can connect just because they know the ip)/dns
You could do a vpn hosting by yourself.
I'm uneasy about this, because I don't trust myself to do it securely. VPNs are a very complex piece of software, so I highly prefer to stick with widely used setups (i.e. "stock" VPN software such as ProtonVPN, Mullvad VPN, etc.)
Wireguard was written with the explicit goal of having sane, secure defaults. I totally feel you w.r.t. openvpn or ipsec, since it's easy to do something wrong. Wireguard is much easier because it simply refuses to give you the choice to do things incorrectly.
w.r.t. the certificate thing, you could set up a reverse proxy and do HSTS to ensure nobody can load up a rogue CA on your devices. HSTS has the issue that SSH has (trust on first use or whatever it's called), but you just need to make sure nobody is MITM you for that first connecting and then you'll be good to go. This would let you use a self-signed certificate if you do desired.
Wireguard was written with the explicit goal of having sane, secure defaults.
Wireguard is much easier because it simply refuses to give you the choice to do things incorrectly.
Security my beloved
I totally feel you w.r.t. openvpn or ipsec, since it’s easy to do something wrong.
This is one reason I've avoided selfhosting for this long. I am not a network engineer, and I have no plans to be. That means if I am managing an entire server from my physical home location, that's a recipe for disaster. There's simply no way to ensure you've done things correctly, especially since a lot of the selfhosting community has an... aversion to good security practices (which is why I had to make this post to begin with).
w.r.t. the certificate thing, you could set up a reverse proxy and do HSTS to ensure nobody can load up a rogue CA on your devices.
Would that work while having ProtonVPN still enabled?
trust on first use
My favorite food
This would let you use a self-signed certificate if you do desired.
Jellyfin clients don't accept self-signed certificates, as I mentioned. Is there a way around that (or does HSTS somehow solve it)? From what I've learned about HSTS up until know, it is simply there to require the use of proper certificates and HTTPS. Am I wrong about that?
What jellyfin client are you using that doesn't support self signed certificates?
A self-hosted VPN is the most secure free way to host your Jellyfin. I’ve had to learn the hard way over the years, but all the features and control you gain for hosting services yourself comes with all the same responsibilities and risk that the provider would be taking on for you.
The money you spend on their service is the alternative to the many hours it takes to learn how to properly host your own server.
You can definitely learn how to do it and it will be difficult and confusing at times, but that’s what the community is there for. I recommend joining a Matrix server or similar so you can get more real-time feedback for when you’re just getting started.
Totally understand not wanting to take the risk, though. Just something worth considering.
