Put your ip in the IP variable or use localhost if running locally
$ IP=127.0.0.1 openssl s_client -noservername -connect $IP:8089 </dev/null 2>/dev/null|openssl x509 -text -nocert | grep Subject:
The output will be:
Subject: CN = hexnumber.u.channelsdvr.net
Might be helpful for some ...
What’s the point of this. Everyone knows their subdomain. You get redirected to it from https://my.channelsdvr.net
It is amazing how much info is being revealed without authentication. My favorite is the one that spits this:
{"arch":"arm64","booted":true,"description":"the daemon powering Channels DVR","features":{"bonjour":true,"bytelimitedhls":true,"comskip":true,"cpu":true,"dev":false,"dvr":true,"events":true,"guide":true,"m3u":true,"nat":false,"on_later":false,"playon":false,"remote":true,"roku":false,"tmsimgproxy":true,"transcode":true,"tve":true,"virtual":false},"name":"channels-dvr","os":"linux","prerelease":true,"start_time":"2021-12-01T15:56:41.589389504-08:00","subscription":"active","url":"https://getchannels.com/dvr","username":"sdust","version":"2021.12.01.2223"}
I put my server behind a reverse proxy so you need to know the domain name first to start poking. Will also ask for the port change...
I am starting to think providing a single port with both http and https wasn't such a great idea ...
There is some confusion when logging remote addresses vs. checking the remote IP. While the logs contain the header instead of the real ip, the real ip is used to decide if access should be granted. So this is great, but it would be nice if the method was unified as now I find reverse proxy doesn't work that well with the dvr ;(
Is there some explanation how dvr decides if the client is local and doesn't need to authenticate?
This can not be done via the forwarded port, while the method described in the original post can.
The dvr could trust the header it puts in the logs as the client IP. Right now anybody is trusted which results in entries like this in the logs
2021/12/02 04:56:05.378934 [HTTP] | 200 | 6.391624ms | 0.0.0.0 | GET "/settings"
See:
Close, but not quite. From the troubleshooting page
Remote Access
Could not connect to xxxxxxx.u.channelsdvr.net. Check if the port is mapped.
the check expects 302 to /oauth/start/auto
and now it gets 200 and a page
Get Authorization Code
If you use a reverse proxy then the built-in remote access features won't work. You're on your own if you want to do all this kind of stuff.
I understand. It would be nice to know if no additional security problems are introduced in the process. I can also accept a bounty for the discovery of the problem with X-Real-Ip 
Looks like I got it:
Remote Access
Successfully established external connection
Now the only problem in the web gui the activity shows streaming from 127.0.0.1 ...
Current status
So it turns out not using a proxy in front of the dvr gets you on a list at shodan
Would the Fancy Bits team look into this problem and consider playing nicer with proxies?
The DVR doesn't allow configuring it so it would trusts the x-real-ip header and everything under clients and activities appears to be coming from the proxy.
There is also some convoluted logic when certain end points are accessed. The X-DVR-ForceAuth header can only do so much.
Also speaking http on the same port as https is not clever and it should be turned off when remote access is allowed, maybe with the exception of the local net.
This is incorrect and exactly backwards. The situation causing issues is that going around the supported scenario of using port forwarding from your router and putting a TCP or HTTP proxy in front of the Channels DVR without taking additional steps to secure it will cause the DVR to be publicly accessible without authentication.
The Channels DVR allows for unauthenticated access from RFC1918 IPs (IPs that cannot be routed on the internet). If you put an HTTP proxy in front of Channels, the proxy is terminating the connections and creating new connections to the DVR. This causes all of the requests to be coming from RFC1918 IP addresses (and thus not requiring authentication).
We do what we can to prevent peoples DVRs from ending up insecurely in the internet by looking for the X-Forwarded-For HTTP header and marking those requests as remote, as well as providing the X-DVR-ForceAuth header to force authentication.
Please do not put a TCP or HTTP proxy in front of the Channels DVR unless you really understand what you're doing. Chances are you're going to run into confusing situations, cause security issues for yourself, and are generally going to have a bad time.
Providing instructions for setting up a proxy would go a long way. Were there any issues fixed recently?
Which of the headers are important?
Looking under Activities and in the logs they all come from the IP address of the proxy.
It should be sufficient to just set X-Forwarded-For to the right value and the DVR should trust the header if the tcp connection came from RFC 1918 or 127.0.0.0/8