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.
Yes, but io5/6 doesn't seem to have built in support for startssl certs. It would have to be added similar to a self signed cert. Complicates the temporary workaround fmstrat and i are working on.
IOS 5 and 6 together account for 13% of the iOS installed base today. Given that iOS 8 is due in a few months and iOS 5 will reach end-of-support, this is not a concern.
Sent from my iPad using Tapatalk
Probably not a huge concern... but I ran into a few more than %13 in my testing of our work-around over the weekend.
Not a concern at all for self signed certs on iOS, provided the client app can import them.
I’m glad to hear you’re working on a work-around and would love to hear more about your progress.
Sent from my iPad using Tapatalk
It's a temporary hack fmstrat and I are testing to secure remote Plex communications until the Plex team is able to implement a native solution. Hopefully it'll work well enough to release, but it's relatively complicated to implement.
You can see more information starting here:
+1 for improving the security situation.
Security IS important!
+1 for Improved Security
+1 for security
+1 for this, self signed would be good
with the amount of money plea is now asking people to pay, I'm expect them to fix this asap.
http://www.reddit.com/r/PleX/comments/2ih85r/an_update_on_the_security_of_plex/
Updated list I saw on /r/PleX today
Edit: Launching on a Xbox means there will be more eyes paying attention to plex. Can't wait for the greifers to start hijacking accounts.
+1 fix the issues. What ever the solution.
My suggestion as a stop gap. Allow servers to turn on SSL if desired. Allow servers to use a auto generated self signed or admins provide a valid cert. Allow servers to be identified by a domain name so the plexweb can be made aware.
If someone really cares about all the security, then they will have a domain, point it to their home server, have a valid cert for the domain. The plex web just needs to be told the domain name for web viewing.
If someone sorta cares then they can just turn on SSL, and live with a self-signed cert and all the security warnings.
Yes and No: an XBox is a typical client. And in general the security issues are with the server which is exposed to the internet through Plex. Having said that, it does raise awareness of the existence of Plex in the wrong circles, and there is money to be gained by hacking into the typical server that houses Plex: machines designed/bought to allow Plex to Transcode video, also are great machines for Bitcoin mining...Launching on a Xbox means there will be more eyes paying attention to plex. Can't wait for the greifers to start hijacking accounts.
+1 fix the issues. What ever the solution. My suggestion as a stop gap. Allow servers to turn on SSL if desired. Allow servers to use a auto generated self signed or admins provide a valid cert. Allow servers to be identified by a domain name so the plexweb can be made aware. If someone really cares about all the security, then they will have a domain, point it to their home server, have a valid cert for the domain. The plex web just needs to be told the domain name for web viewing. If someone sorta cares then they can just turn on SSL, and live with a self-signed cert and all the security warnings.
Unfortunately, its not that simple.
fmstart and I are currently developing a possible work-around that uses a valid CA singed cert, domain name and a reverse proxy to secure remote connections to a PMS server. However, some clients are unable to work correctly with https. The iOS clients use http even when https is requested and the Roku client doesn't show thumbnails on some screens. (Actually not the fault of the Roku Plex client, but the fault of one of Roku's libraries ("roGridScreen") not correctly working with https urls.)
In addition, Plex clients are relatively aggressive about caching server addresses. If you have a local client accessing your local, insecure, PMS server, then you move that client to a non-local network, the client will still try to poll your PMS server using its local addresses, leaking the token to anyone that sets up a honeypot.
Another complication is that many clients (iOS, Android, windows 8, etc.) can act as PMS servers, opening another attack vector.
For our work-around to ever work, the Roku and iOS clients need to be fixed, you must never access your PMS server via the web client on plex.tv (until an issue with Plex Web is fully fixed (only a partial fix is currently implemented)), all clients must disable mobile media server abilities, GDM must be turned off on the local server, all mobile clients must think they are always accessing the PMS server remotely (never receiving the local address of the PMS server), and any PMS servers that are shared with you must also be secured, else your token could be leaked by accessing one of those servers.
Note that Plex is working on a native solution, and our work-around wouldn't work at all without leveraging the foundation Plex is currently laying for their native security solution. However, I have no idea how far off full implementation of their solution is.
Note that Plex is working on a native solution, and our work-around wouldn't work at all without leveraging the foundation Plex is currently laying for their native security solution. However, I have no idea how far off full implementation of their solution is.
Wouldn't it be easier for Plex to adopt your solution instead of devising their own (I know, the Not Invented Here syndrome)??
Jaap
Wouldn't it be easier for Plex to adopt your solution instead of devising their own?
The problem with our solution is that it requires a separate domain name and CA signed cert for each PMS, complicating use of it for securing local traffic (each client running a mobile media server would be like another PMS), and increases costs for Plex and.or Plex users. The problem with local traffic being insecure is the honeypot issue I mentioned before. (That could be solved other ways, but Plex did not seem interested in going down that path, yet. My current solution is to simply not use clients as "mobile media" servers, and to have all (well, most) clients act as remote clients, by never letting them see the local server IP. No easy way to fix the local traffic issue without modification to every client. )
That said; yes, I think they should so something similar for a least a short term solution that doesn't require the complication and limitations of configuring a reverse proxy. Most everything is already in place for it (save the iOS/Roku/Plex Web/Local traffic issues).
Unfortunately, its not that simple.
Thanks for the detailed explanation of the issues that you've encountered. It looks like there is going to be some work to do both on the Plex App side, and on the platform side, before a robust solution can become available. I do hope, though, that Plex developers choose to embrace the features of the later versions of iOS and Android rather than be tied down by limitations of older ones.
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.The problem with our solution is that it requires a separate domain name and CA signed cert for each PMS, complicating use of it for securing local traffic (each client running a mobile media server would be like another PMS), and increases costs for Plex and.or Plex users.
this should be the most important and highest priority feature the plex team should be working on
