Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?

  • Nibodhika@lemmy.world
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    1
    ·
    15 hours ago

    Secure is relative, you should be aware that jellyfin itself has security issues https://github.com/jellyfin/jellyfin/issues/5415 most of which are harmless, but at least one is fairly serious and allows people to watch your media without authentication, and adding an extra layer of authentication on the proxy would likely cause issues with clients.

    That being said, if you’re okay with those security issues what I would do is have a cheap VPS, connect both machines to tailscale, and have something like Caddy on the VPS to do the forwarding.

    • exu@feditown.com
      link
      fedilink
      English
      arrow-up
      26
      ·
      15 hours ago

      Just leaving this here

      Now, let’s address this clearly once and for all. What is possible is unauthenticated streaming. Each item in a Jellyfin library has a UUID generated which is based on a checksum of the file path. So, theoretically, if someone knows your exact media paths, they could calculate the item IDs, and then use that ItemID to initiate an unauthenticated stream of the media. As far as we know this has never actually been seen in the wild. This does not affect anything else - all other configuration/management endpoints are behind user authentication. Is this suboptimal? Yes. Is this a massive red-flag security risk that actively exposes your data to the Internet? No.

      https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290

      • Nibodhika@lemmy.world
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        1
        ·
        12 hours ago

        Except most people have almost the same structure because of media organizers like radarr/sonarr. At the very least they should hide that behind a setting to not require auth (since the header should be there for most clients) so only people running an old client would be affected. They could also add an extra salt to that hash or something similar.

        I agree, it’s not critical, but it shouldn’t be hand waved either. And like I said, security is relative, I would argue for most people this is fine, but I still think this should be taken more seriously.

        • BakedCatboy@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          10 hours ago

          Yeah not only would a lot of people have the same media name, because of docker mounts, probably a lot of people have the same path to the media inside of the docker container even if the external location is different. I bet you could make a rainbow table of sorts of the most popular movie/TV torrents combined with the most common place in the container for media to be mounted, then use shodan to get a list of hundreds of instances that you could scan for the common hashes.

          I’m just seeing the issue for the first time and noticed it was raised 5 years ago - surely that was enough time to at least put forward a changeover date and give clients time to update.

          • Flatfire@lemmy.ca
            link
            fedilink
            English
            arrow-up
            1
            ·
            5 hours ago

            Jokes on them, my paths are a shitshow and I can’t be bothered to organize them properly

            • BakedCatboy@lemmy.ml
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              4 hours ago

              Do you not do any renaming? That probably would make it even easier as you can just brute force with a database of filenames scraped from torrents. I already have a proof of concept that generates valid jellyfin IDs from any given file path, it only takes a few more steps before you can plug in a shodan scan of jellyfin instances and just shotgun a bunch of IDs generated from torrents.csv at them and find stuff you can stream without authentication.

              People not bothering to rename, using the default radarr naming scheme, or everyone using the same naming pattern from trash guides just makes it easier.

              Probably the only way to guarantee nobody can probe your media and stream it without authentication is to make sure to rename everything using a format that only you use or mount all your media under a path inside docker that contains a long randomly generated folder prefix.

              • Flatfire@lemmy.ca
                link
                fedilink
                English
                arrow-up
                1
                ·
                3 hours ago

                I was mostly making the comment in jest. I do rename, but my folder structures, as someone who downloads everything manually based on what I want to watch rather than doing the automated *arr stuff leaves it in directories only I consider sensible.

                I have Jellyfin behind a reverse proxy that lives in a DMZ and a WAF to go with it. I’m sure there’s still room for watching an unauthenticated stream because I forgot to rename a folder somewhere, but it’s not exactly an attack vector I care about. I’m more concerned about DDoS or impersonation attacks, which I also attempt to mitigate via an LDAP implementation behind the scenes.

                It’s not perfect, but it’s the best effort I can make at the moment.