Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AndrewFG]

I have been following this HouseBand thread http://yabb.jriver.com/interact/index.php/topic,102709.0.html with great interest, and indeed I am close to buying myself an Amazon Dot, 'cos it all seems rather cool.

Today I imagine that most MCWS calls, or indeed other MC web server calls, come in from any one of "Joe Average" IP addresses, so they they are probably below the radar for attracting much attention. However if you have an increasing take up of customers using Alexa (or Cortana, or OK Google, or Siri) then you will have an increasing number of calls coming from Amazon servers (or Microsoft, or Google, or Apple). Which may attract outside eavesdropping more.

You might say, who cares if a snooper learns that I am a closet Abba fan, but even such a tidbit can add to the credibility of an identity theft. Not to mention that I don't want anyone browsing my family photos say.

Therefore, I wonder if you should think again about hardening MC's HTTP security by adding an SSL layer.

I know that you guys will push back with arguments about certificate supply and management, and/or arguments about CPU loading (e.g. when streaming transcoded video). But nevertheless I think you should consider this, and perhaps add it as a four way choice option (Disable, Force, Force on calls from WAN, Follow client URL request).

What do you think?

[mwillems]

I'd like to add my support for this.  You can sort of hack it in now using a reverse proxy, but that's way outside the lane of the average user.  Especially as certs can now be obtained for free from letsencrypt, there's really never been a better time to try and get something like this off the ground: users can grab their own certs for free or you could add some automation support to help people use letsencrypt (I'm not sure how far you could go with the automation and not run afoul of the terms of use, but at minimum you could provide good instructions).

If the thought of having users provision their own ssl certs (even in a semi-automated way) gives you pause, one alternative that competing services (emby or plex) offer is to handle the SSL, authentication, and/or NAT traversal issues via their servers; sort of like the current access key system on steroids.  A service like that could be a fair bit of work, but would add a lot of value for the average user who doesn't know or care how to configure port forwarding much less SSL and/or a reverse proxy.  You could make the web services both more secure and more usable for the new user.

Such a service would need to be optional and well-explained (so people realize what is and isn't being sent to your servers if they turn it on), but might improve out of the box user experience and security for non-power users at the same time.  I don't personally need or want such a service (I'd be happy to just be able to point JRiver at a cert manually), but it seems like you could resolve a significant volume of tech support requests that way. 

In any case, I'd be perfectly happy if there were any built in way to use HTTPS with JRiver at all; certs are easy to get now.

[AndrewFG]

Interesting feedback.

As you know SSL does two things, a) authentication, and b) encryption. The authentication part allows a client to verify that the server is really the one it claims to be. And the encryption part provides transport level encryption of the data stream. And most browsers show a (black) padlock in the address bar if the data stream is encrypted, plus an additional green indication if the server is also authenticated.

In the context of MC I think the essential part is the encryption. This does require a certificate (actually a public/private key pair), but this certificate does not necessarily need to be authenticated. (A so called self generated / self signed certificate). And the certificate must be "unique" insofar as no outsider may know the private key.

Theoretically JRiver could create and deliver such a certificate for each user of MC. The only requirement is that the certificate must be unique and the certificate distribution process must itself be secure.

When you buy a registered version of MC, you get an MJR file by email. The MJR is unique. So it could be used either a) as a transport key for unlocking an encrypted certificate provided in a separate email by JRiver, or b) as a unique "seed" for locally generating a certificate.

[glynor]

I'd like to add my support for this.  You can sort of hack it in now using a reverse proxy, but that's way outside the lane of the average user.  Especially as certs can now be obtained for free from letsencrypt, there's really never been a better time to try and get something like this off the ground: users can grab their own certs for free or you could add some automation support to help people use letsencrypt (I'm not sure how far you could go with the automation and not run afoul of the terms of use, but at minimum you could provide good instructions).

You wouldn't even need to do this. A self-signed certificate would be perfectly adequate to provide security on the MCWS traffic (self-signed certs encrypt the traffic just as well as ones issued by a CA). That would not, of course, provide server identity verification, but since we are running the servers ourselves, this is basically irrelevant.

