Technology

There's a bug (closed as won't fix) where proxy basic authentication breaks jellyfin. You can't use it.

No. None of the items are closed. Click the "closed" items. All of them are "Not planned. Duplicate, see 5415".

Edit: The biggest issue of unauthenticated streaming of content... https://github.com/jellyfin/jellyfin/issues/13777

Last opened last week. closed as duplicate. it's unaddressed completely.

With unrestricted signups, they can obtain their own account easily. With their own account they can enumerate all your other users.

If they have their own account they can just find your instance, make a login, collect all the proof they need that you're hosting content you don't own (illegally own) then serve you a court summons and ruin your life.

I wouldn't worry about the vulnerability in the link since your already wide open. But I wouldn't leave Jellyfin wide open either. Movie and TV studios are quite litigious.

I hope you're at least gatekeeping behind a vpn or something.

Edit: typo

I guess the worst thing is that your server starts attacking the US military servers because you've become part of a botnet.

That happened to my friend one time when I installed Linux on his computer. He made the username and password the same 4-character word. Got a letter from the DoD.

I dont think they would be so forgiving these days. Especially if you're brown.

If you use normalized paths/file names (through *Arr stacks or docker mounts or otherwise common tools), then the hash that jellyfin sets up when it imports that media can be guessable. If someone was to go and precompile a list of hashes for content that they're looking for at common paths that people store their files at, they can ask your server for those hashes, and if their list is sufficiently large enough to include the path that you used, your jellyfin instance WILL RESPOND WITHOUT AUTHENTICATION.

I've been using this example because it shows how silly this is.

In the context of Sony’s top 1000 movies, they can pre-compile the top 100 likely paths for the file (/movies, /mnt/movies, etc) then run the 100000 hash check through scripts against your instance. How long does it take to let a crawler collect http statuses on 100000 page loads? Now put that to a bot that gets jellyfin instances from a tool like shodan and add more hashes. If you flag, now onus is on you to prove you have license for content and they would have a case that you distributing (albeit weak) since your server was open to the public. This is child’s play level abuse-able. Risking that something easy like this isn’t being abused by Sony and others (you know… willing to install a rootkit on your computer types…) is a very silly stance to take.

The answer to some of this is that you can just hide the content on a more complicated and less likely to guess path. That will sufficiently change the MD5 hashes enough that you should be more or less unguessable... Instead of using /mnt/media/movies (or /media/movies, or /movies/, etc...) make the path /mnt/k9RKiQvUwLVCjSqhb2gWTwstgKuDJx59S3J35eFzW2dgSSp84EG7PPAhf2MwCySt/media/movies. (obviously don't use this one... use a random generator. Make your own.)

The real answer should be that Jellyfin requires that all those endpoint need authorization/login. But their answer is "We don't want to break backwards compatibility. So we won't." Which is a bit silly of an answer. Those who use the default installation and organize their content with *arr suites (or with default docker settings/guide settings), are most likely to have guessable MD5 hashes and are most at risk.

Edit: Oh and the other point... if the "response" against this is "well that would take too long, or be too hard. You'd need a lot of money to find all these instances and test them...". We're talking about the likes of Sony... The ones that installed rootkits on peoples computers for daring to put a CD into a CD-ROM drive. They're litigious folk, and will bury you in paper and sue you to oblivion. It's not a lot of machine time to test a single server. Setting up a couple dozen scanners and just letting it go to find content on it's own isn't that bad from a computational standpoint.

And another argument I've seen here... "Well if they hack your server then that's illegal too, can't make a lawsuit out of that"... Except this is normal web operations. Bots and site scanners aren't illegal. Nor do they break any authentication mechanism (which is illegal) to do this. Specifically putting this behind authentication would make you correct. But Jellyfin didn't do that (yet). So guess what. It's perfectly possible for them to setup a few scanners across a few servers and do this 100% legally.

Security through obscurity isn't security.

Edit2: Clarification on not using the path I just gave... make up your own random gibberish.

Friends, family using Jellyfin is the reason many have it directly available (and not behind VPN for example).

Many of the issues are related to unauthenticated requests. Even though your reverse proxy provides SSL, Jellyfin still won’t know the difference between you and a random internet user. So, no, your setup doesn’t mitigate the security risks much at all.

short answer: no, not really

long answer, here's an analogy that might help:

you go to https://yourbank.com/ and log in with your username and password. you click the button to go to Online Bill Pay, and tell it to send ACME Plumbing $150 because they just fixed a leak under your sink.

when you press "Send", your browser does something like send a POST request to https://yourbank.com/send-bill-payment with a JSON blob like {"account_id": 1234567890, "recipient": "ACME Plumbing", "amount": 150.0} (this is heavily oversimplified, no actual online bank would work like this, but it's close enough for the analogy)

and all that happens over TLS. which means it's "secure". but security is not an absolute, things can only be secure with a particular threat model in mind. in the case of TLS, it means that if you were doing this at a coffee shop with an open wifi connection, no one else on the coffeeshop's wifi would be able to eavesdrop and learn your password.

(if your threat model is instead "someone at the coffeeshop looking over your shoulder while you type in your password", no amount of TLS will save you from that)

but with the type of vulnerability Jellyfin has, someone else can simply send their own POST request to https://yourbank.com/send-bill-payment with {"account_id": 1234567890, "recipient": "Bob's Shady Plumbing", "amount": 10000.0}. and your bank account will process that as you sending $10k to Bob's Shady Plumbing.

that request is also over TLS, but that doesn't matter, because that's security for a different level of the stack. the vulnerability is that you are logged in as account 1234567890, so you should be allowed to send those bill payment requests. random people who aren't logged in as you should not be able to send bill payments on behalf of account 1234567890.

Not really, no. These are application flaws. Caddy will happily do its job and just let bad actors abuse them. (Unless you mean mTLS certs, then Caddy would only respond to those having a client certificate, which hopefully reduces the number of bad actors to your users😉)

Not unless the reverse proxy adds some layer of authentication as well. Something like HTTP basic auth, or mTLS (AKA 2-way TLS AKA client certificates)

For nginx: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/

so if I add a user ”john” with password “mypassword” to video.example.com, you can try adding the login as: “https://john:[email protected]/

Most HTTP clients (e.g. browsers) support adding login like that. I don’t know what other jellyfin clients do that.

The other option is to set up a VPN (I recommend wireguard)

I'm also an absolute dumbfuck. And I can confidently tell you, as a matter of fact, that I don't know.

I'm running SWAG reverse proxy, my DNS is not tunneled, I share my Jellyfin with others outside my network.

My primary concern is my server gets hacked, or I get charged with distributing 'public domain movies'