Server Version#: plexmediaserver_1.25.1.5286-34f965be8_amd64.deb
Player Version#: Web 4.70
The latest web client fails when trying to login, appearing to successfully accept credentials but then re-presenting the login dialog. A second attempt, just clicking on “use username/email” button results in a basic “An error occurred while logging in” response. However, if I then open Tautulli I can authenticate using the already-established token. Or if I go to app.plex.tv, I breeze right in. The problem is solely with “https://myservername.mysuperlongsecretidentifier.plex.direct” which resolvs internall to a local IP on my network as well as for VPN traffic. This was for only web client 4.70. I happend to still have a session open on another system with web client 4.66 cached and it did not have this issue.
External connections were unaffected.
I rolled the server back to plexmediaserver_1.25.0.5282-2edd3c44d_amd64.deb, and tried again with the cached Web 4.70 client and failed. I then cleared my browser cache, and reconnected. This time I received Web Client 4.66 and everyting works again as expected.
The FQDN is "https://myservername.mysuperlongsecretidentifier.plex.direct” there is no other valid one. The SSL certifciate, as issued, has “*.mysuperlongsecretidentifier.plex.direct” as the CommonName and the only SubjAltName. It does not list an IP entry. What address are you suggesting I use?
This is absolutely a bug with Web Client 4.70. There is no reason why I shoudn’t be able to browse directly to my own server.
Nothing has changed on my network. I have used this configuration for several years.
Requests "myservername.mysuperlongsecretidentifier.plex.direct” on my internal network resolve to that system’s private/RFC1918 address
Authentication still actually works. My browser receives its token and I can then connect to related services such as Tautulli in another browser window without re-authenticating. The only problem is PLEX Web Client v4.70 craps out with the aforementioned error…
you don’t have your own domain name (as you stated)
you aren’t supposed to use Plex’s names (they are internal use only from https client to https server)
On your LAN, you bookmark the IP address of the server and that’s that.
Plex/web 4.70 knows the above rule #2 so that’s what it uses.
It converts the LAN IP address you give it on the invocation URL, converts it to the Plex internal name, and establishes https between PMS and the browser.
You have always been able to, and should, use the LAN IP unless you have your own FQDN added to Plex.
4.66 → 4.70 isn’t a bug. As I read it, it’s a further refinement to protect https for those who rely on it for remote connections. It opens the connection as https. You can’t do that in 4.70 without having Plex’s certificate added to your browser (which can’t be done manually)
How does this work without breaking the security model? My IP is not part of the Subject Alternative Name of the certificate, so if a user browses to say https://192.168.1.2:32400, the first thing that is happens is they will receive a certificate warning, not a secure connection, which opens a host of exploit possibilities and is unacceptable.
PLEX does not auto-regenerate my certificate and include an IP Address entry in the Subject Alternative Name, which would work but then that advertises private internal network data to the Internet which provides valuable info for anyone intent on browser exploits. Adding my FQDN does nothing, as PLEX/Let’s Encrypt Root is neither authoritative for my domain nor does it include my FQDN as part of the SubjAltName; the certificates generated are for plex.direct only. Browsing to https://myserver.mydomain also breaks SSL and is also unacceptable.
On the other hand, the previous setup allowed for leveraging the wildcard SSL certificate. Browsing to any system designated by DNS as “WHATEVER.mysuperlongsecretidentifier.plex.direct” will result in a transparent SSL connection. In order to have a secure setup, all that was required was:
Add an internal DNS override for “myservername.mysuperlongsecretidentifier.plex.direct” to your router/DNS server to point to the internal IP.
JOB DONE.
Now, instead of having a simple DNS redirect, users will have to manage their own certificates PLUS DNS entry (with full domain), PLUS add the URL to the custom server dialog. Certificate management is a PITA at best and beyond the reach of many users. The entire point of the partnership with the EFF/Let’s Encrypt was to fix this, no? Going back on this means adding more complexity which means more vulnerability.
“Not supposed to use” is arbitrary and, in this aspect, capricious. What problem does this change fix, as opposed to just breaking a currently functional security model?
so if a user browses to say https://192.168.1.2:32400, the first thing that is happens is they will receive a certificate warning, not a secure connection, which opens a host of exploit possibilities and is unacceptable.
If you have someone that untrustworthy on your LAN, don’t you have bigger problems to solve ?
192.168.x.x is nonroute-able RFC-1918 space. If someone is on your LAN, what security hole do you have which allowed them to get there?
Really? Your answer to creating a security vulnerability is that if there is trouble “we’ll just make it worse for you”?
That is pretty poor. That is security theater.
“What kind of exploits are exposed?”
Let’s say I get on your netwok by way of half-a-hundred exploits against consumer grade routers, or a browser exploit on one of your <parents | kids> or malware or whatever, maybe an Internet-of-Things botnet exploit such as via your TV you cannot patch, or a compromised laptop, or a friend who brings computer over with any of the above…and more. Then what? If you only have properly encrypted services on your network, the next jump becomes orders of magnitude harder. That is the point. That is why we want properly encrypted communications. But no, now you’ve created a key weak point.
For example, how about a simple ARP redirection for Man-in-the-Middle inject of HTTP traffic anyone? Oh, you already accepted the insecure cert so your safe? No. Do the same MitM attack and spoof your non-valid SSL cert with a clone-copy of my own with any one of a dozen automated tools. You get the same old warning, this time that it expired (becuase that is what they do every year) which means the new cert will need re-accepting. Do YOU know how to verify a certiicate manually? Maybe. Based on your response here I have extreme doubts. Do YOU know how to verify against a spoofed certificate while I am on YOUR network and injecting my fake cert? I bet not. Good luck. 99.99967% of your user base certainly doesn’t. So now you re-accept my fake cert. Poof. I’m in your browser and now YOU are compromised.
This is one of a couple dozen methods I use on a daily basis. I could go on, but there is no point. Your position is indefensible.
You have taken what was a perfectly functional security model and broken it and are defending that position by saying if your network gets attacked you have BIGGER PROBLEMS and this additional attack vector that we’ve opened doesn’t really matter.
You opened your response by saying that the change from “4.66 → 4.70 is a further refinement to preotect https”…what is this refinement, if you please? The ONLY change I can see is that it introduces an attack vector. What attack vector was eliminated?
Additionally, instead of just thinking of your lowest-common-denominator use-case network environment, how about someone who uses PLEX as a media server where users are not all trusted? Hmmm? Then what? This model exposes everyone to anyone who is on the network.
A better solution would be making it easier for users to copy this URL for distrubution to users. A button that says: “Here is the direct URL to this server”
You guys made a big step in the right direction by enabling the relationship with Let’s Encrypt and adding SSL. Direct browsing using the server URL and leveraging this SSL cert has worked since 2015. Web Client 4.70 now breaks this and forces users back to having to generate their own SSL certificates for many advanced use-cases.
Untrustworthy devices are VLAN’d from the main server. I can give you my Guest WiFi password and you will get NOWHERE with it except out to the internet which is where I want you to get.
Yes, I absolutely know how to verify certs manually.
If you can get into my network, Go for it.
I will admit, there are things I don’t know but I will also admit that a portion of what you’re writing sounds like “crying wolf” to me which may well be my ignorance showing,
I will go get someone to come review here and read what you’ve written.
If our security folks agree it’s an issue then they will address it.
Sorry. Your flip response got my security-hackles up. As a “security guy” whenever anyone says (literally): if ‘bad thing’ then “you have bigger worries” so ‘other bad thing’ doesn’t matter…it really gets to me.
When I said “YOU” I really should have put it in the third person. As a guy who works where you do and does what you do, I’m guessing your layout at home is probably a few steps above the average bear (not that I don’t think I could still make a go of it, mind you)…but I was more trying to get you (actual you) to think about your everyman user. Or even your edge-case user but those who just have non-traditional setups (school, shared living space with roomates, whatever) where this could be a real and demonstrable problem. I don’t know what your living situation is like, but many of us have to deal with family and friends who are less-than-savvy and yet have to have some level of access to “privileged” networks. The number of households in this world that are running full-scope host-intrusion is pretty much zero.
What I actually have implemented to protect against this deep and complex problem is beyond the scope of this conversation.
I don’t have the bandwidth to reverse engineer Web Client 4.66 and 4.70 and do compare/contrast on my own…but I honestly do not see what possible vulerabilty this change has fixed. I’m sure direct browsing to the server isn’t something a ton of people are doing, but we should be encouraging proper security, not chipping away at it.
Please elevate this to whoever handles this aspect of the client. If they can explain to me what the attack vector is that this change protects against, I’ll just be quiet and go back to the roll-my-own SSL for my internal connections. Otherwise I will continue to push to have the prior configuration in 4.66 restored so I can continue to enjoy dealing with managing one-less certificate.
Also: I would instead push to see advanced users encouraged to use https://theirsrever.guid.plex.direct:32400 with a DNS redirect. It is a much simpler way to avoid rebind issues, etc.
I am and use that for the URL mentioned above. The problem being that the SSL cert only covers *.supersecretplexid.plex.direct, so any custom URL that isn’t covered by the wildcard will not validate for SSL.
As I mentioned above, the only change that could improve this and “split the difference” would be for the cert-generation function to pull any IP-based URLs and push them to Let’s Encrypt to include as part of Subject Alternative Names. (e.g. IP 192.168.1.2)
Any other custom URLs will also require custom/manual SSL certs…
The problem is documented correctly in the OP. When I upgraded my server to 1.25.1.5286 (Debian Linux) the Web Client that is pushed is 4.70, which produces the described bug. Web Client 4.66 is last pushed from server 1.25.1.5282 on Debian, which works as expected. I can use either my reverse IP or hostname derived URL to browse directly to the server via HTTPS no problem.
I am using the hostname-based url. https://myhostname.GUID.plex.direct:32400 and have myhostname.GUID.plex.direct overridden in my internal DNS to point to my internal IP.
This way external users see the external address (which uses a non-standard, forwarded port and NAT to internal IP) and internal users go direct to the internal IP/port
On “laptop B” (old laptop) I clicked on the link as I always do “https://myserver.guid.plex.direct:32400” and the page loaded as normal. I did some compare and contrast between the two systems and saw “Web Client 4.70” on “laptop A” and “Web Client 4.66” on “laptop b”, as shown in the settings in the user inteface
I then rolled back the server to 1.25.1.5282, cleared the cache on “laptop A” and was able to browse successfully to “https://myserver.guid.plex.direct:32400”, now running Web Client 4.66
At this point I will just leave it at 1.25.1.5282 until someday when:
A) I get confirmation that my expected behavior has been restored
or
B) I have the bandwidth to roll a new custom certificate for this system
For my purposes, this is just TV/Media and 1.25.1.5282 works just great…so until things stop working as desired, I have no need (nor time) to pursue it any futher.
It may very well be that 4.66.1 is the actual culprit and maybe I got 4.70 when I popped over to https://app.plex.tv and that got cached(?) from there…but either way the end result is the same: Web Clients greater than 4.66.0 break my use case…
I’ll revisit next year after the holidays or if I find time in between…
I think he’s referring to the background connection from Plex Web to the server. Not the URL used to load Plex Web.
i.e. https://app.plex.tv on Plex Web 4.70 cannot connect to https://hostname.serverIdentifier.plex.direct.
He’s using a “Custom access URL” set to https://hostname.serverIdentifier.plex.direct which will resolve to hostname instead of https://ip-address.serverIdentifier.plex.direct which will resolve to ip-address.
If it’s not this, then I have no idea because it’s not possible to load Plex Web 4.70 from the local server since it’s currently only available on https://app.plex.tv.
I didn’t catch that he was setting a Custom server access URL, thanks.
I’m curious if that’s the issue. Obviously a made-up internal hostname won’t resolve externally, but it wouldn’t resolve in the old version either.
I can imagine newer versions of PMS/Plex Web doing additional validation of the presented hostname, but 1) I have no evidence of that and 2) I’m stuck being confused about the version #'s.
(I’m also unclear why setting that as a Custom server access URL was necessary.)
@obumbratum_1, I’m certainly curious, if you want to keep looking. I’m also curious if any other components are involved (VPN, reverse proxies, external DNS).