MC could automatically install a self-signed cert, and provide the user with the ability (in options) to upload their own cert if they have one and really want to use it.

That's all that is needed. Really, the core is that MC needs to serve the pages over HTTPS, and use a modern crypto package.

As you know SSL does two things, a) authentication, and b) encryption. The authentication part allows a client to verify that the server is really the one it claims to be. And the encryption part provides transport level encryption of the data stream. And most browsers show a (black) padlock in the address bar if the data stream is encrypted, plus an additional green indication if the server is also authenticated.

In the context of MC I think the essential part is the encryption.

Exactly.

[glynor]

For the record, the best way to run a secure MCWS server right now is to access it only through an encrypted VPN. I'm hoping MCWS can be secured for the future, and redirect all traffic to HTTPS by default (except for old, not-updated clients). But... In the interim, if you need to do it, you're probably best using a VPN rather than doing the reverse proxy thing.

Also... I've yelled about this for years to no avail, but it isn't only privacy that is a concern. Since there is no encryption, the username and password for all connections to MCWS are sent in the clear. That means if you come to my house and connect to your MC server, I can sniff the username and password, and then go in and delete all of your media! I won't unless you really tick me off, but I could. Hopefully you don't use MC on public wifi at a coffee shop next to a bored teenager.

It isn't just about "someone might see what I'm watching/listening to". It is about basic data security. MCWS can mass delete files.

[mwillems]

For the record, the best way to run a secure MCWS server right now is to access it only through an encrypted VPN. I'm hoping MCWS can be secured for the future, and redirect all traffic to HTTPS by default (except for old, not-updated clients). But... In the interim, if you need to do it, you're probably best using a VPN rather than doing the reverse proxy thing.

I agree; I currently use a private VPN myself rather than a reverse proxy.  My point was that the only current way to wrap MCWS in an https wrapper with no muss and fuss on the user end (i.e. in a way that actually works like visiting a normal https website) is to use a reverse proxy.  My current interest in getting working https is to make it easier for my wife and family to use JRiver away from home, as a VPN is a non-starter for her (much less the rest of my family) and I'm not willing to allow unencrypted access as they all use public wifi.  I'm currently working out the kinks in a reverse proxy to get them sorted, but would love not to have to maintain one.

A VPN is certainly an easier and more robust solution if you don't need your services to be easily accessible to non-tech savvy family members or on networks that block VPN access (which are more common than I would like, especially in hotels and vacation homes).  There are lots of ways to do it if you don't need it to be easy for end users, hell you can reverse tunnel the traffic through ssh if you want to (I've done it in a pinch). 

You wouldn't even need to do this. A self-signed certificate would be perfectly adequate to provide security on the MCWS traffic (self-signed certs encrypt the traffic just as well as ones issued by a CA). That would not, of course, provide server identity verification, but since we are running the servers ourselves, this is basically irrelevant.

As you know SSL does two things, a) authentication, and b) encryption. The authentication part allows a client to verify that the server is really the one it claims to be. And the encryption part provides transport level encryption of the data stream. And most browsers show a (black) padlock in the address bar if the data stream is encrypted, plus an additional green indication if the server is also authenticated.

In the context of MC I think the essential part is the encryption. This does require a certificate (actually a public/private key pair), but this certificate does not necessarily need to be authenticated. (A so called self generated / self signed certificate). And the certificate must be "unique" insofar as no outsider may know the private key.

Theoretically JRiver could create and deliver such a certificate for each user of MC. The only requirement is that the certificate must be unique and the certificate distribution process must itself be secure.

When you buy a registered version of MC, you get an MJR file by email. The MJR is unique. So it could be used either a) as a transport key for unlocking an encrypted certificate provided in a separate email by JRiver, or b) as a unique "seed" for locally generating a certificate.

