Motiviation: for the sake of privacy I configured PMS to require secure connections. After i realized samsung for smarthub has playback problems (seems like the tv cpus are not fast enough) at the end of streams during secure playback, I had to change the setting back to prefered. Now my WAN users are able to use unsecure connections again. As a huge fan of privacy I feel pretty uncomfortable with it.
Req: a setting to define an ip-range with it’s own secure connection setting.
preferably the ip-range is defined the same way “list of networks that do not require authentification” is implemented.
Any chance of this happening? I feel like it’s no harder than the no-auth list, and would greatly increase security for those of us who would otherwise have to use “preferred” to accommodate TVs and such.
You can, but it still requires encryption if that setting is set. My TV’s Plex app is too old to run encryption and since my plex talks across the internet I’d rather require encryption. I don’t need encryption for my local LAN connected TV to talk to my local LAN connected Plex server though.
Bumping this - we really need the ability to whitelist IP ranges to allow some specific non-secure connections, especially when many of the Plex apps (for TVs mainly) don’t support Secure Connections.
I really want to be able to use my new Smart TV (LG WebOS) with Plex on my local home network, but definitely don’t want to allow unencrypted connections over the Internet.
Because users might use a faulty reverse proxy setup in combination with an entry for the reverse proxy ip or its ip-range in the “List of IP addresses and networks that are allowed without auth”, that would ultimately result in an unprotected pms instance, which could be accessed from everyone, regardless whether their connection actualy is from the local lan or the internet.
Previously PMS did not pick up the X-FORWARDED-FOR header, set by the reverse-proxy, to determine the real client-ip. Since a couple of months it does. Enabling it in the reverse-proxy eliminates the prevously mentioned threat.
Now here is the thing: according Plex employees operating plex behind a reverse proxy is an unsopported szenario, but on the other hand the argument to not support this feature request. Funny, how unsupported scenarios can affect the supported ones
Oddly, the exact same unspported szenario allows to enforce secure remote connections while allowing unsecure local connections. Though, the setup is way more complicated then having a white-list, especially when the PMS instance is on a dynamic ip.
I’m curious if it could be implemented to allow unsecure connection if it’s coming from the LAN but not if coming from the WAN? My specific use case for this is that I have some apps that run in my LAN that I would like to have API access over the LAN and they don’t need to use SSL for this. When I have plex Secure Connections set to “Required”, those apps are then required to connect via SSL when this isn’t really necessary.
We already have the option to bypass authentication via the “List of IP addresses and networks that are allowed without auth” option. Maybe this could be leveraged and if the connection is coming from one of those network or IPs in that list, It not only doesn’t require authentication, it doesn’t require HTTPS either.
Personally, I see not requiring authentication as a bigger concern that not using HTTPS over the LAN so if there’s already a setting to bypass authentication, I don’t see why we couldn’t utilize that list to also allow bypassing HTTPS.
This option would ensure that connectivity over the WAN Requires HTTPS where it matters most and connectivity over the LAN would not.
I know there is technically a way around this using DNSMASQ for plex.direct but I think it would be much easier for people to have the ability to just bypass HTTPS while on their local LAN.
I understand that and I see in other posts where you specifically have posted that exact same reply so I do get this concern. However, my point is that I would be the one making that conscious decision to trust those IPs and trust that they are not being spoofed within my network. The feature to allow IPs to bypass authentication already exists. This to me is a far greater concern than allowing a private IP address to not require SSL. Not requiring authentication at all seems like a much greater security concern and that feature currently exists. Would you not agree?
EDIT: To be clear. I would not intend for this to be a default option or always open. I’m suggesting that it would be an option that could be enabled if desired.
I could see this as a valid concern as well. I see your point. I think at that point though, someone is in your network sniffing packets and you have bigger concerns than someone getting your Plex credentials.
Of course there is the potential scenario that you are in a shared LAN environment with no client isolation. In a scenario like that, you simply would not use this feature. It might even be best to have a warning under the feature that it should be used with caution in a shared LAN environment. Along those lines, it would probably be a good idea to add that type of warning under the existing feature that allows you to bypass authentication as well.
As a compromise to this though, since it’s already a feature to allow no login, maybe this could be a subset of that feature. Under that text box there could be a checkbox to indicate that you also allow those clients to bypass HTTPS. This way there are no credentials being passed in clear text because there are no credentials being passed at all. If you’re already allowing that IP to gain access without credentials then I don’t think there’s a large concern over using HTTPS for it.
