Jump to content

Webserver TLS version


anderbytes
 Share

Recommended Posts

anderbytes

Hi, can you upgrade the TLS version used for SSL connection in Emby?

 

I've been tuning my Firefox's security configurations, and when I enable "security.ssl.require_safe_negotiation = true" it returns me the error "SSL_ERROR_UNSAFE_NEGOTIATION" at the moment I try to enter Emby web client.

 

Googling a little returned me that the TLS version may be insecure at the webserver.... in this case Emby's embeeded webserver that uses the .pfx for enabling HTTPS.

 

Thanks.

  • Like 1
Link to comment
Share on other sites

shorty1483

So @@Luke the security the Emby Webserver provides depends on Mono if I understand right? And if Mono gets updated, the Server provides automatically more secure connections? Is this anyhow adjustable in the future? Thanks!

Link to comment
Share on other sites

  • 3 months later...
shorty1483

Correct yes.

 

Any news about it, specially regarding Emby on Windows? Still AES_128_CBC with SHA1 preferred with Chrome in latest version. At least, GCM suites should be supported. Just using TLS1.2 does not guarantee security.

 

5946d61775afd_Unbenannt.png

Edited by shorty1483
Link to comment
Share on other sites

Try searching around a bit to see which of those the .net framework 4.6 supports. If we have to update to 4.7 that's fine too.

  • Like 1
Link to comment
Share on other sites

shorty1483

Try searching around a bit to see which of those the .net framework 4.6 supports. If we have to update to 4.7 that's fine too.

 

As far I can see, updating would not bring any benefit.

 

But while searching around, I found libsodium for .Net, which looks very promising in my eyes as a programming n00b, you're the dev in terms of realizability. In terms of security, is it absolutely state of the art.

 

Github:

https://github.com/adamcaudill/libsodium-net

 

Documentation:

https://bitbeans.gitbooks.io/libsodium-net/content/

Link to comment
Share on other sites

shorty1483

From a personal standpoint I would say a reverse proxy is the best path to go down if on wants security,

I agree, a reverse proxy is nice to combine several services and to use a user defined security guideline. But you cannot rely that everyone who uses Emby is such a Techi-Tech--Reverse-Proxy-Setup-Guy like you, me or e.g. @@Swynol or @@pir8radio . In the origins, the weakness of the default emby webserver implementation forced me to try out nginx. I like Nginx and play a lot with it (see sig), but if Emby default webservice would provide state of the art mechanisms, I would use that for sure. And I'm sure that a lot of users who expose their servers to the public and have no clue about Reverse Proxies don't know what they risk without appropriate security. If I imagine being a tech noob I would expect it by default.

 

My personal conclusion: A Program/Service which advertises with mobile connectivity should rely on actual security out of one hand without installing reverse proxies etc. Nevertheless no offense to the devs because I imagine that it's a lot of work.

Edited by shorty1483
Link to comment
Share on other sites

Swynol

Reverse proxy was the 'best' solution for me due to the amount of services i run. I also wanted more control  over headers and security. 

 

Since moving to a reverse proxy, Emby has up'd its game as far as HTTPS and SSL are concerned. For example they now use a password protected .pfx which solves the private key being easily extracted. And now they are looking at TLS versions. For the average user setting up a SSL connection within emby by just ticking a few boxes makes life easier. Its only us geeks who like to tinker that would benefit more from a reverse proxy setup.  

 

As @@Night says added other software hardware in front of your emby server is another way to boost security. I run 2 firewalls in front of emby, one is very lax the other is alot more strict and like Night's it can geofilter, IP log, block connections on x number of incorrect logins, all traffic is scanned for viruses, spyware and ransom ware.  

 

Talking about wannacry, I work in the NHS in Wales, we were hit by it however luckily not to the extent NHS England was. There are now alot of changes happening internally, They are finally talking Cyber Security more seriously, even simple things like upping TLS versions on our connections, adding extra security headers, stricter firewalls and blocking protocols. 

Link to comment
Share on other sites

shorty1483

I agree, but is it worth devs time to implement cipher/tls selection for a handful of users? 99% would use default.

 