I think the authentication piece is non-trivial if the goal is to improve the out of the box experience for end users.  MCWS is not just an endpoint for apps, it's also an endpoint for webgizmo/panel.  Using a self signed cert will result in anyone attempting to use webgizmo/panel having their browsers screaming scary warnings about untrusted certs until one adds the cert to their trust store or (browser permitting) adds a permanent exception.  This would not be particularly user friendly for non tech savvy family members or guests, but the real killer would be for folks who use webgizmo at work (of which there are a few).  My work, for example, won't let us add cert exceptions or navigate through to sites with "fake" certs. I've also had a few android apps complain or fail entirely when I used self-signed certs for various services, but since JRiver controls their own app ecosystem, I expect they could solve that particular issue.

I agree that any support for user-supplied certs at all would be fantastic.  That's all I need myself, and I would be 100% happy with a box in options-->media network that let me point JRiver to a cert I supplied.  I'm not the target market for auto-config and I suspect you two aren't either.

For non-technical users, auto-generating self-signed certs might be better than nothing, but I think if JRiver is going to do anything by way of autoconfiguration (anything more than just supporting using your own cert), that it's worth considering helping users to get fully "certified" certs or just offer a "fee-for-service" to handle the authentication/match-making for them to avoid replacing one stream of help requests with another one stemming from the shortcomings of untrusted certs.  This doesn't necessarily need to involve each end user setting up a FQDN with a trusted cert, as I noted several competing services effectively do their own matchmatching/authentication with their own servers in the middle for a periodic fee.

[AndrewFG]

I also would be happy if in the first phase, MC just provided minimal support for user installed certs. As: "if you find a cert in xyz directory then use it with HTTPS else use HTTP"..

However, as intimated in my prior post, JRiver could if it wanted provide/generate certs itself via the MJR route. In that case JRiver would essentially act as a sub Certification Authority issuing user certs that had an authentication path via the JRiver CA and their respective Root CA.

BTW the work around route of going via VPN is a non starter in my use case (using Amazon Alexa devices to voice control MC). Whereas the other work around route of a reverse proxy would probably do the trick (depending perhaps on some port forwarding tricks).

If the worse comes to the worse, if JRiver does not rise to the challenge, I might have to consider writing a reverse proxy application myself for this very specific MC case. In which case I would probably have its setup program generate a self signed cert as part of the install process.

[mwillems]

However, as intimated in my prior post, JRiver could if it wanted provide/generate certs itself via the MJR route. In that case JRiver would essentially act as a sub Certification Authority issuing user certs that had an authentication path via the JRiver CA and their respective Root CA.

Oh I see what you were thinking now, that hadn't occurred to me.

If the worse comes to the worse, if JRiver does not rise to the challenge, I might have to consider writing a reverse proxy application myself for this very specific MC case. In which case I would probably have its setup program generate a self signed cert as part of the install process.

Let me know if you get one built, at the rate I'm going you may be done with it before I've got a bog standard Nginx reverse proxy working correctly with all my services  .  In addition to JRiver, I also run a few other services on the same domain. Some of the services support https natively and some do not, and getting everything to behave well simultaneously with the SSL reverse proxy has been challenging. Although I am a "bear of very little brain" when it comes to this corner of things, I keep plugging away at it...

[AndrewFG]

If I were to do it, then the way I would write my reverse proxy would be as follows.

First of all, I would set my router to forward WAN port 52199 to the LAN IP address of, and a "spare" port on, the HTPC e.g. 192.168.1.234:567 (say).

The reverse proxy would be a simple application running along with MC on the same HTPC.

The proxy would accept incoming GETs on port 567 (say) providing HTTPS protocol support, and just back to back the payload in plain to localhost:52199

I might need to swap over any port references (567 <=> 52199) in the HTTP request & response headers.

[glynor]

I agree that any support for user-supplied certs at all would be fantastic.  That's all I need myself, and I would be 100% happy with a box in options-->media network that let me point JRiver to a cert I supplied.  I'm not the target market for auto-config and I suspect you two aren't either.

