Request support for enhanced SSL controls

Now that SSL is supported by Plex in a great new way, this request is to support power users who wish to integrate Plex more directly into their network infrastructure. The request includes one or more of the following:

  • Custom cert support in one of two forms. This would enable users to specify a custom certificate when going direct to the server. Understandably this can be done with a proxy, but the request is for built-in Plex functionality
    • Ability to browse for and specify unique certificates to use based on the hostname requested on the URL
    • Ability to specify an individual cert and hostname that plex.tv will leverage instead of the default IP.SERVERID.plex.direct
  • Ability to utilize separate ports for HTTP and HTTPS
    • This allows for firewall blocking of non-SSL connections to ensure tokens can never be transmitted insecurely. This may be handled using the single-port structure of Plex currently, but confirmation is required since the code is closed-source
  • Manual connection support for SSL
    • Allow clients to enter in a hostname and connection information for SSL connections independent of plex.tv

If there are any other more detailed SSL requests, please post them here and I will add them to the list.

 

References:

Proof of Concept: Token Exploit - Please fix this massive security hole [solved] - https://forums.plex.tv/topic/101886-proof-of-concept-token-exploit-please-fix-this-massive-security-hole/page-29#entry947778

Ability to utilize user supplied SSL cert - https://forums.plex.tv/topic/165720-ability-to-utilize-user-supplied-ssl-cert/

Thanks for starting this thread fmstrat!

If would be simplest if the user could just import their own cert using the Plex web interface. It doesn't have to overwrite the existing one, but you would essentially be designating which cert is used. The upload option would place the cert in the default directory that the Plex Devs deem appropriate (likely it would be '\Volume\Plex\Library\Application Support\Plex Media Server\Cache' which is where the existing cert is).

If you wanted to point Plex to a location manually that you already have a certificate stored, then you should be able to do this as well. If your Plex server can't find the cert you designated then it could fall back to using the DigiCert Certificate provided by Plex Inc. This could be hidden as an advanced feature like most of the settings that normal users do not need to mess with. 

Your reading my mind fmstrat!

The first two items are crystal clear. The third item is a bit fuzzy.
Can you elaborate what you meant by this one?


What I had in mind was the following config items:
Non SSL port: default 80
SSL port: default 443
Although technically we could continue to use 32400 type thing.

Domain Name: empty by default but if user had there own domain or ddns they could put it here
Cert Info: Boxes to input the cert info or a select button to pick the cert from your system to upload.

This info would get “uploaded/updated” to Plex.tv anytime you connect your server to it.

Then whenever plex.tv is used by a user it would use your domain name and your cert info instead of what is currently being done.

None of this should be very hard.

Carlo

Thanks for starting this thread fmstrat!

If would be simplest if the user could just import their own cert using the Plex web interface. It doesn't have to overwrite the existing one, but you would essentially be designating which cert is used. The upload option would place the cert in the default directory that the Plex Devs deem appropriate (likely it would be '\Volume\Plex\Library\Application Support\Plex Media Server\Cache' which is where the existing cert is).

If you wanted to point Plex to a location manually that you already have a certificate stored, then you should be able to do this as well. If your Plex server can't find the cert you designated then it could fall back to using the DigiCert Certificate provided by Plex Inc. This could be hidden as an advanced feature like most of the settings that normal users do not need to mess with. 

I think we're basically saying the same thing. The "browse for cert" just means upload to the web interface. The Plex dev teams will know how best to implement in their standard dev structures. Thanks for the comment!

Your reading my mind fmstrat!

The first two items are crystal clear. The third item is a bit fuzzy.
Can you elaborate what you meant by this one?


What I had in mind was the following config items:
Non SSL port: default 80
SSL port: default 443
Although technically we could continue to use 32400 type thing.

Domain Name: empty by default but if user had there own domain or ddns they could put it here
Cert Info: Boxes to input the cert info or a select button to pick the cert from your system to upload.

This info would get "uploaded/updated" to Plex.tv anytime you connect your server to it.

Then whenever plex.tv is used by a user it would use your domain name and your cert info instead of what is currently being done.

None of this should be very hard.

Carlo

I had decided to keep ports and certificates separate because one may be easier than another to implement, and not knowing how Plex is structured on the backend, one may be impossible. What your describing is the essential ideal, and outside of port selection, is what was meant by: "Ability to specify an individual cert and hostname that plex.tv will leverage instead of the default IP.SERVERID.plex.direct"

If you have a suggestion for how to reword that, I can, but I was trying to be succinct for the request and allow the Plex team to, if they choose to focus on it, implement it how they choose.

I have a strong feeling all of these are going to be very low on the totem poll for them, though, since they've still got to focus on securing the rest of the clients and we are definitely in the minority on these.

Thanks.

We are in agreement. While I personally would like to have different ports I’m also OK with just keeping 32400 (SSL and non-SSL). I’ve got the feeling this is probably hard coded in many spots and will be much harder to “fix” then some of the other stuff talked about here.

Agreed, the clients should definitely come first. But our talks here give them something to think about. :slight_smile:

Carlo

We are in agreement. While I personally would like to have different ports I'm also OK with just keeping 32400 (SSL and non-SSL). I've got the feeling this is probably hard coded in many spots and will be much harder to "fix" then some of the other stuff talked about here.

Agreed, the clients should definitely come first. But our talks here give them something to think about. :)

Carlo

Yup. In fact, the multiple port request can be removed entirely from this post if they're able to fix this one: https://forums.plex.tv/topic/101886-proof-of-concept-token-exploit-please-fix-this-massive-security-hole/page-30#entry948047

Thanks.

Yea, I was just reading that.

This weekend when I’ve got some free time to play, I’m going to try a bunch of similar type tests to see how/when non-ssl makes it though.

Carlo

I most care about the proper blocking and safe handling of non-HTTPS communications when encryption is set to required.

In the Devices “tab” I’d like to see more detailed information for each entry with regards to security.

  • who/what is communicating 100% securely and who/what is not.
  • which user(s) are associated with which devices
  • public ip addresses and coarse geolocation data

Thanks to the super-power users and the Plex team for making encryption/certificates happen. Sorry if this is in the wrong place.

Thanks for the post. I’d also like to have the ability to provide my own SSL cert since even without hacks you can’t make plex take a custom one which makes external communication with my server impossible…
Plex team: please allow us to provide our own certificates (personally I don’t need a fancy interface for that, just name a location to put a .pfx file and we’re done – maybe put a file with the pwd in it next to and as the most basic solution).

Many thanks in advance!