Https: Is Emby secure?

[darkassassin07 423]

Hello everyone

 

Just going to start by saying I am by no means an expert on this topic, until about a month ago I was naive enough to think "It says https:// and there is a green lock so it must be secure".

I'm just hoping to spark some conversation in an effort to improve things and expand my knowledge.

 

 

With that out of the way:

 

I have been doing some testing using the SSL Test from Qualys SSL Labs against the https port provided by the Emby server on 5 different OSs:

Windows 7 (Professional and Ultimate), Windows 10, Ubuntu, Elementary, and FreeBSD.

 

In all cases I'm using the exact same certificate (.pfx) which contains my certificate and the CA cert from lets encrypt. The servers were all running on VMware VMs with freshly installed and fully updated OSs following the Download Instructions. (Except Win 7 Pro, that is my current server). other than adding the domain name and cert to emby there was no other configuration done.

 

 

 

Here are the images I captured of the test results for each server. (Dropbox folder, they are pretty large)

 

Starting with the best results, Windows 10:

This was the only OS to receive an 'A', the only negatives being the re-use of Diffie-Hellman parameters and the option for a couple weak ciphers though the server prefers the stronger ones. Both 'issues' are quite minor as far as I understand.

 

Next up we have Ubuntu and Elementary:

Both of these OSs received the same results, a 'C'.

These support the insecure protocol SSL v3 and only except weak and/or insecure ciphers.

They do not support forward secrecy meaning once a key is compromised all past and future traffic can be decrypted.

And they do not serve the full chain, only the main certificate.

 

Windows 7.... Oh windows 7....

This OS (both pro and ult) gets an 'F' as it supports both SSL v2 and SSL v3. These protocols are outdated and susceptible to attack.

Only 2 of the 11 supported ciphers aren't considered to be weak or insecure.

TLS 1.2 is not supported at all though it is the current standard.

Both win 7 and 10 serve the full certificate chain however.

 

and finally we have FreeBSD:

FreeBSD also receives an 'F'. It only supports 6 ciphers with no preference for which to use. All 6 are weak or insecure and used with SSL v3 and TLS 1.0 only.

It also fails to serve the full cert chain.

Then we have more of the same issues as above: SSL v3, no TLS 1.2, no forward secrecy ,etc.

 

 

 

 

For those of you that have Emby behind a reverse proxy such as NGINX this is of no consequence, but how many of you have a windows 7 server directly exposed to the web? how about FreeBSD? Personally I'm not even comfortable with the linux results but that's me.

 

Curious to see what you guys think, please do let me know if I have miss-interpreted something or am missing something.

 

Happy to learn,

- Dark

 

 

 

/edit the topic was named as such because we are talking about embys https security overall. Not whether a specific server is/isn't secure because it is or isnt behind a reverse proxy.

Edited June 26, 2018 by darkassassin07

[shorty1483 453]

Nice to test this all out.

 

Posted something like this 1 1/2 years ago, but never got an answer on this. And your tests are exactly the reason why I would never expose my server to the inet but use a reverse proxy instead.

 

https://emby.media/community/index.php?/topic/44529-server-more-secure-cipher-suites/

Edited June 25, 2018 by shorty1483

[PenkethBoy 2063]

Interesting results

 

One thing though the results are a reflection of the OS rather than Emby - are they not?

 

So perhaps the title of the thread could be "better" to reflect that?

[makarai 108]

Nice to test this all out.

 

Posted something like this 1 1/2 years ago, but never got an answer on this. And your tests are exactly the reason why I would never expose my server to the inet and use a reverse proxy.

 

https://emby.media/community/index.php?/topic/44529-server-more-secure-cipher-suites/

 

I am not sure if i understand you correctly.

 

You would not expose your server to the inet despite using a reverse proxy. 

 

Or.

 

you would only expose your server with a reverse proxy?

[shorty1483 453]

I am not sure if i understand you correctly.

 

You would not expose your server to the inet despite using a reverse proxy.

 

Or.

 

you would only expose your server with a reverse proxy?

Corrected my post. [emoji39]

[ebr 14918]

