Web Player: No HTTPS support?

Channels DVR Server
#14

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.

#15

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.

#16

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

#17

HTTPS on port 8089? How? 8089 is not HTTPS, right? I thought it’s just plain http?

#18

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.

#19

That’s exactly what I thought! Thanks for clarification

#20

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.

#21

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.

#22

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
#23

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

#24

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.

#25

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
#26

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

#27

That’s sweet!

1 Like
#28

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.

#29

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
#30

@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.

#31

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
#32

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
#33

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