For non-technical users, auto-generating self-signed certs might be better than nothing, but I think if JRiver is going to do anything by way of autoconfiguration (anything more than just supporting using your own cert), that it's worth considering helping users to get fully "certified" certs or just offer a "fee-for-service" to handle the authentication/match-making for them to avoid replacing one stream of help requests with another one stemming from the shortcomings of untrusted certs.  This doesn't necessarily need to involve each end user setting up a FQDN with a trusted cert, as I noted several competing services effectively do their own matchmatching/authentication with their own servers in the middle for a periodic fee.

And therein lies the rub:
For a periodic fee.

IMHO... Baby steps gets the gold, my friend. Get us robust TLS support first (but please do allow us to supply our own certs, for exactly the reasons mwillems illustrated). That solves the 80% case.

Then we can see about a fancy auto-registering real authenticated certs system next year, if it works and if people in the wild actually need it.

Please note: I'm thrilled this is coming up again. If you search, I've posted long rants about it for years going back.

[mwillems]

And therein lies the rub:
For a periodic fee.

IMHO... Baby steps gets the gold, my friend. Get us robust TLS support first (but please do allow us to supply our own certs, for exactly the reasons mwillems illustrated). That solves the 80% case.

Then we can see about a fancy auto-registering real authenticated certs system next year, if it works and if people in the wild actually need it.

Please note: I'm thrilled this is coming up again. If you search, I've posted long rants about it for years going back.

Sure the perfect is the enemy of the good, support for TLS self-supplied certs would be golden for me.

[gvanbrunt]

I have to agree SSL is 100% must in todays world. I cringe hanging MC off my router. In fact I actually disabled it until I can get some kind VPN going.

I've had no have external access to MC for several months as I don't have the time to mess with VPN stuff on my phone etc. 

[djfalstaff]

For you programmers out there, there's another alternative as well.
Pick your programming language of choice and write a web service of your own that becomes the only exposure point to the outside world then relay the call where it needs to go on your local network.
If you are only using JRiver, this definitely overkill but let's say you have a new Yamaha amp that also has a built-in REST service. I have at least 5 different APIs on my network just off the top of head that I could wrapper into one protected, mega service. Plus, you could extend it to talk to more than API at once.

For example
https://mysupercoolhouse.com/jriverandchill/1

It could talk to my harmony remote and turn on my entertainment center
then set the amp volume to a certain exact volume
then set my LIFX lights to warm white and 30% brightness
then play my "JRiver and Chill" playlist on JRiver.

When I looked up those APIs, they all have a least a handful of commands that aren't exposed to IFTTT or Alexa or other services.

Setting the Yamaha amp volume to an exact volume is the one that really bugged me.

[rudyrednose]

Good thread, but the developing team point of view is sorely missing ...
I am in favor of baby steps here.  Basic TLS/SSL support plus some way to point MC to a certificate to use should be enough.

[AndrewFG]

For you programmers out there, there's another alternative as well.
Pick your programming language of choice and write a web service of your own that becomes the only exposure point to the outside world then relay the call where it needs to go on your local network.

Yup. I am working on it.   (I might even release it to third parties at some point)

Good thread, but the developing team point of view is sorely missing ...

Yup.

Basic TLS/SSL support plus some way to point MC to a certificate to use should be enough.

Yup. (See above). There are three possible solutions for the certificate part..

• Self Signed Certificate: The problem is that when you use HTTP your data is NOT secure, but your browser doesn't report an error message; whereas if you use HTTPS with a self- signed certificate, the data IS secure, but your browser reports a bad certificate error; so unsophisticated users may think the latter is worse than the former..
  
  
• Commercial Certificate: If you want to buy a proper certificate from normal suppliers like Symantec, Thawte, or VeriSign, it will cost you around $150 per year..
  
  
• Lets Encrypt Certificate: This is free of charge, and does not generate any browser errors. (See for example the website mentioned in my sig). However you can only get a Lets Encrypt Certificate if you own an internet registered domain name, and you have an actual live website running on that domain. You also need to jump through some hoops on that web site to establish credentials.