Renamed and moved to general discussion since this is not a support question for Emby Server.

 

Discuss on....

[adrianwi 238]

My emby server is running in a FreeBSD jail and is accessed externally via an NGINX reverse-proxy running in a FreeBSD jail.  The result below was using Chrome on a macOS device.

 

 

These results are more about how you've configured the server or access to the server, rather than the services you might be running.

[mastrmind11 717]

yep, reverse proxy will solve this.

[shorty1483 453]

My emby server is running in a FreeBSD jail and is accessed externally via an NGINX reverse-proxy running in a FreeBSD jail. The result below was using Chrome on a macOS device.

 

 

These results are more about how you've configured the server or access to the server, rather than the services you might be running.

yep, reverse proxy will solve this.

Yes that's also my setup, but as I already stated in my post above, this cannot be a solution for a media streaming product that offers external access via a domain out of the box. If this is offered, it has to be secure or at least configurable (option to activate negotiation of cipher suites that are considered as insecure for example). And this is the point of the OPs post I guess. And he is right imo. Edited June 25, 2018 by shorty1483

[mastrmind11 717]

Yes that's also my setup, but as I already stated in my post above, this cannot be a solution for a media streaming product that offers external access via a domain out of the box. If this is offered, it has to be secure or at least configurable (option to activate negotiation of cipher suites that are considered as insecure for example). And this is the point of the OPs post I guess. And he is right imo.

But does it though?  Technically speaking, Emby only offers out of the box LAN access.  The end user is the one punching holes in their router and exposing their server to the world.  IMO, and I would think (hope) by now that pretty much anyone even considering Emby for external streaming already realize the risks of that, and the onus to secure things is on them, right?

[Jdiesel 1114]

IMO, and I would think (hope) by now that pretty much anyone even considering Emby for external streaming already realize the risks of that, and the onus to secure things is on them, right?

 

I wouldn't count on it. I'm guessing the average user has UPnP enabled on their router and has no idea which applications, not just Emby, have ports open.

Edited June 25, 2018 by Jdiesel

[shorty1483 453]

But does it though?  Technically speaking, Emby only offers out of the box LAN access.  The end user is the one punching holes in their router and exposing their server to the world.  IMO, and I would think (hope) by now that pretty much anyone even considering Emby for external streaming already realize the risks of that, and the onus to secure things is on them, right?

 

Then I ask myself for what reason the external domain field in settings is. As @@Jdiesel states, the average user does not look at the things we look, the average user does not care of the used ciphers because he does not even know. He uses a self generated Emby cert and connects from outside to stream his stuff.

[mastrmind11 717]

yeah, I suppose you're right.

[Luke 37090]

The startup wizard will actually ask you if you want to enable remote access or not, and also asks about the automatic port mapper.

[shorty1483 453]

The startup wizard will actually ask you if you want to enable remote access or not, and also asks about the automatic port mapper.

 

C'mon Luke, you know how often users click on buttons to activate something without thinking about it.

 

 

But this is really no thread about discussing who is responsible for opening ports on his device and why. The discussion was about hardening the https part of Emby. Are there any plans Luke? Don't know if Emby still uses crypto-js since I had lots of trouble the last yearr and couldn't incorporate in the forum like I would like to.

[Luke 37090]

What do you have in mind specifically?

[adrianwi 238]

I'm in the tough love camp and think anyone using a computer should have a basic understanding of the security required to keep it secure. 

 

If they don't, and then choose, knowingly or not, to expose themselves externally without the appropriate protection, more fool them.

 

Perhaps software developers have a responsibility for more strongly worded warning messages, but the fact software can be used externally doesn't mean you should without understanding the risks.

[darkassassin07 423]

As Luke started Here:

 

We're able to configure the allowed protocols and we're leaving it at platform default.

 

This would lead me to believe there is improvements to be made, the Emby team has just chosen not to.

 

 

