(edited post)
I agree with you on principle here. But given that many people use Plex while travelling, and that criminals are already harvesting AND selling Plex login credentials, I prioritize the active tampering scenario.The "shared wildcard cert" solution isn't completely useless. The issue is more nuanced than that. We need to define a threat model here and prioritize the scenarios.
I in essence proposed this as well. As long as the Plex.tv server transfers the keys without knowing what is transferred with these keys, all communication stays private as well. This would work everywhere where there are clients available that interact in that way. I don't know if the webclient would work like that. But perhaps that would be an acceptable sacrifice, given that almost any platform has a client....Plex has all of the ingredients to make this work without relying on the SSL stack, though. Let's pretend that we only care about media data right now – audio/video segments. That's the stuff that must be delivered directly from your server to your device to achieve reasonable playback performance. That's the challenging part here. (All of the other queries could theoretically just get proxied through plex.tv.)
To encrypt media data without SSL, you just AES-encrypt the media segments using a shared secret. (That's how video CDNs typically work. CDNs don't like to stream video over HTTPS due to overhead, but want to support confidentiality, so they stream encrypted video segments over unencrypted HTTP.) Both the client and the server already have secure SSL connections to plex.tv, so Plex just needs to use that connection to transfer the shared secret. (PMS --ssl--> plex.tv --ssl--> Plex client). In fact, HTTP Live Streaming includes built-in support for this type of "clear key" encryption, and it's widely supported by clients. Now you have a way to securely information between the server and the client without needing to share SSL keys, buy thousands of certificates, or deal with DNS issues.
Jaap
As long as the Plex.tv server transfers the keys without knowing what is transferred with these keys, all communication stays private as well.
If it's proxying through plex.tv, it's not private.
If you just use Plex.tv as a secure way to exchange/distribute keys, it doesn't matter. Plex.tv will have the keys, but no access to the "secrets" since they are communicated directly between client and server.If it's proxying through plex.tv, it's not private.
And we do have to realize: Plex acts as a central authentication service to our servers anyway: so trusting Plex is a necessity anyway to some extent. They might not have direct access to the full file-listing, but they could if they wanted to (since they are the gatekeepers)
Jaap
so trusting Plex is a necessity anyway to some extent.
I wouldn't say it's a necessity. It's is part of the current security/privacy issues. Something that can, and hopefully will, be addressed.
considering that none of the owners/devs are participating in this thread shows me that they don't really care about security. it's just a matter of time in my opinion that plex dies out maybe, 1 SUPER bad security breach and they will lose a majority of their followers/users.
im trying to figure out how to incorporate using MediaBrowser.tv but it's difficult because a majority of my family members use Chromecast which doesn't have a MB application. it seems the feature are so much better with MediaBrowser as well. Just a suggestion, it's best to do research and not just roll over for Plex and their insecurities.
Unless you can completely eliminate Plex.tv from the architecture as central authentication-point, you have to trust it.I wouldn't say it's a necessity. It's is part of the current security/privacy issues. Something that can, and hopefully will, be addressed.
I agree that I would have chosen a different authentication model (by using a more federated model where I would authenticate against my own server), but given the current model you simply have no choice. As I see it, the fact that Plex.tv decides that you are you based on some password/PIN where they maintain a central database already hands them keys to the kingdom. To make life easier, they also keep records where your frontdoor is currently located. So if you don't want to trust them, IMHO you are using the wrong product. They could walk in and walk out without being seen, since they are the keykeeper.
Moving to a federated model of authentication is something I would favour because it would make my install much less dependent on Plex.tv availability (I seriously doubt my server can authenticate me if my WAN goes down but my LAN and local clients are alive), but seeing the way they used managed accounts and Plex-accounts side-by-side, I seriously doubt that is the way Plex.tv likes to go.
That being said, I think that I don't want to give Plex more data/access than they already have. Making Plex.tv responsible for being the secure channel for public key-exchange would be as far as I would be willing to go. I would make them keys with a session-lifetime, so there would be no harm in that given the fact that the rest of the communication is out of reach for Plex. In practice you use Plex.tv as a secure channel for the handshake, and then forget about it.
Jaap
That being said, I think that I don't want to give Plex more data/access than they already have. Making Plex.tv responsible for being the secure channel for public key-exchange would be as far as I would be willing to go.
Having a "public" vs. private key is the, well, key to solving the privacy issue. For authentication, no one but the client should ever need to know exactly what the private key is.
considering that none of the owners/devs are participating in this thread shows me that they don't really care about security.
I wish I could say more, but they do understand the issues, they have a solid a plan, and they are working on it.
The "shared wildcard cert" solution isn't completely useless.
I would say it's worse than completely useless. It gives a false impression of security.
I guess this goes the same way as the "Parental Controls" discussions. The dev-team (especially Elan) have taken a lot of flak for being *&^$%@#!%?'s that don't listen to the number one request of their customers. In the end it clearly showed they did a very good job analyzing and implementing something we wanted.I wish I could say more, but they do understand the issues, they have a solid a plan, and they are working on it.
As I see it, the problem isn't caring about the product or the customers. The problem is communicating that they are working on a good solution which will suit our needs and managing the expectations when it will come. This is hard as it is, and the general approach (we keep our plans secret) doesn't help here.
Let's hope the solution comes before it is too late.
Jaap
(edited post)
Plex has all of the ingredients to make this work without relying on the SSL stack, though. Let's pretend that we only care about media data right now – audio/video segments. That's the stuff that must be delivered directly from your server to your device to achieve reasonable playback performance. That's the challenging part here. (All of the other queries could theoretically just get proxied through plex.tv.)
To encrypt media data without SSL, you just AES-encrypt the media segments using a shared secret. (That's how video CDNs typically work. CDNs don't like to stream video over HTTPS due to overhead, but want to support confidentiality, so they stream encrypted video segments over unencrypted HTTP.) Both the client and the server already have secure SSL connections to plex.tv, so Plex just needs to use that connection to transfer the shared secret. (PMS --ssl--> plex.tv --ssl--> Plex client). In fact, HTTP Live Streaming includes built-in support for this type of "clear key" encryption, and it's widely supported by clients. Now you have a way to securely information between the server and the client without needing to share SSL keys, buy thousands of certificates, or deal with DNS issues.
I'm loving this idea. At the moment a client learns of a servers public IP and port from Plex.tv and then sends a request in plain including a token to that socket. If Plex.tv could also hold a PSK that is also sent when a client requests the socket then it could encrypt its request using the key. The server is also told what PSK it is using for that day/week/client.
I'm loving this idea. At the moment a client learns of a servers public IP and port from Plex.tv and then sends a request in plain including a token to that socket. If Plex.tv could also hold a PSK that is also sent when a client requests the socket then it could encrypt its request using the key. The server is also told what PSK it is using for that day/week/client.
This would only be a partial solution. It wouldn't take care of images and image thumbnails without adding performance killing hacks. Since many are storing family photos, they will want them as secure as well.
All this would do is distract from the final, and required, goal of fully securing all communications.
The big question is: securing from who?All this would do is distract from the final, and required, goal of fully securing all communications.
All the bad hackers on the net, or also the good people from Plex. I know by experience that not trusting the middle man by design has a huge impact on the design. Having an agreement on that scope is crucial, IMHO.
Jaap
The big question is: securing from who?
Anyone.
Encrypting just the keys and video streams still leaves other elements open, like images. Do we just serve images in the open, to anyone? Do we encrypt them, thereby dramatically complicating client display of thumbnails on many of the clients? We can't use the current token authentication, because we haven't secured the image request channel (no HTTPS), and we shouldn't use time sensitive tokens for image request authentication, because then we're back to complicating the client request/display of thumbnails (caching, etc.).
Netflix et al. uses this model because they don't care about thumbnail/image security, and it eases media distribution from CDNs. But it doesn't yet fit well for Plex -- not without adding HTTPS for all other communications first. (It would be good for Plex's cloud sync., where files that are synced to the cloud could be pre-encrypted. I had requested this awhile back in another thread -- but we need HTTPS support first.)
+1
+1 Plex needs to care more about our privacy.
+1 for TLS.
Would running Plex traffic through a home OpenVPN Server be enough to protect you? I do have PIA and have successfully set it up to work with Plex but unfortunately PIA only gives users 1 port to forward and I need that port for a different program. I do have a home OpenVPN server so I am wondering if I could just encrypt Plex traffic with that?
Would running Plex traffic through a home OpenVPN Server be enough to protect you? I do have PIA and have successfully set it up to work with Plex but unfortunately PIA only gives users 1 port to forward and I need that port for a different program. I do have a home OpenVPN server so I am wondering if I could just encrypt Plex traffic with that?
Yep - if you disable the external access from the Plex Server (manually specify a port in the Settings -> Server -> Connect section of the UI) then *don't* forward it on your router, you should end up signed into myplex OK, but with a warning that the service isn't contactable from the outside world. You will need to use the local PMS admin UI now, not the plex.tv one (PMS IP:32400)
Then on your remote clients, you need to manually add a connection (Settings -> Advanced -> Manual connections) with the internal IP address of your PMS.
From then on, if you run the OpenVPN client, fire up the plex app it should connect to the remote PMS and sync etc as expected...
