Why would any home user "need" this sort of sophisticated granular control with encryption and certificates?
I agree
generally. Though I feel I should chime in on one nuance (since it was brought up). I do agree with the OP's point #2 on encryption generally. I don't think they necessarily need to expose the ugly complexities of the certs to the end user, but encryption?
MC should, IMHO, encrypt MCWS traffic with TLS. I don't think it needs to be impenetrable, but... It
should encrypt it. And, since you're just going to do this using one of the common LGPL libraries out there like OpenSSL (or one of the various post-heartbleed "re-dos" of it), you should make an effort to do it well and pre-set it with good, sensible defaults.
As it is, if you poke a hole through your firewall at home and stream your media across the Internet, you are transmitting all of that (
including the authentication MC does) in the clear. That raises a few issues:
* The authentication isn't really much of a lock: If you come to my office or house and use MC on your laptop to connect to your home server, over my network without VPN, with Wireshark and a few minutes to spare, I can delete your entire Library from disk on your server.
* Even assuming no malicious actors on the same LAN as you (or at their ISP, or their ISP, or yours, or wherever it gets routed on this rickety series of tubes we call the Internet) are watching for MCWS traffic and trying to nuke your files for lulz... Many regular people out there use the same password for multiple things. So, sniffing passwords is useful not just to attack MC, but to try to get the "keys to the kingdom" (your email account which can then be used to reset most of your other passwords).
* I don't feel entirely comfortable with my boss, a bored sysad, or some guy on the same public hotspot as me at an airport, being able to watch the filenames fly by of what I'm watching or listening to or looking at in my Library. Is it my banking data? No. But it is creepy. And, it could be valuable "marketing" data on us to know everything you watch and look at and listen to, so there's
also the creepy building-a-dossier-on-every-human-advertising-tech-behemoth(s) out there to be vaguely creeped out about.
Again, IMHO, it
would be best if MC
did TLS encrypt all MCWS traffic. I've agitated about this myself a few times before (and you can call this an opportunity to do it again). I do not think they need to expose a bunch of fancy options to set your own certificates (and other things that would appeal to an enterprise environment). It is fine to just auto-generate a self-signed certificate on install and then prompt the user to accept it on the first connection (right before it prompts for the username and password). Like I said above, it doesn't need to be impenetrable, but... No encryption at all is not just "ok" because it targets home users.
And for the record, if you have a server with authentication enabled (and so therefore allowing changes to the Library via MCWS) you should really be using a VPN. At least, you should know what you are signing up for before you poke a hole through your firewall to allow access to that Library from the WAN.
Author
Topic: JRiver Media Server - missing features (Read 5502 times)