Web Player: No HTTPS support?

It looks like all images from fanc.tmsimg.com are loaded over HTTP. Aside from that, it works perfectly behind a reverse proxy for me.

This is the key to fixing the jsonpipe. I think you may need to move it into the location / block like in @LukeLambertā€™s example

well thanks for the cookie auth, that part works great. but the guide view does not show the scheduled recordings when viewing on an iPhone, or when using Safari on macos.

Hmm, I hadnā€™t noticed that. Disabling HTTP/2 seems to fix it. Iā€™ve updated my example conf.

2 Likes

thank you so much for pointing this out! my conf is slightly different than yours, I was just using your cookie auth, which is great. But I had no idea that http2 was incompatible with iPhone and Safari like this! I had to turn off http2 for everything using the same ip and port (which took a bit of searching). But I got it!
Finally, a fully working dvr over https, using my own cert!
@tmm1 : edit: was going to suggest an nginx conf as a feature, but just remembered how many different devices you have developed for that are now compatible with channels.

Thanks for tracking it down. I recall seeing the same behavior before.

What was the required line in the nginx conf? I didnā€™t see any changes in the example.

it was previously: listen [port] ssl http2;

the hidden issue is that if this is say, port 443, and there is anything other service set to use http2 over port 443 (this would be common for a reverse proxy), then it will be used by default for every other service listening on that port.

1 Like

Iā€™ve added experimental HTTPS support to the DVR starting in v2017.07.20.1616. Each DVR installation will automatically generate a unique self-signed certificate, and publish the fingerprint of that certificate as part of its bonjour service.

HTTP and HTTPS both share the same port, so to force SSL connections simply change the URL to https://

If you want, you can also swap out the generated cert for your own, by replacing cert.pem and key.pem in the channels-dvr/data/ directory.

4 Likes

Thatā€™s GREAT news!!! Hmmā€¦but can you implement a different port for HTTPS, say port 8090? Because when we do port forwarding, we cannot differentiate between https and HTTP. Iā€™d just want to allow https only. Could you please implement different port? Otherwise, itā€™s no use at all.

1 Like

If you only use https it shouldnā€™t matter that http is also available.

But other people from outside can choose to connect using http, right? Iā€™d like to block http from outside world completely.

Yes but all they would see is the login page. There is zero difference if you see the login page over http or https

I donā€™t see login page. Both http or https would bring me directly into Channel DVR web page.

I could be wrong, but I think your public IP address is also considered a local address to Channels DVR. i.e. You wonā€™t be prompted to authenticate from any request originating from your network, even if you access the admin using your public IP address.

Try accessing it from your phone with wifi turned off in a private browser window. I was concerned until I tried that.

1 Like

The login page is only shown when you try to access the DVR from the internet. Also once you login you wonā€™t see it again unless you clear cookies.

So yea check from cellular connection in a private browsing window and youā€™ll see itā€™s the same for http and https. All https does is encrypt the traffic, so when you do login no one sit in between you and your DVR and sniff your login details.

I was able to use a certificate generated from Letā€™s Encrypt project. Thanks.

Okay so Iā€™ve setup the DVR using https with a cert from letsencrypt. Iā€™d be happy to expose my box to the internet via my own domain (DDNS setup with router port forwarding just to the DVR linux box). Do any ports other than 8089 need to be forwarded to the box for the streaming in the web client?

Also detection of the DVR on the local network for the Channels client apps relies upon bonjour, right? Any chance we could use a server address instead/aswell on a client device? That way a client device could connect from the internet without having to resort to a VPN. I could take my aTV away with me and still access my recordings and live TV as long as the bandwidth is good enough. Obviously this doesnā€™t relate specifically to https per se but is just something else I thought about.

Iā€™ve been able to connect over https with my own certificates from Letā€™s Encrypt, and it seems to be working fine. The only thing Iā€™ve noticed is that when you start to play live TV or a recording, the padlock disappears in the web browserā€™s address bar. Is this expected behaviour?

Nope.

Remote streaming support in the tvOS and iOS apps is planned.

Looks like the video player loading image was being downloaded over http. Fixed for the next build.

1 Like