Hi,
Is there anyway to force Channel DVR to accept HTTPS incoming via different port? Say 8089 is HTTP, can I set a different port for incoming HTTPS connection? My 1st concern is security if I open (or port forwarding) a port from the outside world.
Thanks
HTTPS requires a certificate which we are not able to issue, because it depends on the hostname/ip. The best bet for secure access would be to setup a VPN in your home so no ports are open at all.
+1 to a VPN, but you can also use something like nginx as a proxy in front of the Channels DVR instance. This can then serve traffic through HTTPS with your certificate configured.
Slightly related, @tmm1 is it possible to have the web instance bind to localhost instead of the internal IP?
The server binds to all IPs, including localhost
Note that if you use nginx or other reverse proxy, you will need to implement your own authentication as the built-in auth will no longer work.
I just discovered that there is 1 nice feature that the Plex Live TV offers is that you can view live tv while you are outside of your home using my 4G cellular phone. The quality is acceptable, it’s viewable. I was little pleasantly surprised. That means I can finally watch live tv outside. And…it’s over HTTPS because I force Plex Media Server to accept secured HTTPS only. No VPN at all! That’s nice surprise. I wonder why Channel DVR or iOS TV app can’t offer that. The developer mentioned certificate issue. But I did not have any certificate issue with Plex.
I use Channels with HTTPS outside my house using cell data or random wifi a lot when I’m traveling, with it transcoding to whatever I set it to.
I use it all the time too, both recordings and live tv on my iPhone. Sometimes I will play live sports on my iPhone while at the bar.
As far as https, the server needs a certificate to identify the cryptographic key as coming from that server. Without it, the security benefit is lost.
Yes, Channels does allow that and by default creates the upnp rule. It uses oauth for authentication and allows you to watch with a web interface. We are all waiting and hoping that the iOS has this all setup and working as well when that version ships…soon?
Check out the web interface. You can adjust the transcoding to match your home’s uplink.
The only benefit to an encrypted TLS connection is only during the negotiation of the oauth, after that, it’s unnecessary. Why encrypt broadcast tv?
If someone takes the oauth key and copies your session, the most they can do is watch videos and delete them.
You can do a bit more than just delete and watch videos from the web-ui. But I wasn’t arguing that more security is needed, at least not for my purposes. I was stating the reason why the web-ui is not https.
On second thought, however, it would be possible without costing money. Channels-DVR could just use a self-signed certificate (not one issued from a certificate authority). The web-browser would give a warning when connecting (along the lines of “this site cannot be trusted”), but user could ignore the warning and tell the browser to trust the site anyway. And then you have TLS/SSL for your tv streams. ha 
I would never do that. It teaches people to accept invalid certification certs. We used to do that 10 years ago, but it’s unnecessary. I run the PKI environment for my company, just costs some hardened VMs and a USB stick. Things like “let’s encrypt” make valid certs free.
The problem with certs is that you have to have names, and making that work isn’t easy. Most people probably don’t run internal dns servers, nor do they run hairpin NAT on their external interface.
I still say there is no reason for TLS on this service. If the service were exploitable, it’s just as exploitable encrypted.
Let people snoop my football game I’m watching in my hotel room.
If i were passing credentials or credit card data, or my porn preferences, then it would need to be encrypted. That’s why they encrypt that.
Everyone is happy to pass data to hosted servers in big data centers, but they don’t consider the fact that alot of those services still only encrypt the edge, and once the data is internal to their network, it often goes plain text over a network or server shared by hundreds of different customers.
Sooner or later all your traffic will be MITM by your provider when they require you to trust one of their self-signed CA certs. It’s really coming.
It might make some people happy just to have the option. I am not talking only about security, but also about appeasing users. A self signed certificate doesn’t need a domain name. It could work with a subdomain using DDNS. Or even someone connecting with just an IP address. Many users would see the https and the lock icon on their browser and perceive it to be the same thing as if connecting to a website with a published certificate. Perception is reality. And it is better than no security at all. It is only the authentication and identity of the server that cannot be verified by a third party. But the connection for that https session is secure. And then the OAuth could still be used. Or, there could be a settings option for users who do own a domain name and SSL certificate.
@ImNotSerious But as far your point about letting people snoop your DVR, nobody wants to snoop your football game. If someone does think that it is worth it to try to access your http from your server, it is because they are trying to do one of these things: make money with ransomware (or some kind of bribery), record your viewing habits, steal private/proprietary information, gain further accesses to other hosts on the LAN. But, encrypted or not, I think the easiest way to get in would be to spoof the OAuth with some kind of phishing.
I am not really interested in any of this, but really just felt like pointing out that https would be possible if the devs thought it was worth it. Apparently, Plex is doing it. But we are way off topic now.
well, in a final effort to ensure no time is wasted on certificates for this solution for the forseeable future so that they can get back to iOS:
oh. my. Perception is not better than security. It’s fooling yourself. Its like setting your clock 10 minutes ahead to be on time. Just be on time.
how are they going to phish you into giving them a token? “Dear Mike, i’m a Nigerian prince with a million dollars. if you send me an OAUTH token for your DVR, I will make you rich”. nope, they are going to try and phish a corporate employee at Wal-Mart and steal a million user accounts and credit cards, or spear phish someone in accounting into a bank transfer.
Having a certificate on your sever doesn’t stop any of above behavior you mentioned. What it does do is makes the attack private! If a false sense of security is what your looking for, then try “Security through obscurity” and use Channels!
No hacker is trying to get into any ONE user’s NAS, they are trying to monetize the trouble they cause, by setting up an automated attack system with lots of users. If they want to hit personal users, they go after something with a large user-base and known vulnerabilities. like the My Cloud solution or Synology QuickConnect. (Both of which have had vulnerabilities and exploits created. Don’t use these directly on the Internet. EVER. use a VPN and keep your router patched). What are hackers going after? Millions of Windows and Andriod with a gazillion KNOWN and shared holes or 1000 DVRs with no know holes, and an insufficient user-base to bother. Lets take a look at WannaCry. they had 200,000 known infections against their 200,000,000 attempts, and only 200 people paid. Total bust compared to CryptoWall and their $325Million haul. The total channels community barely has 1000 users and some of them are arguing over $3/month. How many of them will be willing to pay $300-600 if someone encrypts their movies and TV?
PeaceOut
HTTPS on port 8089? How? 8089 is not HTTPS, right? I thought it’s just plain http?
The port doesn’t determine HTTPS or not, but that’s a different discussion. I use a reverse proxy, so I actually connect with 443, and then my server plays middleman to 8089 on my SHIELD.
That’s exactly what I thought! Thanks for clarification
Encrypting live TV is not the concern. Having your NAS or computer with http open to public is just dangerous. Nope, it’s not that simple. If Channel DVR has security bug, the hacker can poke into your system using the uncrypted 8089 port. I just don’t take security lightly. I cannot afford to have any non-secured connection open to the internet.
You don’t understand. Having the open port encrypted or not does NOT do anything to slowdown or hinder someone attaching a vulnerability, all it does is encrypt the attack. The reason for encrypting the traffic is to have privacy.
The OAUTH is for authentication. So the cert knows who the client is.
The certificate is meant to identify the server and works in trust. It needs to be signed by a trusted entity like digicert.
See, nothing to stop vulnerabilities from being exposed.
Vendors who talk about HTTPS but don’t actually write good code are just preying on non engineers lack of understanding.
Now, unless the negotiation is done on https over 8089, and then a second port is opened for data, you will be encrypting the mpeg stream. Since this is coming from the home’s uplink, which is about 1mbs for most households, it trashes the measly throughput to add encryption on top.