When I first began using Emby almost a year ago now, aside from a Garrys Mod server several years ago I had never hosted a web service before. I was mainly looking for a way to watch my media on the various devices in the house without having to move files allover the place, Streaming over the internet while away was a bonus. All I knew about security was that http was plain un-encrypted and https was the secure side of things. I had read somewhere while setting up emby you would need your own cert for WAN access and was recommended LE so over there I went. There I learned I would need a domain so I grabbed a cheap one from domains.google.com; got those setup, loaded the pfx and domain name into emby and that was that. There was no indication that that was inadequate or that I should look into things further. A false sense of security as it were.

 

 

While I wouldn't necessarily expect an A+ score from every Emby server in use, I would never expect to receive an F and in the case of Linux/FreeBSD to not serve the full chain? 

Embys server software offers a security solution right out of the box that in most cases is very outdated without any indication to the end user that more should be done. If you guys don't want to go to the trouble of creating a configuration for each platform that utilizes secure protocols/ciphers, at the very least it would be nice to be able to configure the SSL/TLS parameters used by Emby as an end user. Users shouldn't have to learn and configure another piece of third party software to secure the server that already advertises as secure through https.

 

I started using NGINX because I have accumulated several services Id like to access externally and not all of them have https capability. I only ended up testing Emby after the fact for a comparison and boy was I surprised.

Edited June 26, 2018 by darkassassin07

[chef 3746]

I put my server on a reverse proxy.

I trust Embys authentication rules to keep it safe.

 

When I was building a JavaScript version of a client there were two types of authentication/encryption needed to access the API and information.

 

I suppose that it would be still possible for some person to ddos my server through my domain if they really wanted to, shutting it down, but I hope that doesn't happen. {no bright ideas dudes...}

 

I feel pretty safe with the Let's encrypt certificates and the authentication in place from emby.

[darkassassin07 423]

The biggest thing I'm worried about here is if an attacker can intercept your admin account login info they can access the servers config > Settings > Custom css. Then you are loading code from an attacker in every browser that accesses your server. Its not just the server owner at risk, but every one of his/her users.

 

 

 

Again those of you/us that have Emby behind a revers proxy like NGINX this makes no difference, but what about those users that aren't. Whether that's because they don't know how, or because they are blissfully unaware that they should be.

Edited June 26, 2018 by darkassassin07

[chef 3746]

The biggest thing I'm worried about here is if an attacker can intercept your admin account login info they can access the servers config > Settings > Custom css. Then you are loading code from an attacker in every browser that accesses your server. Its not just the server owner at risk, but every one of his/her users.

 

 

 

Again those of you/us that have Emby behind a revers proxy like NGINX this makes no difference, but what about those users that aren't. Whether that's because they don't know how, or because they are blissfully unaware that they should be.

 

Oh my ...

 

I suppose the hacker could use design elements (like sudo elements) to create/change some content. Now that I think about it, it would be possible to create <script> tags in a sudo element... I think.

That would be dangerous.

The hacker would have to sniff the http requests, if the users were not encrypting their link to the internet. 

Is it possible to decrypt https/2? I think that is kinda hard, but again I'm not sure.

[pir8radio 1292]

The biggest thing I'm worried about here is if an attacker can intercept your admin account login info they can access the servers config > Settings > Custom css. Then you are loading code from an attacker in every browser that accesses your server. Its not just the server owner at risk, but every one of his/her users.

 

 

 

Again those of you/us that have Emby behind a revers proxy like NGINX this makes no difference, but what about those users that aren't. Whether that's because they don't know how, or because they are blissfully unaware that they should be.

 

I mean, who are you pissing off that they are attacking you....    Yea I know everyone no need to reply back that attacks happen to everyone...  But I had my emby server exposed to the net for years just using HTTP. Never once had an issue.   I even have a guest account with the login info that can be found using google.  My domain name has been around since around 1999-2000.   Even with the best HTTPS there can be a man in the middle without your users really knowing. 

 

Take for example :  Link Removed  my domain name....    If you follow that link it will lead you to the emby.media site, yet i am decrypting then re-encrypting everything so i can log it. (not actually logging it and I will remove it shortly, just proving a point)  I could do this for the emby connect login page, and maybe buy embry.media domain name    who would notice they clicked app.embry.com in a google search?    Some might, but i bet i could capture some logins.  Or social engineer the login info from the domain name owner and point their domain name to my server first.  

 

