Comment on I don't know who needs to hear this, but DO NOT EVER expose Jellyfin to the internet

walden@sub.wetshaving.social ⁨1⁩ ⁨week⁩ ago

• beek@beehaw.org ⁨1⁩ ⁨week⁩ ago

  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.

  source
• spit_evil_olive_tips@beehaw.org ⁨1⁩ ⁨week⁩ ago

  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.

  source
• Mora@pawb.social ⁨1⁩ ⁨week⁩ ago

  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😉)

  source
• Zozano@aussie.zone ⁨1⁩ ⁨week⁩ ago

  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’

  source

  • Flax_vert@feddit.uk ⁨1⁩ ⁨week⁩ ago

    Hacking, even on an insecure system, would be illegal. Any copyright troll trying to sue a single user for having a private jellyfin instance which they hacked to find out about would probably have a hard time actually making a case.

    “Yeah, this one guy was distributing films to himself and a few friends. I know because I hacked him” doesn’t seem like a good case.

    source
• mark@social.cool110.xyz ⁨1⁩ ⁨week⁩ ago

  @walden @Scary_le_Poo Only if the reverse proxy has its own login on top of Jellyfin's, and even that only mitigates some of them.

  source