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...
Unless you've configured your client/VPN to route ALL requests (not just LAN requests) over the VPN, the client could still be convinced to leak a token when it tries to connect to your plex server on its external, but inaccessible, address/port.
Unless you've configured your client/VPN to route ALL requests (not just LAN requests) over the VPN, the client could still be convinced to leak a token when it tries to connect to your plex server on its external, but inaccessible, address/port.
Surely the risk would be much reduced though - as the server isn't externally accessible, so the token would be reasonably useless anyway..
I agree it's not an ideal situation though, we are working round a problem that really needs to be fixed...
Well I guess for the time being, any time I am using a public internet connection I will have to turn in my VPN before I do anything with Plex. While it’s inconvenient it’s not the end of the world for be but the problem lies if I want to give access to a family member. I doubt they would remember to use the vpn in that situation. It’s really a shame I have to worry about that sort of thing.
So plex-web is the hard one the solve. For Android/iOS devices it wouldn't be that hard for a plex install to generate a key pair and upload the public key to plex.tv attached to your account. Then plex clients can grab the public key for the server when they authenticate with plex.tv and then use the key to authenticate communication with your server.
To deal with plex-web the generated key could be for your plex server's external domain name (how else are you connecting to your plex-web). Then you visit http://yourplexserver.example.com It does a quick https ajax call to see if you have the cert and if you don't it redirects you to https://cert-install.plex.tv where you login with your plex-pass account and the page displays how to install the public key for your plex-web install into the browser you are currently using. This is annoying but a one time thing and since we are using a secure connection to a secure public key escrow (plex.tv) we should have a complete chain of trust.
This requires no purchased certs
This has minimal traffic increase for plex.tv
This has minimal storage increase for plex.tv, public keys are tiny
This would essentially solve all of the security concerns, all traffic from your plex server would be encrypted with the private key that only you have, there is no need for even plex.tv to know your private key.
When you share your library with a friend it would give them access to your public key that is stored on plex.tv as well to provide them with the ability to securely access your server.
Then you visit http://yourplexserver.example.com It does a quick https ajax call to see if you have the cert and if you don't it redirects you to https://cert-install.plex.tv where you login with your plex-pass account and the page displays how to install the public key for your plex-web install into the browser you are currently using.
You can't assume that every user will be able to install certificates. They could be limited by their technical proficiency, or the access they have to a given workstation. This quickly changes Plex web from the ubiquitous client to being much less than.
That's fine for an open source project like MB3, but not really a viable long term option for a commercial product like Plex.
Because the changes to the server and clients to add UI for installing/managing/pinning self signed certs would take away from time to implement it "properly".
Because the changes to the server and clients to add UI for installing/managing/pinning self signed certs would take away from time to implement it "properly".
This issue has been known for at least 11 and a half months. 5 months ago you proposed and I quote.
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.
So I get your point that a permanent solution would be the best answer here... but in the mean time it's been more then 11 months without even a temporay fix... perhaps instead of waiting who knows how much longer (I mean who does know? Plex hasn't even made it clear to it's paid members that they even cares about this issue. At this point I'm expecting something truely revolutionary out of Plex since it's taken 11+ months to fix) we should ask for a stop-gap measure.
So I get your point that a permanent solution would be the best answer here... but in the mean time it's been more then 11 months without even a temporay fix...
Don't get me wrong, I'm also disappointed that it has taken this long.
The problem is that since I originally made that post, and then set out to roll my own solution, I found shortcomings with a number of clients (every one fmstrat and I tested) and the way those clients communicate with PMS, making it clear the solution wasn't so simple. There are some core changes Plex needs to make in every single client to fully secure communications, and some of those changes are non-trivial. The new ROKU client is one big step towards that end, but more needs to happen.
Yes, Plex could mask some of these issues, say that some clients can't connect remotely, etc., but as I've previously pointed out in more detail, even this spit and gum approach isn't as simple as it appears, and would significantly detract from getting security/privacy properly resolved on all relevant clients, for all communication.
TL;DR: There is no easy temporary fix. Plex needs to hurry up and finish the permanent fix.
Don't really want to make you feel worse, but this has been known for at least 2.25 years not 11.5 months and we still have the same security issue(s).
Don't really want to make you feel worse, but this has been known for at least 2.25 years not 11.5 months and we still have the same security issue(s).
I'm not singling you out, Carlo...
Why has this been around for so long and not been fixed? New clients coming out and those are as buggy as the rest, so more code requires fixing to get it all implemented.
I think some of the subscribers are as much to blame for this as the Plex Team. The 800+ votes for PS3/4 support certainly had an impact on the time devs could have spent working on security. Xbox clients even more time. Cloud sync for all of the off-the-wall cloud services out there, even more time. None of the new clients even have half of the features yet, so we know there is going to be more dev time working on them to get the feature sets up to par.
The end result? We have security issues and getting those issues resolved is likely to require a rewrite of some of the existing clients or completely scrapping them and all new code.. We have a need for server side tools for user management, bandwidth, transcoder permissions, concurrent users, monitoring the server status and the list goes on.
But I bet we see a new Cloud Service first... :(
2 years to fix an identified security issue is unacceptable. The research was shown to the Team, and I'm sure the info was made available to them to help resolve this. It's past time to get this fixed.
Rant coming, so skip this post it if you don't want to get mad at (or with) me. :)
Why? I don't know, but I'd have to guess "Lack of attention because other things are more important?". I know they say they are working on it and it's important, but I don't see it. Even if they released a new eco-system tomorrow I still don't see the focus because it's taken way to long. 2+ years tells me enough of where Plex regards security. No amount of words or posts can change this fact that it's been 2+ years. Of course it's still not fixed and with the additions of new clients it's only going to get worse before it gets better (if ever). Almost 2 and a half years of public knowledge (I knew before that) is really bad. I'm a systems architect (hardware and software) with knowledge of everything from low level protocols to high level programming languages with everything in between. There are several things that could be done relatively easily to stop much of the security compromises.
Right now there are guys running scans on IP ranges looking for Plex servers. Once the Plex server is found, it's pretty easy to compromise and sell access to. These types of things could be fixed rather easily but have been going on for years. If your internet search skills are good and you know where to look you can figure out how they are doing it. But as most people I think already know, get the right token and you have the keys to the kingdom with only moderate (if that) work.
I understand Plex maybe trying to come up with the ultimate way of doing security and that is GOOD. But it's been 2.5 years that I know of and even the basic exploits are still there just as they were 2+ year ago. Surely, they could implement a few easy things to at least make the exploits much harder to do. Temp measures don't need to be 100% effective but enough to get the "intruders" to move on to easier pastures/targets while a real security implementation is done. But we haven't gotten this OR Plex has tried some stuff without telling us and it hasn't worked. End game is that 2.5 years later anyone's Plex server is compromisable still which is... well bad.
There are many different ways to fix this properly and it's surprising it's not done yet. What is even more surprising is the lack of any "stop gap" temp measures that could be implemented to stop much of this. This really isn't rocket science. Maybe Plex should pull down MB3 code and look at many of the things they have done to implement security. Better yet, wait another release then pull the code and you'll get even more security goodies from being able to auto-lock accounts for bad password attempts or multiple IPs in use from different regions to questionable logins (disperse IPs) to limiting streams per shared account, etc.
What I myself find really ironic is that this bug in Plex is actually older then MB3 itself which got security correct as well as everything else it has implemented. I don't know if that makes me want to laugh or cry!?!?
I'm sorry if you think I derailed topic but it saddens me, this is still ongoing.
Plex could pull down MB3 code and see how they implemented it which works well and doesn't have the security implementations that Plex has.
Again, not that simple. As just one example; I don't believe each MB3 client has the ability to act as its own mini-server, like many of the Plex clients do. Unfortunately, features like this were implemented before a solid plan for security was formed, making the hole they need to dig out of that much deeper. That, or they could eliminate such features, and then fend off an uprising of a different nature. Rock <-> hard-place.