Long story short don't piss off the bad guys and you will be fine.     Things you should be looking into DNSSEC, HPKP and all of that fancy stuff that emby cant possibly bake into their software and have it be user friendly...    They do the basics, its up to you to beef it up if you feel you will be attacked...  Like a reverse proxy.

Edited June 26, 2018 by pir8radio

[darkassassin07 423]

Hoping you wont get attacked is a terrible policy.

 

If someone knew that the security provided by emby was easy to deal with, knew the default port many people would likely use, and knew they could use access to those servers to distribute their malware to a potentially huge user base all of those servers are now easy targets.

 

You will find people looking to get into things they shouldn't in the strangest places sometimes. Two weeks ago on the 7-11 public wifi in my small town everyone was suddenly getting https insecure connection warnings. If you looked at the certificate on any of the warnings on any of the connected devices they had been replaced by one from signmeup.arubanetworks.com

They don't have to be attacking your home network directly. Maybe you or another of your users stumbles upon the wrong guy on the wrong wifi network. Now he has your servers ip/domain and can attack later. Hypothetical, but all too possible.

 

 

Im not trying to have Emby turned into fort knox, just lock the door with a bit more than a zip tie. It keeps out the casual onlookers, but someone that decides they want in wouldn't need as much effort as they should.

Edited June 26, 2018 by darkassassin07

[pir8radio 1292]

Hoping you wont get attacked is a terrible policy.

 

If someone knew that the security provided by emby was easy to deal with, knew the default port many people would likely use, and knew they could use access to those servers to distribute their malware to a potentially huge user base all of those servers are now easy targets.

 

You will find people looking to get into things they shouldn't in the strangest places sometimes. Two weeks ago on the 7-11 public wifi in my small town everyone was suddenly getting https insecure connection warnings. If you looked at the certificate on any of the warnings on any of the connected devices they had been replaced by one from signmeup.arubanetworks.com

They don't have to be attacking your home network directly. Maybe you or another of your users stumbles upon the wrong guy on the wrong wifi network. Now he has your servers ip/domain and can attack later. Hypothetical, but all too possible.

 

 

Im not trying to have Emby turned into fort knox, just put up a little more than a paper lock at the door.

 

I think what they have is fine for home media users.   At least that was the point i was going for...  I wouldn't call it "paper lock" HTTPS of any kind is going to protect you from scriptkiddies.   Paypal.com a banking site gets a B, Chase.com bank site B.  Emby got an A in win 10, wow thats better than a bank. lol.  Emby uses the underlying OS for its security.  The issue appears to be in the OS no?      But I get all of your points...   I guess it's like asking a locksmith how they feel about locks.......   Most of this stuff is to stop the amateurs.  If you were a real worth while target then I would say yes, lock-R-down.     

 

    Going to remove my little man in the middle link above.....     I would rather see 2FA (like authy) supported for my emby accounts. 

 

Oh and the wifi issue you talked about above, aruba is the maker of the public wifi hotspots. The city probably decrypts the traffic and re-encrypts it to monitor the HTTPS traffic, we do this at my work.  Or someone misconfigured the system, if it was a hacker you probably wouldn't have noticed anything. 

Edited June 26, 2018 by pir8radio

[darkassassin07 423]

Oh and the wifi issue you talked about above, aruba is the maker of the public wifi hotspots. The city probably decrypts the traffic and re-encrypts it to monitor the HTTPS traffic, we do this at my work. Or someone misconfigured the system, if it was a hacker you probably wouldn't have noticed anything.

This was on a public wifi provided by telus in a small town in canada. It only happened for about 10min then returned to normal.

 

I digress, the point there was to show you don't have to piss someone off or do something to make yourself a target. Hackers will attack devices/software they think are vulnerable regardless of where they are or who owns them.

When it comes down to whether or not your particular server will be attacked the answer is its very unlikely. But when you consider the number of servers there are or will be and how many of them will be run by people who just don't know any better. Is it not worth making sure those servers have an acceptable level of security?

 

Literally just disable SSL V2/3 and you will no longer get 'F's

Edited June 26, 2018 by darkassassin07