anderbytes 139 Posted February 24, 2017 Share Posted February 24, 2017 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. 1 Link to comment Share on other sites More sharing options...
Luke 37009 Posted February 24, 2017 Share Posted February 24, 2017 mono 4.8 now supports TLS 1.2: http://www.mono-project.com/docs/about-mono/releases/4.8.0/ But we are just beginning testing with it. 1 Link to comment Share on other sites More sharing options...
anderbytes 139 Posted February 24, 2017 Author Share Posted February 24, 2017 Okay Link to comment Share on other sites More sharing options...
shorty1483 450 Posted February 26, 2017 Share Posted February 26, 2017 Okay Could be related to this req https://emby.media/community/index.php?/topic/44529-server-more-secure-cipher-suites/ . Feel free to like. Link to comment Share on other sites More sharing options...
Luke 37009 Posted February 26, 2017 Share Posted February 26, 2017 I would suggest checking out the 4.8 release notes about the new TLS support: http://www.mono-project.com/docs/about-mono/releases/4.8.0/ Link to comment Share on other sites More sharing options...
shorty1483 450 Posted February 28, 2017 Share Posted February 28, 2017 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 More sharing options...
Luke 37009 Posted February 28, 2017 Share Posted February 28, 2017 Correct yes. 1 Link to comment Share on other sites More sharing options...
shorty1483 450 Posted June 18, 2017 Share Posted June 18, 2017 (edited) 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. Edited June 18, 2017 by shorty1483 Link to comment Share on other sites More sharing options...
Luke 37009 Posted June 18, 2017 Share Posted June 18, 2017 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. 1 Link to comment Share on other sites More sharing options...
shorty1483 450 Posted June 19, 2017 Share Posted June 19, 2017 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 More sharing options...
shorty1483 450 Posted June 19, 2017 Share Posted June 19, 2017 (edited) 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 June 19, 2017 by shorty1483 Link to comment Share on other sites More sharing options...
Swynol 375 Posted June 19, 2017 Share Posted June 19, 2017 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 More sharing options...
shorty1483 450 Posted June 19, 2017 Share Posted June 19, 2017 (edited) 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 June 19, 2017 by shorty1483 Link to comment Share on other sites More sharing options...
Tur0k 143 Posted June 20, 2017 Share Posted June 20, 2017 (edited) 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 June 20, 2017 by Tur0k Link to comment Share on other sites More sharing options...
shorty1483 450 Posted June 20, 2017 Share Posted June 20, 2017 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 More sharing options...
Tur0k 143 Posted June 21, 2017 Share Posted June 21, 2017 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 More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now