User selection is not the purpose of my request m8, I also think this would be to much. I just talk about implementing actual and known as secure cipher suites instead of using old obsolete ones. When the servers would have implemented and preferred e.g. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 in his advertisment, a modern browser like Chrome or FF would use that by default anyways ( https://emby.media/community/index.php?/topic/44529-server-more-secure-cipher-suites/ ). No user setting or interaction.

 

With the libsodium link above this could be possible, but I will wait for @@Luke 's opinion if the lib could make sense for Emby in terms of functionality and compability.

 

Since moving to a reverse proxy, Emby has up'd its game as far as HTTPS and SSL are concerned. For example they now use a password protected .pfx which solves the private key being easily extracted. And now they are looking at TLS versions. For the average user setting up a SSL connection within emby by just ticking a few boxes makes life easier. Its only us geeks who like to tinker that would benefit more from a reverse proxy setup.  

 

As @@Night says added other software hardware in front of your emby server is another way to boost security. I run 2 firewalls in front of emby, one is very lax the other is alot more strict and like Night's it can geofilter, IP log, block connections on x number of incorrect logins, all traffic is scanned for viruses, spyware and ransom ware.  

 

Talking about wannacry, I work in the NHS in Wales, we were hit by it however luckily not to the extent NHS England was. There are now alot of changes happening internally, They are finally talking Cyber Security more seriously, even simple things like upping TLS versions on our connections, adding extra security headers, stricter firewalls and blocking protocols. 

 

I know what you mean and I recognize and honor that every part of Emby gets better step by step.

 

But you know yourself that Emby wants to be as intuitive and automatic as it can be (reference e.g. Android TV thread). I'm pretty sure most users just download server and use it without several security / DMZ systems or VPN's in front. Even lot of https users often just use internet manuals without knowing exactly what they are doing.

Edited by shorty1483
Link to comment
Share on other sites

Tur0k

One of the issues with encryption is legacy hardware support.

The closer you get to bleeding edge encryption types and ciphers the more legacy devices become unusable. In my house I don't care much since our smart devices seem to get replaced or fail within 2 years or so. My HTPC desktops are patch managed and are updated regularly.

 

I prefer my reverse proxy (currently running on HAproxy) because when another cipher or encryption type bites the dust and becomes deprecated I edit my global settings in HAProxy and then test my devices.

 

Currently, I force all traffic to TLS1.2 and only support newer ciphers. I will likely begin testing the latest draft of TLS1.3 within the next few weeks. My expectation is that any older smart device or tab will likely not be supported by this config, but again I don't think that will be a problem for me.

 

 

Sent from my iPhone using Tapatalk

Edited by Tur0k
Link to comment
Share on other sites

shorty1483

One of the issues with encryption is legacy hardware support.

The closer you get to bleeding edge encryption types and ciphers the more legacy devices become unusable. In my house I don't care much since our smart devices seem to get replaced or fail within 2 years or so. My HTPC desktops are patch managed and are updated regularly.

 

I prefer my reverse proxy (currently running on HAproxy) because when another cipher or encryption type bites the dust and becomes deprecated I edit my global settings in HAProxy and then test my devices.

 

Currently, I force all traffic to TLS1.2 and only support newer ciphers. I will likely begin testing the latest draft of TLS1.3 within the next few weeks. My expectation is that any older smart device or tab will likely not be supported by this config, but again I don't think that will be a problem for me.

 

 

Sent from my iPhone using Tapatalk

 

It's not forbidden that server still supports older ciphers (e.g. TLS 1.0 ciphers), as long as some remarks like Forward Secrecy are kept in my opinion. SSL Server Test by ssllabs delivers good examples for the different scenarios. As long as the server provides latest but also older considered secure ciphers, the client chooses the one most appropriate for the own connection.

 

Regarding TLS 1.3, does Chrome support any draft later than 18 in meanwhile? That's why openssl set up an own draft18 branch on github. I tried it but there were several ClientHello errors because of 0-RTT implementation. I decided to try again when TLS1.3 is final and it's fully supported by all dev participants I use. But you're right. TLS1.3 implementation gets interesting, I guess this will be a long process regarding the device support, since IETF drops support for so many insecure or obsolete features including compression, renegotiation, non-AEAD ciphers, static RSA and DH key exchange etc.

Link to comment
Share on other sites

Tur0k

It's not forbidden that server still supports older ciphers (e.g. TLS 1.0 ciphers), as long as some remarks like Forward Secrecy are kept in my opinion. SSL Server Test by ssllabs delivers good examples for the different scenarios. As long as the server provides latest but also older considered secure ciphers, the client chooses the one most appropriate for the own connection.

Agreed, security/compatibility is a double edged sword. In my house everything works with TLS 1.2 without issue. When running larger deployments with a wider range of devices only running TLS1.2 and 256 bit or higher ciphers may not be well supported. It is interesting that there is some evidence that the ssl3.0 poodle attack can be targeted at TLS directly (https://blog.qualys.com/ssllabs/2014/12/08/poodle-bites-tls). This problem has more to do with the implementation (browser manufacturers) of TLS1.x than the protocol itself.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...