Comment

Comment on Plex is locking remote streaming behind a subscription in April

You are, authentication on the VPS, you’re relying on Jellyfin authentication against the internet. Correct me if I’m wrong, but this is your suggested setup: [home server] Jellyfin -> [remote server] Reverse Proxy -> [remote machine] users. Let’s imagine a scenario where Jellyfin has a bug that if you leave the password empty it logs you in (I know, it’s an exaggeration but just for the sake of argument, an SQL injection or other similar attacks would be more plausible but I’m trying to keep things simple), on your setup now anyone can log into your Jellyfin and from there it’s one jump to your home server. On Plex’s solution even if Plex authentication gets compromised the attacker only got access to the remote server, and would now need to find another vulnerability to jump to your Plex at home.

Putting something like Authelia/Authentik on a VPS in front of Jellyfin is a similar approach, but the Jellyfin client can’t handle third party authentication AFAIK

source

Sort:hotnew top

couch1potato@lemmy.dbzer0.com ⁨2⁩ ⁨weeks⁩ ago
My interpretation of your linked instruction (granted, I haven’t tried plex) is that it’s the same two scenarios.

Your plex client app login talks directly to your server login. The client app meeting the server is arranged by the plex relay server and nothing more. There is no ‘logging in’ to the plex relay server; it’s function is to arrange a meeting of two tunnels and that’s it, much like a tailscale derp server.

The relay server is serving the same function as caddy on a VPS, hell, they could even be using tailscale under the hood and it’d look exactly the same to a user.

Anyway, attack vectors even with a public facing jellyfin are mitigated because

a) jellyfin is running in a docker container = a successful attacker would only be able to trash my jellyfin container, which ultimately is not that big of a deal (unless there is a different docker exploit that enables access to the server itself, which is an entirely different issue and larger than a jellyfin/plex discussion)

b) fail2ban in conjunction with a reverse proxy bans malicious ip addresses that come back with too many errors too many times (errors that you, the admin, specify) So, for example, brute force login attacks are mitigated.

c) the reverse proxy itself allows access to only one specified internal ip address/port combination. Pending a caddy exploit (again, a different discussion) it is not possible to fish for acrive ip addresses or port scan my internal network.

source
- Nibodhika@lemmy.world ⁨2⁩ ⁨weeks⁩ ago
  First of all I agree with most of your a, b and c points, just would like to point out that while it’s true that Docker containers provide an extra level of security they’re not as closed down as people sometimes believe, but as a general rule I agree with everything you said.
  
  But you’re wrong about the way Plex works, this is a quote from their documentation:
  
  So, your Plex Media Server basically “relays” the media stream through our server so that your app can access it since the app can’t connect with your server directly.
  
  If that’s not clear enough:
  
  Your security and privacy is important to us. When you have enabled secure connections on your Plex Media Server, then your streaming will continue to be secure and encrypted even when using our Relay feature. (When using secure connections, the content is encrypted end-to-end and tunneled through our Relay. The connection is not terminated on our servers and only your Plex Media Server has the certificate.)
  
  So it’s very clear data is streaming through their relay server, which goes back to my original point of I expect that to be a paid feature, it’s using bandwidth from their relay servers.
  
  As for the security again you’re wrong, authentication happens on the Plex remote server, not on your local one, which is why you can’t use Plex without internet (part of my dislike for them). So you connect to Plex remote server and authenticate there, you then get a client that’s talking to the remote server, even if someone was able to bypass that login they would be inside a Plex owned server, not yours, they would need to then exploit whatever API exists between your home server and that one to jump to your machine, so it’s an extra jump needed, again similarly to having Authelia/Authentik in front of Jellyfin.
  
  source
  - couch1potato@lemmy.dbzer0.com ⁨1⁩ ⁨week⁩ ago
    Okay. I finally understand what you mean 🥲
    
    Authenticate a self hosted software stack in someone else’s cloud 😂
    
    That is a wild design choice. Glad it works for some…
    
    Anyway… apologies for being ignorant
    
    source
    Nibodhika@lemmy.world ⁨1⁩ ⁨week⁩ ago
    No need to apologize, it’s a weird choice from Plex, I would have never guessed that this is how it works if I hadn’t suffered outages myself, and I’m amazed that not many people call them out on this, it seems completely against what most self-hosting people are looking for, but they seem to defend Plex with teeth and nails.
    
    source