As others have mentioned, running plex and enabling plexpass posses a major security risk which many members would like to see fixed. Speaking with people on the Plex Subreddit, I've decided to make a complimentary post here from this thread http://www.reddit.com/r/PleX/comments/2e3rvl/plex_needs_better_security_privacy_and_encryption/
Any chance we could get the developers to take the security issues more seriously
Anyone interested in this should have a read over this thread:
A permanent solution to this is long overdue, but allowing users to use their own certs and domain names would be a good and relatively easy to implement stop-gap until Plex can create the infrastructure to sell SSL certs/sub domains to those that would like to avoid the hassle of doing it themselves.
For the benefit of everyone, let's explain the situation fully. What specifically are the gaping security holes in Plex?
enabling plexpass posses a major security risk
What specifically is this security risk? How does it affect users? What do you think should be done about it?
I'd be willing to buy a full featured SSL cert if that's what it would take to make this work.
For the benefit of everyone, let's explain the situation fully. What specifically are the gaping security holes in Plex?
What specifically is this security risk? How does it affect users? What do you think should be done about it?
If you use plex remotely, all communication between a remote client and your PMS server is done in the clear -- no encryption. Anyone between you and your PMS server basically have the keys to the castle (yes, a bit of an overstatement, but not by much) -- all they need to do is look at the unencrypted network traffic passing through their network.
Currently the only way to secure this is to simply not allow remote access to your Plex server (block/don't open the ports on your firewall), or block the ports and use a VPN (complicated to setup and maintain -- especially on mobile devices).
1. What should be done in the short term is to allow users to use a domain name, install their own, valid, SSL certificates from a trusted certificate authority, and force all clients to use SSL for communication with your PMS server. (StartSSL's free certs would work perfectly in this case.) Once this is done on the server, everything else would just work. No extra client configuration.
Unfortunately, registering a domain name, setting up dynamic DNS and then creating and installing a certificate from a certificate authority is far too technical for most users. They simply wont do it.
2. In the long term, Plex should create the infrastructure and sell a subscription for secure remote access (automatically creates a subdomain and a valid cert for said subdomain) to those that don't want to jump through these techy hoops to secure their connection.
#1 wouldn't take much work at all on Plex's part to implement. It should be done immediately.
#2 will take more time, but has the reward of another revenue stream for Plex.
More information can be found in this thread:
The ideal implementation for PlexPass members would be if PMS would automatically generate a CSR (Certificate Signing Request) that would be signed by Plex themselves, serving as the CA (Certificate Authority). Any Plex client can be programmed to trust Plex as a CA. Of course this is labor intensive, but it could work very well and help to add value to the PlexPass subscription.
The ideal implementation for PlexPass members would be if PMS would automatically generate a CSR (Certificate Signing Request) that would be signed by Plex themselves, serving as the CA (Certificate Authority). Any Plex client can be programmed to trust Plex as a CA. Of course this is labor intensive, but it could work very well and help to add value to the PlexPass subscription.
Any Certificate Authority (CA) would need to have broad browser support in order to work with Plex Web. If Plex were to become a CA today, it would be some time before they were implemented in the majority of OS/Browsers, if ever, requiring the user to manually install the cert on the client. Similarly, self signed certs are not an option.
To maintain transparent compatibility with Plex Web, Plex would need to resell certs from an entrenched CA. APIs are available from a number of CAs to help with this.
I imagine that Plex is currently working on having Plex's own servers securely relay metadata, but I hope not. This, IMHO, is the WRONG approach. First, I don't want my media's metadata going through Plex servers, and second, it leaves the stream requests, that would still need to be served from your local PMS server, unencrypted and open to harvesting.
I think you’re missing something. A certificate signed by Plex is essentially a self-signed certificate, which would simply trigger the typical warning in standard browsers. Once the user accepts the certificate, everything afterwards is encrypted,
The primary advantage is that the various Plex client applications can themselves be coded to automatically accept these certificates.
I think you're missing something. A certificate signed by Plex is essentially a self-signed certificate, which would simply trigger the typical warning in standard browsers. Once the user accepts the certificate, everything afterwards is encrypted,
The primary advantage is that the various Plex client applications can themselves be coded to automatically accept these certificates.
A couple things:
1. Accepting and bypassing a certificate warning as a matter of practice is not a good idea. It's really only something you do in development, but definitely not in not production, and not something you want to train your users to do. Yes, it may be encrypted, but no, you can't really trust the connection.
2. When using Plex Web via Plex.tv, scripts served from plex.tv will ajax call your PMS server. Without the CA certificate installed on the client, the ajax calls will fail silently (will not prompt the user with a security warning.) It would take some ugly scripting to detect this, pop up a modal with the security warning so the user can bypass a potential security issue (see #1), and then continue -- only to be bothered by it again the next time they use Plex Web in a fresh session.
If there wasn't Plex Web to be concerned with, I'd agree with you.
The ideal implementation for PlexPass members would be if PMS would automatically generate a CSR (Certificate Signing Request) that would be signed by Plex themselves, serving as the CA (Certificate Authority). Any Plex client can be programmed to trust Plex as a CA. Of course this is labor intensive, but it could work very well and help to add value to the PlexPass subscription.
Problem here is that anyone can buy/get a certificate, so man-in-the-middle attacks are still possible with valid certs. That is a typical issue with a too large CA with too few controls over identity.
The only real solution is working with a self-signed cert on the server, which gets pushed to the apps when they connect for the first time (like connecting to Radius or SSH for the first time: you get an explicit request to accept the certificate), preferably through the secure channel from Plex.tv (which does have a publicly trusted cert). Alternatively, the certificate is locked to a specific certificate and escalates when an untrusted (but valid) certificate is encountered.
The browser is a problem, however you put it. Having Plex.tv working as a proxy would be an option, but it would quickly become messy.
Jaap
The primary advantage is that the various Plex client applications can themselves be coded to automatically accept these certificates.
Automatically accepting certificates because the root-CA is trusted, but effectively has no control over it (anyone can buy these certificates!) is quite a bad practice. Explicitly handling new certificates (like for example Putty does for SSH, or Windows does when a Radius server is encountered) is essential for preventing man-in-the-middle attacks.
Jaap
I agree browsers are going to be problematic. With regard to Plex clients, I don’t think they would be as vulnerable as that. The PMS would need to authenticate against plex.tv, with the PlexPass member’s credentials, in order to acquire a certificate, and this communication itself would happen over a secure socket.
Sent from my iPad using Tapatalk
I agree browsers are going to be problematic. With regard to Plex clients, I don't think they would be as vulnerable as that.
Yes, but the client, being written by Plex, would be configured as needed.
Sent from my iPad using Tapatalk
Yes, we’d just hope that Plex doesn’t take an insecure shortcut 
+1 there are a lot of security tools missing
++ security + sync fixes
Implementing SSL (HTTPS) for Plex web would be easy. However, Plex supports a lot more devices other than web browsers. I don't think you could unilaterally force SSL or TLS.
Implementing SSL (HTTPS) for Plex web would be easy. However, Plex supports a lot more devices other than web browsers. I don't think you could unilaterally force SSL or TLS.
AFAIK, all the remote devices, the ones that need SSL/TLS, support SSL/TLS.
The issue is certificates. Some of the clients, like Plex Web and, I believe, iOS (Plex on iOS depends on what certificates iOS supports because it uses the native iOS video player), are dependent on what certificates the host OS support.
AFAIK, all the remote devices, the ones that need SSL/TLS, support SSL/TLS.
The issue is certificates. Some of the clients, like Plex Web and, I believe, iOS (Plex on iOS depends on what certificates iOS supports because it uses the native iOS video player), are dependent on what certificates the host OS support.
Speaking with some iOS experience, but knowing nothing about how Plex/iOS is written, the standard iOS AVPlayer class supports playback of HTTPS streams encrypted with self-signed certificates.
