INTERACT FORUM
More => Old Versions => JRiver Media Center 23 for Windows => Topic started by: Hendrik on June 12, 2017, 08:14:24 am
-
In Media Center 23, MC gained the ability to host the Library Server and MCWS, and all related services like WebGizmo and Panel, over HTTPS.
This feature is disabled by default due to the required certificates, and can be enabled in Options -> Media Network -> Advanced -> Enable SSL
The server is based on the most recent security technologies and supports TLS 1.0 up to TLS 1.2 (older SSLv2 or SSLv3 protocols are not supported, as they are considered insecure).
Certificates
To use SSL/TLS encryption, you need a certificate. Media Center supports generating a self-signed certificate automatically, or lets you provide your own certificate.
Here is a short primer what these differences basically mean to you:
Self-signed certificates have the advantage of being immediately available, however web browsers do not trust them, and you'll get a security warning when connecting to MCWS or Panel with a browser, and because everyone can just create a new self-signed certificate, you have no information about which server you are actually connecting to. They otherwise provide the same secure encryption as "trusted" certificates, however.
Certificates issued by a Certificate Authority have the advantage of creating a chain of trust, if you own a certificate for a certain Domain/Server, the Certificate Authority will have verified in some way or form that you actually own this server, and a chain of trust is established - when you connect to this server, you know that it's this server. Browsers trust these certificates, as long as the Certificate Authority is trust-worthy.
So what kind of certificate do you need for Media Center? Well, that's up to you. Setting up a fully trusted certificate, especially for a library server running from your home, can be a bit complicated, while generating a self-signed certificate happens in a matter of seconds. In my opinion, if your primary goal is to be able to securely communicate with MC so that your username/password and your media cannot be "snooped", even on open WiFi or insecure networks, then a self-signed certificate will do the job.
Status
- 23.0.2: Implemented HTTPS server support
- 23.0.8: HTTPS Client support for Media Center clients is available
- Support in mobile remote apps is planned
Why don't you automatically get certificates from Lets Encrypt?
Some of you interested in HTTPS support have expressed interest in services like Lets Encrypt being integrated directly into MC to try to obtain trusted certificates automatically. We've explored these ideas, but due to the fact that MC most of the time is hosted on home connections, behind a router/firewall and without a permanent DNS name, the effort required to set this up on the user's side takes the value out of such an "automation", and we're more likely to investigate options to allow power users to update the certificate MC uses automatically (ie. in a script), so such an automation could be set up externally.
-
One note on the upcoming client support (even though i'm not sure when 23.0.3 will be made available, which would include it)
We currently disable any certificate verification, until we can decide how to handle this.
The Access Key server will actually list the fingerprint of the certificate used by the server (if you use an Access Key to connect), so we're thinking we can establish a secondary line of trust through the Access Key server, and only if that fails, perhaps prompt the user once, but this will require some more work, and in the meantime MC will just accept any certificate.
PS:
In the current state (unless it changes until the build is made), to connect to a HTTPS server you'll need to enter the URL directly: m01ps://xx.xx.xx.xx:52200 - m01ps:// being the prefix for the HTTPS-based library server connection. Maybe I'll make a checkbox instead.
-
Are you using OpenSSL for this? TLSv1.3 is coming soon (though still in a working draft and only is available if building from the OpenSSL Git) but I wouldn't rush to support it yet. Firefox has support for draft 18 enabled by default and Chrome did too until users started noticing issues with it enabled so they disabled it. :P
This is a VERY important feature indeed. :D
-
We're using GnuTLS. We scored an "A-" on SSL Labs SSL Server Test, mostly because of some older ciphers that are still enabled for compatibility.
-
Oh, nice! This *should* allow for cross-platform support too. :D
-
Definitely works on Linux already. Mac is still in the work I think, due to some build issues, but yes, its fully cross-platform.
-
Great news!
-
This is great news!
-
Even though it didn't quite make the change log yet because its not fully complete, you can make MC 23.0.3 connect to a MC23 Library Server using HTTPS now, as hinted in a post above by specifying the protocol directly:
Like this: m01ps://xx.xx.xx.xx:52200
If you use Access Key, there is no way to do it yet. The full GUI for that is still in the work.
-
I assume there will be a JRemote release too?.
-
Updates for mobile clients will be coming a bit later. Probably Android first, unless someone beats me to it. ;)
Obviously server support had to be the first, and MC client support is just relatively easy (even if a bit wasted for something most people likely only use locally).
-
This alone is a huge step for MC23. Glad to see it be incorporated, looking forward to seeing the change in JRemote :)
Thanks!
-
Any plans to support LetsEncrypt, this way we get a free SSL certificate that browsers don't moan about.
-
Any plans to support LetsEncrypt, this way we get a free SSL certificate that browsers don't moan about.
It's probably not that easy. I have done a few tests on Let's encrypt, and currently it only works with sites that have a registered domain name; but it won't help you at all with sites using an IP address (like 192.168.1.xxx). (And IMHO nor should it).
Basically cert validation depends (at least partly) in proving a binding between a domain and a cert..
-
It's probably not that easy. I have done a few tests on Let's encrypt, and currently it only works with sites that have a registered domain name; but it won't help you at all with sites using an IP address (like 192.168.1.xxx). (And IMHO nor should it).
Basically cert validation depends (at least partly) in proving a binding between a domain and a cert..
Assuming you've got a domain name and a letsencrypt cert, the certs can be made to work with no browser complaints with local IPs as well provided you're willing to setup split DNS on your router (and that your router supports it). Basically use your router as your DNS cache (which is often the default configuration, and has a lot of other potential advantages), and then configure your router to resolve the domain name in question to a local address when traffic originates inside the LAN, etc. I've been doing that for about a year with other services and it works great (no browser complaints).
Obviously not trivial to set up even if you've got everything already working with LetsEncrypt, but possible with some elbow grease. Automating letsencrypt for most home users is not likely to be viable; much easier for most people to just to set your self-signed cert to trusted in your and your families browsers.
-
I use a CNAME DNS entry (ie. an alias) in my own domain that points to a DynDNS account, and acquire a LetsEncrypt cert for that. However, there is a bunch of manual work involved for the initial setup, and a custom script to renew that certificate so I don't have to keep port 443 open at all times (for tls-sni auth).
As commented on in the original post in this thread, automating LE certificate retrieval for home connections is complicated, for various reasons. Lack of a domain name for one, problems with firewalls/routers on port 80 or 443 for authentication, and whatnot.
Of course nothing stops you from achieving this manually and feeding the cert to media center. I do plan to try to offer command line commands to renew the certs used by MC somehow, for full scripting. Although thats not done yet.
-
I don't understand what this is all about. Does this allow easy access to a Server Library when outside my home network (like over the internet)?
-
I don't understand what this is all about. Does this allow easy access to a Server Library when outside my home network (like over the internet)?
It doesn't make external access easier, but it does make it more secure by encrypting the traffic and your login credentials. If you ever notice the small lock in your browser bar when visiting bank or commerce websites that's a sign that your connection to those sites is encrypted, which adds a layer of security; this is the same thing. Previously if you wanted to use JRiver outside of your network, you could only communicate using an uncrypted protocol (http); the new feature allows you to instead communicate via an encrypted protocol (https). This is significantly more secure if you ever access your jriver server from insecure locations, like, for example, using public wifi as there's a much smaller chance that someone on the public wifi network with you could sniff your login credentials. It's some extra work to setup, but has benefits.
TL;DR, It doesn't provide "easy" access outside your home LAN, but it does provide more secure access when outside your own LAN
-
I think I have a bug in web gizmo SSL support in 23.0.19. This is something I've longed for. I access my library over the internet from remote locations on a regular basis and web gizmo and the flash player are close to my heart...
SSL access works with web gizmo but when you attempt to play a movie or tv show you get a file not found error.
The url referenced in the error begins with HTTP:// instead of HTTPS:// tho the port number is correct for the ssl connection. This is likely why you get the file not found error.
The flash player launch process needs to to be updated to understand that there is an https:// path to the file and to use it when your using secure access. please... :)
Thanks very much for this btw! If you travel for a living and want access to your library while on the road this is the BOMB!
(side query: any chance flash is going to retire in favor of an html5 player? flash support in browsers is fading away. they all require extra tweaking to get flash to run now...)
Steve D.
-
We're working in this area now. Thanks for the report.
-
Even though it didn't quite make the change log yet because its not fully complete, you can make MC 23.0.3 connect to a MC23 Library Server using HTTPS now, as hinted in a post above by specifying the protocol directly:
Like this: m01ps://xx.xx.xx.xx:52200
If you use Access Key, there is no way to do it yet. The full GUI for that is still in the work.
am I right in thinking the above is the current state?
I added this to MC because I just setup a ssl equipped vpn. Should I care if mc is using ssl or not given the connection is via a secure vpn? I would think it is irrelevant in that case but I am definitely not a security expert!
-
Recent versions have a checkbox to set connection to secure. You can still use the m01ps protocol prefix if you want to, or you can just enter the IP/Port or Access Key and click the checkbox.
If SSL is being used, it'll say so on the library page (ie. "Library Name" is a client of the Library Server with the access key xxxxxx (secure connection))
If you're already running on an encrypted VPN, and thats the only way you ever use it, encrypting the connection on top of that is probably not very meaningful.
-
A question:
I'm trying to host an ssl enabled MC instance behind a web-reachable domain name, but my IP address is not static (I'm using a dynamic DNS service to keep my domain pointing at my IP). I can access webgizmo/panel via the domain name easily enough, but it seems like Android Gizmo and JRemote won't accept FQDNs as server addresses, they'll only accept IP addresses.
Is there any way currently to use a FQDN for the android apps, and if not could this be added?
-
- Support in mobile remote apps is planned
Is this coming soon?
-
- Support in mobile remote apps is planned
Is this coming soon?
I have the same question. Since the mobile apps are most likely the connections coming through insecure networks, one would have assumed this to be a priority.
-
Is there an update for JRmote (iOS) needed to take advantage of this?
I use JRemote daily for accessing my library outside of my home network.
--
-
can we get an update on this?
if there is a different/preferred channel to ask this question let us know.
thanks in advance
-
How do you set up webgizmo to work with MC 23? Is there a step by step instruction?
-
How do you set up webgizmo to work with MC 23? Is there a step by step instruction?
If I recall correctly, Panel replaced WebGizmo.
https://yabb.jriver.com/interact/index.php/topic,105883.0.html
-
Im hoping panel will be enhanced to allow building playlists on the fly, add, play next, play only - with similar features as webgizmo. Unless there is another method to build playlists using an app with my web browser on a remote notebook, MC 23 won't work in my setup.
-
Should SSL work with JRemote on iOS as well? ::)
-
Is there an update on this for the mobile apps?