Web Player: No HTTPS support?

[stoli412]

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.

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?

[tmm1]

Do any ports other than 8089 need to be forwarded to the box for the streaming in the web client?

Nope.

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.

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

[tmm1]

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.

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

[shepherdr]

Thanks. I did spot reference to this in another thread after posting where you said you wanted it to “just work” and no-one should have to enter IP addresses etc. I assume the DVR will register with a Channels server or some such which will note its IP address and a tvOS/iOS client which is signed in to the same account will get connected to it - much like Plex.

[rog889]

Ahh…now this explains it, no wonder I could access the DVR page, but none of the video playing was working. Can’t wait for the next build https for videos.

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

[tmm1]

It seems that safari cannot play videos if you use a self-signed certificate: Remote https on iOS safari

[syplex]

Thanks for adding this! I’d like to use this as well but would like to block out http, so it would need to be on a different port.
One good reason for a different port is identifying issues or bugs where http is used unintentionally and login details are inadvertently sent over http vs https (like the loading image issue above). Using a different port and blocking it on my router would help immediately identify these issues and give me a better sense of security.

[rog889]

Totally agree!!! Please consider use different port for https, perhaps use a 5 digit port, it would less likely to conflict with other commonly used ports or popular apps.

Thanks for adding this! I’d like to use this as well but would like to block out http, so it would need to be on a different port. One good reason for a different port is identifying issues or bugs where http is used unintentionally and login details are inadvertently sent over http vs https (like the loading image issue above). Using a different port and blocking it on my router would help immediately identify these issues and give me a better sense of security.

[djcastaldo]

The port number is just a number and is not representative of the protocol being used. If it were a different port for SSL, that port could just as easily take http requests without SSL.

[LukeLambert]

The web server could easily be configured to block or redirect plain HTTP requests. I’d eventually love to see a checkbox to require encryption. The cookie could then be set with the secure flag so there’s no chance of my auth token leaking over HTTP. Also, HSTS headers would be nice, but I’m not sure how they work with non-standard ports.

[tmm1]

Given that it’s not possible to stream video to iOS using a self-signed certificate, the current experimental support is considered DOA and I plan to remove it.

I’m looking into some alternatives. If we can find a way to make SSL work out-of-the-box for everyone, then I will happily enforce https-only for all public internet connections.

[bpoland]

Can you make it optional? I linked the certificates to my LE certs and it works great. maybe give an option to enable https, and provide a path to the certs?

[djcastaldo]

I’m looking into some alternatives. If we can find a way to make SSL work out-of-the-box for everyone, then I will happily enforce https-only for all public internet connections.

Or just make it a built-in reverse proxy, like has been documented in this thread using nginx. This system works great and anyone with a hostname can get a Let’s Encrypt cert for free. The cert request could be built-in to the app too.

[rog889]

Is NGNIX free?

Or just make it a built-in reverse proxy, like has been documented in this thread using nginx. This system works great and anyone with a hostname can get a Let’s Encrypt cert for free. The cert request could be built-in to the app too.

[tmm1]

There is no need for nginx or reverse proxying when the server can support HTTPS natively.

We have requested a rate limit increase from Let’s Encrypt. Once that is granted, we plan to issue subdomains to every user along with an SSL cert for that domain (similar to how Plex works).

EDIT: To clarify, the only reason to use nginx is if you have multiple domains/services that you are hosting on your custom domain via subdomains, and you want to use port 443 to access them all.

[LukeLambert]

That’s really good news. Channels DVR seems like the exact sort of project Let’s Encrypt/EFF would want to support. If they can make it work, I’ll definitely be donating to Let’s Encrypt, EFF, and the Mozilla Foundation. They’re great organizations. Please keep us posted.

I assume this also means you guys will be running a dynamic DNS service?

[tmm1]

I assume this also means you guys will be running a dynamic DNS service?

Yep, since LE only works with DNS that’s our only option. This will also enable us to streamline remote access from the iOS/tvOS apps.

[tmm1]

Anyone who wants to try the LE integration can upgrade (using curl commands) to xxxxxx and turn on the Remote Access feature at the bottom of the new Settings tab.

[ImNotSerious]

Logs sent

[tmm1]

Looks like there’s a bug causing crashes so don’t update.