I am making this post in good faith
In my last post I asked about securely hosting Jellyfin given my specific setup. A lot of people misunderstood my situation, which caused the whole thread to turn into a mess, and I didn’t get the help I needed.
I am very new to selfhosting, which means I don’t know everything. Instead of telling me that I don’t know something, please help me learn and understand. I am here asking for help, even if I am not very good at it, which I apologize for.
With that said, let me reoutline my situation:
I use my ISP’s default router, and the router is owned by Amazon. I am not the one managing the router, so I have no control over it. That alone means I have significant reason not to trust my own home network, and it means I employ the use of ProtonVPN to hide my traffic from my ISP and I require the use of encryption even over the LAN for privacy reasons. That is my threat model, so please respect that, even if you don’t agree with it. If you don’t agree with it, and don’t have any help to give, please bring your knowledge elsewhere, as your assistance is not required here. Thank you for being respectful!
Due to financial reasons, I can only use the free tier of ProtonVPN, and I want to avoid costs where I can. That means I can only host on the hardware I have, which is a Raspberry Pi 5, and I want to avoid the cost of buying a domain or using a third party provider.
I want to access Jellyfin from multiple devices, such as my phone, laptop, and computer, which means I’m not going to host Jellyfin on-device. I have to host it on a server, which is, in this case, the Raspberry Pi.
With that, I already have a plan for protecting the server itself, which I outlined in the other post, by installing securecore on it. Securing the server is a different project, and not what I am asking for help for here.
I want help encrypting the Jellyfin traffic in transit. Since I always have ProtonVPN enabled, and Android devices only have one VPN slot enabled, I cannot use something such as Tailscale for encryption. There is some hope in doing some manual ProtonVPN configurations, but I don’t know how that would work, so someone may be able to help with that.
All Jellyfin clients I have used (on Linux and Android) do not accept self-signed certificates. You can test this yourself by configuring Jellyfin to only accept HTTPS requests, using a self-signed certificate (without a domain), and trying to access Jellyfin from a client. This is a known limitation. I wouldn’t want to use self-signed certificates anyways, since an unknown intruder on the network could perform a MITM attack to decrypt traffic (or the router itself, however unlikely).
Even if I don’t trust my network, I can still verify the security and authenticity of the software I use in many, many ways. This is not the topic of this post, but I am mentioning it just in case.
Finally, I want to mention that ProtonVPN in its free tier does not allow LAN connections. The only other VPN providers I would consider are Mullvad VPN or IVPN, both of which are paid. I don’t intend to get rid of ProtonVPN, and again that is not the topic of this post.
Please keep things on-topic, and be respectful. Again, I am here to learn, which is why I am asking for help. I don’t know everything, so please keep that in mind. What are my options for encrypting Jellyfin traffic in transit, while prioritizing privacy and security?
Don’t.
https://github.com/jellyfin/jellyfin/issues/5415
Yeah, you shouldn’t, but OP seems determined to hamstring themselves and do everything as convoluted as possible.
Yeah, this whole thread feels like a “but I can’t do that, work around it for me”
Do. And make sure your logs are piped through fail2ban.
All of these “vulnerabilities”, require already having knowledge of the ItemIDs, and anyone without it poking around will get banned.
The rest of them require a user be authenticated, but allows horizontal information gathering. These are not RCEs or anything serious. The ones which allowed cross-user information editing have been fixed.
Don’t. OP already said in the previous post that they only need Jellyfin access within their home. The Principle of Least Privilege tilts in favor of keeping Jellyfin off the public Internet. Even if Jellyfin were flawless – and no program is – the only benefit that accrues to OP is that the free tier of ProtonVPN can access Jellyfin.
Opening a large attack surface for such a modest benefit is letting the tail wag the dog. It’s adding a kludge to workaround a different kludge, the latter being ProtonVPN’s very weird paid tier.
If they need SSL certs, they’ve got to. Jellyfin doesn’t accept self-signed certs, which means DNS entries in a domain, and access from the internet.
Really, honestly - what they need to do is just install Jellyfin on the Raspberry Pi and ditch the encryption requirement altogether. There’s no reason to have it on a LAN-only environment. They aren’t going to need it, nobody is going to MITM their lan environment, and VPNs will regularly allow LAN passthrough.
If ProntonVPNs own client doesn’t allow LAN connections, they either need to swap to the Wireguard vanilla client (if that’s allowed on free tier), or upgrade their VPN service.
OR switch VPNs altogether.
There isn’t a way to do this without breaking one of their requirements
Only options here are to publicly host with real SSL certs, on a domain and tunnel out – Or swap VPN providers/software so that you can achieve LAN access and forego HTTPS altogether.
Edit: And sorry – the previous post is gone regarding their only needing access within the home, there’s no way I could have known that.
There’s a bit of paranoia going on here to begin with - There’s no reason they need this level of “security” within their home network on the LAN side anyhow. They could possibly buy a managed switch and make the jellyfin server only visible to a specific vlan that didn’t include the router, but that doesn’t quite match up with what it sounds like they’re needing.
Huh?? My
jellyfin.home.labself-signed certificate would like a word… Just put everything behind a reverse proxy (in a self-hosted community you will sooner or later be confronted to one anyway…) And you get all your services behind self-signed certs. Doesn’t matter if Jellyfin accept or not… It’s encrypted through your reverse proxy !Hmm, that’s a good point. I just checked my Jellyfin, and I don’t put any of the cert data into its config, I’m using caddy as my reverse proxy to serve it and I didn’t even think about this. No reason it has to be a self-signed cert, it could technically be local only and still be a Let’s Encrypt cert.
The latter is not a requirement at all. Plenty of people have publicly-issued TLS certs for domain named services that aren’t exposed to the public internet, or aren’t using HTTP(s). If using LetsEncrypt, the DNS-01 challenge method would suffice, or can even issue a wildcard certificate for subdomains, so additional certificate issuance is not required.
If after acquiring a domain, said domain can be pointed to one of many free nameservers that provide an API which can be updated from an ACME script for automatic renewal of the LetsEncrypt certificate using DNS-01. dns.he.net is one such example.
OP has been given a variety of options, each of which come with their own tradeoffs. But public access to Jellyfin just to get a public cert is not a necessary tradeoff that OP needs to make.
Came to suggest this. I ran into the same problem when I tried to host Jellyfin at home. Also I was fed up with all those certificate warnings, depending on which device I used. Since I was already using pihole in my home network, I just went and looked at all the DNS plugins for certbot to learn which provider allows for easy DNS challenges. Then I researched a bit and stumbled upon a provider that was running a sale - so I got a domain for less than 5 bucks/year.
I set the public A record to 127.0.0.1 and configured certbot to use their API. This domain is now used internally in my network exclusively and I just added some DNS entries for several subdomains in pihole, so that it works for every device at home (e.g. jellyfin.example.com / dockerhost.example.com / proxmox.example.com / …).
When I’m away, I shouldn’t be able to resolve the domain, and even if DNS were hijacked, the TLS certificate will protect me from connecting to $randomServices. Also my router is less restricted, which means that I can just use it’s VPN server to connect directly to my home network, if I need to access my server or need to troubleshoot things when away.
Which are simply MD5 hashes… You can precompile (rainbow tables) those. The “knowledge” here to get a valid video stream is “What path is the file on” which is pretty standardized. This is a good way to have a major movie studio’s process server knocking on your door.
And again - if you put those behind a fail2ban; and you 404 5x in an hour, which is likely - you’ve solved that issue. Had my jellyfin instance publicly available for 2 years on its own VM with passthrough GPU, and haven’t had any issues. People poke around quite often, and get blackholed via the firewall for 30d.
It wouldn’t stop a dedicated attacker, but I doubt anyone’s threat model here is that intense. Most compromised servers happen from automated attacks probing for vulnerabilities in order to get RCE; not probing for what movies you have – Because having movies on a media server doesn’t prove that you didn’t rip them all off of blu-ray…it just means you have movies.
You’re not going to have 100% privacy when you put up ANY service on your network. Everything leaves a trace somehow; but I’m starting to think half of you are Chinese spies or something with the amount of paranoia people here show sometimes. :P
I was going to leave this alone… your original comment was correct enough that it wouldn’t matter and your “dedicated attacker” left it fine when i read it before.
but your edit has a gaping flaw. you assume that all content in the library would be physically released. lots of shows and movies are not physically released now. Can’t claim “backup” for those. The moment a movie studio finds your stuff and can map a few titles and one of them never had a physical release… your in the shit.
but yes you can be much harder to scan overall with a few steps. fail2ban is a great answer that makes it deeply unlikely to be an issue.
but i wish that they’d just fix it.
edit: OR that they wouldn’t try to go after you for distribution…