Luke 37065 Posted November 24, 2016 Share Posted November 24, 2016 Great thanks, it looks pretty simple. Link to comment Share on other sites More sharing options...
sv3nno 2 Posted November 24, 2016 Share Posted November 24, 2016 After setting up nginx as reverse proxy on another VM I do not see this problem anymore. There are a bunch of stale connections, these originate from the reverse proxy (naturally), but more importantly they have a timer on them and are actually timing out and gets closed after a while: tcp 0 0 10.0.80.10:20000 10.0.40.52:33340 TIME_WAIT timewait (21.98/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33244 ESTABLISHED off (0.00/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33328 TIME_WAIT timewait (5.85/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33350 TIME_WAIT timewait (49.89/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33344 TIME_WAIT timewait (41.62/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33324 TIME_WAIT timewait (5.77/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33326 TIME_WAIT timewait (5.80/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33320 TIME_WAIT timewait (5.69/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33310 TIME_WAIT timewait (3.94/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33330 TIME_WAIT timewait (5.91/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33312 TIME_WAIT timewait (5.48/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33338 TIME_WAIT timewait (18.57/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33304 TIME_WAIT timewait (0.21/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33308 TIME_WAIT timewait (1.33/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33302 TIME_WAIT timewait (0.16/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33332 TIME_WAIT timewait (6.01/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33346 TIME_WAIT timewait (45.12/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33348 TIME_WAIT timewait (48.48/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33336 TIME_WAIT timewait (11.40/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33306 TIME_WAIT timewait (0.51/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33316 TIME_WAIT timewait (5.64/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33322 ESTABLISHED off (0.00/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33342 TIME_WAIT timewait (31.34/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33300 TIME_WAIT timewait (0.13/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33314 TIME_WAIT timewait (5.60/0/0) Link to comment Share on other sites More sharing options...
Luke 37065 Posted November 24, 2016 Share Posted November 24, 2016 Thanks for the info. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted November 26, 2016 Share Posted November 26, 2016 After setting up nginx as reverse proxy on another VM I do not see this problem anymore. There are a bunch of stale connections, these originate from the reverse proxy (naturally), but more importantly they have a timer on them and are actually timing out and gets closed after a while: tcp 0 0 10.0.80.10:20000 10.0.40.52:33340 TIME_WAIT timewait (21.98/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33244 ESTABLISHED off (0.00/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33328 TIME_WAIT timewait (5.85/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33350 TIME_WAIT timewait (49.89/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33344 TIME_WAIT timewait (41.62/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33324 TIME_WAIT timewait (5.77/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33326 TIME_WAIT timewait (5.80/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33320 TIME_WAIT timewait (5.69/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33310 TIME_WAIT timewait (3.94/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33330 TIME_WAIT timewait (5.91/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33312 TIME_WAIT timewait (5.48/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33338 TIME_WAIT timewait (18.57/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33304 TIME_WAIT timewait (0.21/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33308 TIME_WAIT timewait (1.33/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33302 TIME_WAIT timewait (0.16/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33332 TIME_WAIT timewait (6.01/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33346 TIME_WAIT timewait (45.12/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33348 TIME_WAIT timewait (48.48/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33336 TIME_WAIT timewait (11.40/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33306 TIME_WAIT timewait (0.51/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33316 TIME_WAIT timewait (5.64/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33322 ESTABLISHED off (0.00/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33342 TIME_WAIT timewait (31.34/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33300 TIME_WAIT timewait (0.13/0/0) tcp 0 0 10.0.80.10:20000 10.0.40.52:33314 TIME_WAIT timewait (5.60/0/0) Keep us posted with whether or not you experience the issue again with this new setup. AS far as I know you shouldn't but you never know! Link to comment Share on other sites More sharing options...
anderbytes 139 Posted November 26, 2016 Author Share Posted November 26, 2016 But it shouldn't be needed a reverse proxy to be able to use Emby in Linux. I'm still hopeful for the removing of Mono Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted November 27, 2016 Share Posted November 27, 2016 But it shouldn't be needed a reverse proxy to be able to use Emby in Linux. I'm still hopeful for the removing of Mono Agreed, but for a work around it will work. Hoping this net core makes mono obsolete but ti will likely take a while Link to comment Share on other sites More sharing options...
Luke 37065 Posted November 27, 2016 Share Posted November 27, 2016 You should give the .net core build a try. They have video setup guides for almost every OS. The girl in the video sets it up in about three minutes. Link to comment Share on other sites More sharing options...
sv3nno 2 Posted November 30, 2016 Share Posted November 30, 2016 The workaround with nginx has worked flawlessly since I set it up. Have not had to restart emby service at all. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted April 28, 2017 Share Posted April 28, 2017 (edited) The workaround with nginx has worked flawlessly since I set it up. Have not had to restart emby service at all. Yep same here. It must be an issue with mono and https. Hopefully the switch to .netcore will fix that in the future I can even reliably use chromecasts externally now! Edited April 28, 2017 by spudy12 Link to comment Share on other sites More sharing options...
anderbytes 139 Posted April 28, 2017 Author Share Posted April 28, 2017 I'm eager to test out .netcore Sent from my ASUS_Z017DA using Tapatalk Link to comment Share on other sites More sharing options...
blastbass 0 Posted July 16, 2017 Share Posted July 16, 2017 Hello all, Do you have any update about this issue ? I experiencing the same problem on my debian with emby installed. All connections with an unexpected disconnection remain ESTABLISHED .... With the android app for exemple. Only one little solution, reboot each days the service to purge all zombies TCP connections. But is not a really workaround ... Link to comment Share on other sites More sharing options...
anderbytes 139 Posted July 16, 2017 Author Share Posted July 16, 2017 Just for curiosity, do you use Docker? Sent from my ASUS_Z017DA using Tapatalk Link to comment Share on other sites More sharing options...
blastbass 0 Posted July 16, 2017 Share Posted July 16, 2017 Previously yes, and i had the same problem, but i had not identified it. I have test in HTTP and HTTPS, same problem. I am forced to reboot the service to set the state of all TCP connections from ESTABLISHED to TIME_WAIT Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted July 30, 2017 Share Posted July 30, 2017 I'd recommend using a nginx reverse proxy for handling SSL. much easier to implement a secure configuration and you won't run in to this issue. Also easy to use lets encrypt Link to comment Share on other sites More sharing options...
anderbytes 139 Posted July 31, 2017 Author Share Posted July 31, 2017 I'd recommend using a nginx reverse proxy for handling SSL. much easier to implement a secure configuration and you won't run in to this issue. Also easy to use lets encrypt Actually this is a very good question: native Emby SSL vs Reverse SSL Proxy. Anybody knows the best way to measure this? Is there any online tool to measure, or simulate attack, something like that? Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted July 31, 2017 Share Posted July 31, 2017 Actually this is a very good question: native Emby SSL vs Reverse SSL Proxy. Anybody knows the best way to measure this? Is there any online tool to measure, or simulate attack, something like that? You can use ssl labs https://www.ssllabs.com/ssltest/ I don't know what cipher suites and protocols emby server defines for ssl but my guess it would go for compatibility over security. With the reverse proxy you are able to define enabledcipher suites, use the latest technologies like http2 and only allow recent protocols Would be interested in seeing a comparison between the two Link to comment Share on other sites More sharing options...
anderbytes 139 Posted July 31, 2017 Author Share Posted July 31, 2017 Would be interested in seeing a comparison between the two I'd happily do these comparisons myself, but I'm really busy these days. Probably mid August I'll be back on tracks. Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted August 18, 2017 Share Posted August 18, 2017 I finally had a chance to setup a dev environment and test the default emby server config. I have used testssl to run the tests against both a *reasonably* secure nginx reverse ssl proxy and the default emby ssl configuration. Server: Ubuntu 16.04 Reverse SSL Proxy Results: (Because it finished first, testing emby itself is taking a long time - assuming thats down to mono) ########################################################### testssl.sh 2.9dev from https://testssl.sh/dev/ (5ea2b7c 2017-08-13 11:32:24 -- ) This program is free software. Distribution and modification under GPLv2 permitted. USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK! Please file bugs @ https://testssl.sh/bugs/ ########################################################### Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers] on ubuntuDev:bin/openssl.Linux.x86_64 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64") Start 2017-08-17 22:49:57 -->> 10.0.0.37:443 (hostname) <<-- rDNS (10.0.0.37): {hostname}. Service detected: HTTP Testing protocols via sockets except SPDY+HTTP2 SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 not offered TLS 1.1 not offered TLS 1.2 offered (OK) SPDY/NPN h2, http/1.1 (advertised) HTTP2/ALPN h2, http/1.1 (offered) Testing ~standard cipher categories NULL ciphers (no encryption) not offered (OK) Anonymous NULL Ciphers (no authentication) not offered (OK) Export ciphers (w/o ADH+NULL) not offered (OK) LOW: 64 Bit + DES encryption (w/o export) not offered (OK) Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) not offered (OK) Triple DES Ciphers (Medium) not offered (OK) High encryption (AES+Camellia, no AEAD) offered (OK) Strong encryption (AEAD ciphers) offered (OK) Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 Elliptic curves offered: secp384r1 Testing server preferences Has server cipher order? yes (OK) Negotiated protocol TLSv1.2 Negotiated cipher ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Cipher order TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA Testing server defaults (Server Hello) TLS extensions (standard) "server name/#0" "renegotiation info/#65281" "EC point formats/#11" "status request/#5" "heartbeat/#15" "next protocol/#13172" "application layer protocol negotiation/#16" Session Ticket RFC 5077 hint (no lifetime advertised) SSL Session ID support yes Session Resumption Tickets: yes, ID: yes TLS clock skew Random values, no fingerprinting possible Signature Algorithm SHA256 with RSA Server key size RSA 2048 bits Fingerprint / Serial SHA1 F2F3EB3EEBEC262A4768B814237EFFB7212DC9E2 / 0360EC4ABF04D4B676A1ED83587CD377CE95 SHA256 9200E2693D588713BEF496FD0CB8A099A43121D6F06D18CCF17BD5CB0FD7008C Common Name (CN) hostname (CN in response to request w/o SNI: hostname) subjectAltName (SAN) hostname hostname Issuer Let's Encrypt Authority X3 (Let's Encrypt from US) Trust (hostname) Ok via SAN (same w/o SNI) Chain of trust Ok EV cert (experimental) no Certificate Expiration 63 >= 30 days (2017-07-22 11:19 --> 2017-10-20 11:19 +0100) # of certificates provided 2 Certificate Revocation List -- OCSP URI http://ocsp.int-x3.letsencrypt.org OCSP stapling offered OCSP must staple no DNS CAA RR (experimental) -- Certificate Transparency no Testing HTTP header response @ "/" HTTP Status Code 302 Found, redirecting to "web/index.html" HTTP clock skew 0 sec from localtime Strict Transport Security 365 days=31536000 s, includeSubDomains Public Key Pinning -- Server banner nginx Application banner -- Cookie(s) (none issued at "/") -- maybe better try target URL of 30x Security headers -- Reverse Proxy banner -- Testing vulnerabilities Heartbleed (CVE-2014-0160) not vulnerable (OK), timed out CCS (CVE-2014-0224) not vulnerable (OK) Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension Secure Renegotiation (CVE-2009-3555) not vulnerable (OK) Secure Client-Initiated Renegotiation not vulnerable (OK) CRIME, TLS (CVE-2012-4929) not vulnerable (OK) BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested POODLE, SSL (CVE-2014-3566) not vulnerable (OK) TLS_FALLBACK_SCSV (RFC 7507) No fallback possible, TLS 1.2 is the only protocol (OK) SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK) FREAK (CVE-2015-0204) not vulnerable (OK) DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK) make sure you don't use this certificate elsewhere with SSLv2 enabled services https://censys.io/ipv4?q=9200E2693D588713BEF496FD0CB8A099A43121D6F06D18CCF17BD5CB0FD7008C could help you to find out LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected BEAST (CVE-2011-3389) no SSL3 or TLS1 (OK) LUCKY13 (CVE-2013-0169) VULNERABLE, uses cipher block chaining (CBC) ciphers RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK) Testing 359 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC) ----------------------------------------------------------------------------------------------------------------------------- xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 384 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 384 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 384 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 384 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Running client simulations via sockets Android 2.3.7 No connection Android 4.1.1 No connection Android 4.2.2 No connection Android 4.4.2 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 384 bit ECDH (P-384) Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 384 bit ECDH (P-384) Android 7.0 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Baidu Jan 2015 No connection Chrome 51 Win 7 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Edge 13 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Edge 13 Win Phone 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Firefox 49 Win 7 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Firefox 49 XP SP3 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) IE 11 Win 7 TLSv1.2 ECDHE-RSA-AES256-SHA384, 384 bit ECDH (P-384) IE 11 Win 8.1 TLSv1.2 ECDHE-RSA-AES256-SHA384, 384 bit ECDH (P-384) IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES256-SHA, 384 bit ECDH (P-384) IE 11 Win Phone 8.1 Update TLSv1.2 ECDHE-RSA-AES256-SHA384, 384 bit ECDH (P-384) IE 6 XP No connection IE 7 Vista No connection IE 8 Win 7 No connection IE 8 XP No connection Java 6u45 No connection Java 7u25 No connection Java 8b132 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 384 bit ECDH (P-384) OpenSSL 1.0.1l TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) OpenSSL 1.0.2e TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Safari 5.1.9 OS X 10.6.8 No connection Safari 6.0.4 OS X 10.8.4 No connection Safari 7 OS X 10.9 TLSv1.2 ECDHE-RSA-AES256-SHA384, 384 bit ECDH (P-384) Safari 8 OS X 10.10 TLSv1.2 ECDHE-RSA-AES256-SHA384, 384 bit ECDH (P-384) Safari 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Tor 17.0.9 Win 7 No connection Done 2017-08-17 22:50:40 [ 45s] -->> 10.0.0.37:443 (hostname) <<-- Emby Server Default SSL Configuration Still running, results so far ########################################################### testssl.sh 2.9dev from https://testssl.sh/dev/ (5ea2b7c 2017-08-13 11:32:24 -- ) This program is free software. Distribution and modification under GPLv2 permitted. USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK! Please file bugs @ https://testssl.sh/bugs/ ########################################################### Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers] on ubuntuDev:bin/openssl.Linux.x86_64 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64") Start 2017-08-17 22:48:57 -->> 10.0.1.59:8920 (10.0.1.59) <<-- rDNS (10.0.1.59): -- Service detected: HTTP Testing protocols via sockets except SPDY+HTTP2 SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 offered TLS 1.1 offered TLS 1.2 offered (OK) SPDY/NPN not offered HTTP2/ALPN not offered Testing ~standard cipher categories NULL ciphers (no encryption) not offered (OK) Anonymous NULL Ciphers (no authentication) not offered (OK) Export ciphers (w/o ADH+NULL) not offered (OK) LOW: 64 Bit + DES encryption (w/o export) not offered (OK) Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) not offered (OK) Triple DES Ciphers (Medium) offered High encryption (AES+Camellia, no AEAD) offered (OK) Strong encryption (AEAD ciphers) offered (OK) Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 PFS is offered (OK) ECDHE-RSA-CHACHA20-POLY1305-OLD ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA Elliptic curves offered: prime256v1 secp384r1 X25519 Testing server preferences Has server cipher order? nope (NOT ok) Negotiated protocol TLSv1.2 Negotiated cipher ECDHE-RSA-CHACHA20-POLY1305-OLD, 384 bit ECDH (P-384) (limited sense as client will pick) Negotiated cipher per proto (limited sense as client will pick) ECDHE-RSA-AES256-SHA: TLSv1, TLSv1.1 ECDHE-RSA-CHACHA20-POLY1305-OLD: TLSv1.2 No further cipher order check has been done as order is determined by the client Link to comment Share on other sites More sharing options...
Luke 37065 Posted August 18, 2017 Share Posted August 18, 2017 Why not try it out with .net core: https://emby.media/community/index.php?/topic/50012-emby-server-for-net-core/ 1 Link to comment Share on other sites More sharing options...
runtimesandbox 152 Posted August 18, 2017 Share Posted August 18, 2017 Yes will also do that as a comparison! Doesn't look like testssl is ever going to finish the cipher enumeration on the mono version of emby. It'll be interesting to see if the .NET core version of emby resolves the original issues in this thread too. Will post back when I get results from it 1 Link to comment Share on other sites More sharing options...
Luke 37065 Posted January 27, 2020 Share Posted January 27, 2020 You can use ssl labs https://www.ssllabs.com/ssltest/ I don't know what cipher suites and protocols emby server defines for ssl but my guess it would go for compatibility over security. With the reverse proxy you are able to define enabledcipher suites, use the latest technologies like http2 and only allow recent protocols Would be interested in seeing a comparison between the two Emby Server 4.4 will have http2 support on Windows and Linux. 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