Web Player: No HTTPS support?

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.

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.

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

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.

1 Like

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.

1 Like

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.

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.

1 Like

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.

1 Like

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?

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.

Is NGNIX free?

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.

2 Likes

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?

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.

2 Likes

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.

1 Like

Logs sent

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

I had rolled back immediately this morning. Would be happy to test again.

Also of note, it didn’t overwrite the old pem and key files from when I purchased a cert for the previous test. I had deleted them on a second attempt, but the results were obviously the same.

The new LE cert is stored in settings.db, so it gets backed up and can be transferred to a new installation. The old cert.key is still used as a backup, or when you try to access SSL over an “unknown” domain name.

So… If I have an existing cert (manually assigned) using my own domain from LE or otherwise, will this allow both to be accepted? both the manually assigned cert and the dymanic dns based channels cert?