You are probably deeper into this then I am, but wouldn't that be solved by a standardised naming scheme? A solution might be to give every server a url under a Plex URL, so for example "machinename.username.plex.tv". Plex could then provide a signed certificate when the server connects for the first time on that URL (please note that it would replace the https://plex.tv/servers/machinenumber naming scheme that is currently used). Plex could pin that certificate when it connects to that server for the first time.
Jaap
If using CA signed certs, this would increase costs for the users and/or Plex, as each host name would require a cert for host.username.plex.tv. (It's not the name that costs -- it's the cert.)
If Plex is handing out CA signed certs, it needs to be for a domain they own -- and I don't know if there's any way to get the costs down to much lower than ~$1 to $2 per certificate, per year, and Plex will probablu hit a brick wall if they try to become an intermediate CA.
I believe Plex is going to try the self signed route, but this will require a distribution system to be built, allowing the clients to securely obtain the public keys. Then there's still the issue of finding a way for Plex Web to use self signed certs in a non intrusive way.
If Plex is handing out CA signed certs, it needs to be for a domain they own -- and I don't know if there's any way to get the costs down to much lower than ~$1 to $2 per certificate, per year, and Plex will probablu hit a brick wall if they try to become an intermediate CA.
Hence my proposal for the naming scheme :). But your point of becoming an intermediate CA and Plex not being qualified might be a valid one.
I believe Plex is going to try the self signed route, but this will require a distribution system to be built, allowing the clients to securely obtain the public keys.
That is the easy part: let Plex.tv handle the distribution of public keys. When a server signes in for the first time, it publishes the public certificate to Plex.tv (this can be done through HTTPS). When a client signs in on Plex.tv, it not only requests the URL's on Plex.tv, but also requests the associated certificate (this again could be done over HTTPS).
The problem is what to do with the certificate once you get it. I seriously doubt you can easily add certificates from inside an app into the OS truststore (this shouldn't be too easy/silent by design) of any OS. So adding the certificate into the truststore and simply starting starting a HTTPS-connection won't work. And I seriously doubt you can initiate a HTTPS-session with a specific certificate from any sandboxed app on any OS.
Then there's still the issue of finding a way for Plex Web to use self signed certs in a non intrusive way.
I once tried to import a self-signed cert on iOS. I still wake up crying from the experience.....
The problem is what to do with the certificate once you get it. I seriously doubt you can easily add certificates from inside an app into the OS truststore (this shouldn't be too easy/silent by design) of any OS.
The native apps (ios/roku/android/PHT/etc.) shouldn't have much difficulty using a custom set of certificates. (I believe many of them are already using their own set of root certificates rather than trusting what the OS provides. PMS certainly does.)
I once tried to import a self-signed cert on iOS. I still wake up crying from the experience.....
Yes. The issue is browsers. I have low confidence that self singed certs will lead to a satisfactory user experience in Plex Web. It'll probably feel like a step backwards.
Not a huge techno guy but I get along pretty well. Just doing some house keeping today on plex, re-arranging libraries, and moving the kids to separate accounts to limit what they have access to etc. Went to share my library with the new kids account and noticed an unknown account I was shared with that I did not setup. It had only been there 10 days but it was on both of my servers. I deleted it, changed passwords, and deleted clients from my clients list.
I am not entirely sure when or where my password would have been sniffed. To be honest I was using a very simple plex password so the kids could use it but it was long enough I still doubt someone would have guessed. Only my family have the account and none of us would typically use public wifi. I may on occasion but always through VPN. So not sure if it was just a guessed password or if in fact I got sniffed during some drunken outing being promiscuous with open wifi.
Point of post. A temporary solution that should be put in right away s an email to the account holder every time one of your servers have a new share added, or at least copied on the share request. A long term solution should be put into place ASAP however. Having read through this post it is unbelievable that plex would leave this glaring problem wide open! To the point that I will be telling people not to use plex until it is fixed.
Out of curiosity, how is your VPN configured? Which Plex clients (iOS/android, Plex Web, etc.) have you used remotely (on VPN or not) and on what types of networks (hotel, airport, restaurant, etc.)? What OS is your PMS server installed on?
Out of curiosity, how is your VPN configured? Which Plex clients (iOS/android, Plex Web, etc.) have you used remotely (on VPN or not) and on what types of networks (hotel, airport, restaurant, etc.)?
Kids are 6 and 8, on old iPods touches. Never been on public wifi (Just looked at the wifi list on them to be sure)
Wife is Nexus 4, Not really a plex user. Has a couple shows synced, but thats about it... Second thought on that she is on her own account anyways.
That leaves me.... Nexus 5. I use PIA's android client for VPN. I am going to guess I am the culprit. A couple trips to texas recently I was making use of hotel wifi (Canadian so US data on my phone costs an arm and leg). I try to insure the VPN client is up and running before I connect to wifi. A couple of times though rebooting the phone and the VPN client kicked out and the wifi connected.. usually fixed pretty quick but one of the hotels was for a Tech conference I was at... I am sure there might have been some packet sniffing going on.
Goes back to the thread at hand. This is a big damn security hole! FIX THIS and send me an email any time a share is added to my servers...
I have never felt so violated having been sniffed! ;-)
Just re-read the question and missed a few points...
2xPMS both on Win7 boxes. One is being retired shortly, just there until the new one is stable.
I do use plexweb but I don't think I have used it on public wifi of any sort. I use a nexus 5 and nexus 7 when traveling, both with PIA. But as noted above They were connected to hotel wifi for short periods were VPN was not running.. Don't think plex was run during this time, but who knows. It was a couple months ago. Only been using plex a few months.
I'm pretty sure PIA doesn't fully secure the connection from your remote device to your home PC -- You'd need to run a private VPN server on your home router/network for that to be the case. If PIA operates as I suspect, the connection from your device to PIA is secure, but from PIA to your PMS server would be in the open. Anyone listening between PIA and your PMS server could capture packets. (Though there probably isn't that many chances for someone to listen in between.)
The other, more probable, issue could be local traffic. I'm not sure what PIA's VPN client will do with requests for local traffic. Even when on a remote network, your Plex Client will try to ping the local address(es) of your PMS server. The PIA client likely lets these attempts out on the untrusted wifi network, rather than tunneling them over the VPN. If captured, these ping attempts will leak your token.
I doubt that a Plex client could accidentally leak a token via a local request if the client is not in that actual network. The TCP/IP stack wouldn’t even know which network interface to use to attempt the connection, and without an ACK from the PMS host, there wouldn’t be any further data transmission.
I doubt that a Plex client could accidentally leak a token via a local request if the client is not in that actual network. The TCP/IP stack wouldn't even know which network interface to use to attempt the connection, and without an ACK from the PMS host, there wouldn't be any further data transmission.
Yes. I oversimplified a bit, but setting up a "honeypot" for on port 32400 (again, an oversimplification, but I don't want to write a how-to for how to exploit Plex) isn't that difficult, and is what I suspect is going on.
Even then, the IP address of your PMS would have to be within the local network’s address range, otherwise the TCP/IP stack will ask the gateway to route the packet.
Even then, the IP address of your PMS would have to be within the local network's address range, otherwise the TCP/IP stack will ask the gateway to route the packet.
Not a problem if you manage the router/gateway on the untrusted network.
So I guess if you connect to a network that is completely compromised, then you would have a problem. But PMS token leakage would not be your biggest concern at that point.
So I guess if you connect to a network that is completely compromised, then you would have a problem.
This is not an uncommon occurrence when traveling. You should never trust public networks. HTTPS on these networks will still work to secure your traffic.
Not even traveling, for that matter. One can hijack any WiFi network, even WPA2 with a complex key, simply by spoofing the SSID and creating a MITM. So yeah, ■■■■ happens.
Not even traveling, for that matter. One can hijack *any* WiFi network, even WPA2 with a complex key, simply by spoofing the SSID and creating a MITM. So yeah, ■■■■ happens.
Exactly. Just one of the reasons security should be THE top priority for Plex.
Not even traveling, for that matter. One can hijack *any* WiFi network, even WPA2 with a complex key, simply by spoofing the SSID and creating a MITM. So yeah, ■■■■ happens.
True, PSK-based networks are prone to this because they lack mutual authentication. The most practical attack is the "Jasager" approach (see http://www.youtube.com/watch?v=yr5upPHqhlA, which features a $100 device that automatically does the MITM-attack for you) which abuses any trusted SSID. People in hotels and airports are pretty easy targets....
Just to clarify, because I don't think many Plex users get this point: This isn't about "added" security. This is about ANY security. Currently, by modern standards, Plex basically has zero security. Running a Plex client remotely is synonymous to shouting your password(s) from the rooftop. The client will leak the tokens (look at a "token" as your username and password wrapped in to one) for all servers that publish its IP address to your myplex account. Once a token for any client has been leaked, you're screwed. Whoever has captured it now has almost full access to your myplex account and any remotely accessible servers associated with it.
Is there an easy way to see whether there is activity coming from the internet attempting to access a Plex Server?
Not built in to Plex, no. If you want to secure your Plex server, it should not be connected to the internet.
