Jump to content

Emby isn't closing used network ports.


anderbytes
 Share

Recommended Posts

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

runtimesandbox

 

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

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

runtimesandbox

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

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

  • 4 months later...
runtimesandbox

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 by spudy12
Link to comment
Share on other sites

I'm eager to test out .netcore

 

Sent from my ASUS_Z017DA using Tapatalk

Link to comment
Share on other sites

  • 2 months later...

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

Just for curiosity, do you use Docker?

 

Sent from my ASUS_Z017DA using Tapatalk

Link to comment
Share on other sites

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

  • 2 weeks later...
runtimesandbox

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

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

runtimesandbox

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

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

  • 3 weeks later...
runtimesandbox

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

runtimesandbox

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

  • Like 1
Link to comment
Share on other sites

  • 2 years later...

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

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...