Web Player: No HTTPS support?

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.

Looks like Plex pays digicert for an SSL certificate for every one of their users: https://support.plex.tv/hc/en-us/articles/206225077-How-to-Use-Secure-Server-Connections

Unfortunately we don’t have the size or budget to do this. We could use self signed certs, but they are quite annoying to use and can be MITM just as easily.

Ideally we could use letsencrypt, but currently that only works if you run a service on port <1024, which requires root access.

1 Like

The TVOS and IOS client could setup a secure communication without setting up certificates, since the Channels site can verify the identity of both parties. it would just exclude the web brower clients

Thanks for your candid answer. At least this lets us know the challenges you guys are dealing with. It’s good that we know it’s not because of technical barrier.

It's quite interesting how Plex is doing this. Here's an article with some more technical detail:

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

2 Likes

This works on synology if a LetsEncrypt certificate is already set up:

1 Like

That’s sweet!

1 Like

on second thought, this is insecure because it breaks the remote access authentication. Maybe a separate authentication could be created, but I haven’t looked into this yet.

I have my Channels DVR set up on a real host name, protected with a Let’s Encrypt cert, via an nginx reverse proxy.

Yes, when you do this, your server will use HTTPS but will then also not have any authentication. You will need to protect it with your own means. I do this with simple basic auth.

While setting up the cert and a basic auth htpasswd file is outside the scope of my comment, you can find that information pretty easy online. But I thought I’d at least provide my nginx vhost config as an example:

# --- + PROXY + ---

# Template variables:
#
# * domain = channels.mydomain.com
# * name = channels
# * type = proxy
# * host = 192.168.1.198
# * port = 8089

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream channels-lb {
    server 192.168.1.198:8089;
}

server {
   listen 80;
   server_name channels.mydomain.com;
   return 301 https://channels.mydomain.com$request_uri;
}

server {
    server_name channels.mydomain.com;
    listen 443 ssl;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://channels-lb;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        auth_basic "Username and Password Required";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }

    ssl_certificate /etc/letsencrypt/live/channels.mydomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/channels.mydomain.com/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
    ssl on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    proxy_buffering off;

    access_log /var/log/nginx/channels-access.log;
    error_log  /var/log/nginx/channels-error.log;
}
2 Likes

@maddox Thanks for this, it works! I do notice though, that the guide view doesn’t show the recording clock icons on the programs when viewing in safari. It also doesn’t seem to see the what is recording from guide view. Chrome works though. I think something is breaking some part of the javascript.

Also, when trying to play live stream remotely on an iphone, the htpasswd auth asks for un/pw multiple times and the stream doesnt load.

This has been a fun experiment, but the non-ssl connection without using any proxy results in a more functional website.

1 Like

FYI, let’s encrypt will begin supporting wildcard certs in January:

You could probably use this to accomplish what Plex is doing, if you really wanted to.

1 Like

Wildcard certs don’t really help us, because using one would mean every customer shares the same cert. And if you get a copy of the shared private cert key just by downloading Channels DVR, then you can easily use that to MITM anyone else’s DVR.

Plex has an agreement with a CA which issues a separate cert for each of their users. We could do something similar with Let’s Encrypt, but they cap each account to a maximum of 20 new certificates a week.

1 Like

Seems there’s no easy way.

Plex’s specific technique uses a wildcard cert for each user (described in the article earlier in this thread). That said, I didn’t know about the 20/day limit - that would be a show stopper.