Apache/Nginx - Disable Weak TLS Ciphers

[TheDreadPirate]

***DISCLAIMER - THIS WILL CAUSE SSL/TLS HANDSHAKE ISSUES WITH VERY OLD OPERATING SYSTEMS AND BROWSERS THAT DON'T SUPPORT THESE STRONG CIPHERS***

Having said that, if you are using an operating system old enough to not support any of these strong ciphers, Jellyfin probably doesn't work on the system anyway.

BACKUP YOUR APACHE/NGINX CONFIGS BEFORE PROCEEDING!!!

This is not a guide to setup a reverse proxy with Apache or Nginx.  This is for users who are already running a Jellyfin server behind an Apache or Nginx reverse proxy and these instructions assume this has already been completed.  Additionally, this only applies if you already have certs and are using HTTPS.  For new Apache or Nginx users, please review the official docs and post in the troubleshooting section of the forum if you need help with the initial setup.

https://jellyfin.org/docs/general/networking/apache/
https://jellyfin.org/docs/general/networking/nginx/
https://jellyfin.org/docs/general/networ...tsencrypt/

Only a few additional lines to an Apache or Nginx config are required to disable weak ciphers.

====Apache====

Within your site config, usually in /etc/apache2/sites-available/000-default.conf, there is this section of parameters that define how Apache handles SSL/TLS.  This example is taken from the official Jellyfin Apache guide.

Code:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/DOMAIN_NAME/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN_NAME/privkey.pem
Protocols h2 http/1.1
# Enable only strong encryption ciphers and prefer versions with Forward Secrecy
SSLCipherSuite HIGH:RC4-SHA:AES128-SHA:!aNULL:!MD5
SSLHonorCipherOrder on
# Disable insecure SSL and TLS versions
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

While this disables the absolute weakest of ciphers, there is new guidance to further restrict the ciphers offered.
Replace the entire section above with the following.

Code:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/DOMAIN_NAME/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN_NAME/privkey.pem
# Enable only strong encryption ciphers and prefer versions with Forward Secrecy
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:RSA-AES256-GCM-SHA384
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384
SSLOpenSSLConfCmd Curves secp384r1
SSLHonorCipherOrder On
SSLSessionTickets Off
Protocols h2 http/1.1
# Disable insecure SSL and TLS versions
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
# HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
Header always set Strict-Transport-Security "max-age=63072000"

Restart Apache.

====Nginx====

The process is pretty much identical.  If you followed the official Jellyfin Nginx guide, your Jellyfin reverse proxy config is at /etc/nginx/conf.d/jellyfin.conf.
From the official Jellyfin Nginx guide, the SSL section we are going to change looks like the following.

Code:

ssl_certificate /etc/letsencrypt/live/DOMAIN_NAME/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/DOMAIN_NAME/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
add_header Strict-Transport-Security "max-age=31536000" always;
ssl_trusted_certificate /etc/letsencrypt/live/DOMAIN_NAME/chain.pem;

Swap these lines out for the following.

Code:

include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_certificate /etc/letsencrypt/live/DOMAIN_NAME/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/DOMAIN_NAME/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/DOMAIN_NAME/chain.pem;
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;
ssl_session_tickets off;
# HSTS (ngx_http_headers_module is required) (63072000 seconds)
add_header Strict-Transport-Security "max-age=63072000" always;

Restart Nginx.

************************

Sources:

https://media.defense.gov/2021/Jan/05/20...443-20.PDF
https://github.com/nsacyber/Mitigating-Obsolete-TLS

[niels]

A good source for SSL configurations is the Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org/. You can even see which software versions will be supported so you can easily see if your old Fire TV device will work or not!

[TheDreadPirate]

A good source for SSL configurations is the Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org/. You can even see which software versions will be supported so you can easily see if your old Fire TV device will work or not!

Indeed.  That is one of the included links in the NSA github link in my sources.  That NSA github also includes links to verify your SSL/TLS settings, including testing for other common vulnerabilities.  Heartbleed, for example.  I used https://testtls.com/.

[bitmap]

Okay...so for somebody who has a wide breadth of expertise, barely any of networking -- and even less of that in security, how would I even get started on learning about What any of this means?

For instance, I ran my JF instance through the testing site you posted and didn't get a whole lot of warnings or any red flags, the largest one was that my cert expires in less than 60 days (it renews via CertBot probably about that often), but some of the other warnings might as well have been in a different alphabet for how much sense they made to me and there aren't really any resources I'm aware of for learning what it means, identifying a root cause, searching for proper solutions, then implementing.

Thoughts?

[TheDreadPirate]

Okay...so for somebody who has a wide breadth of expertise, barely any of networking -- and even less of that in security, how would I even get started on learning about What any of this means?

For instance, I ran my JF instance through the testing site you posted and didn't get a whole lot of warnings or any red flags, the largest one was that my cert expires in less than 60 days (it renews via CertBot probably about that often), but some of the other warnings might as well have been in a different alphabet for how much sense they made to me and there aren't really any resources I'm aware of for learning what it means, identifying a root cause, searching for proper solutions, then implementing.

Thoughts?

I wouldn't worry about that particular cert message.  In the grand scheme of the Internet, 90 day certs are uncommon so that test just doesn't account for users like us.

A lot of the concepts in this kind of report is covered in certs like Network+, Security+, CCNA, and CISSP.  I have the pluses.  A past job suddenly required everyone have the two latter certs before realizing the first try failure rate for both is like 80% and they would lose most of their IT workforce.  But I was halfway through studying for them before they dropped the requirement. But my day-to-day job still frequently involves OS and network security.

That NSA github link in my sources has some background info.  One is really technical, one is mile high overview.  But its something.  Read the wikis on TLS, HTTPS, and Forward Secrecy.

https://github.com/nsacyber/Mitigating-O...rmation.md
https://media.defense.gov/2021/Jan/05/20...RAPHIC.PDF
https://media.defense.gov/2021/Jan/05/20...443-20.PDF

https://en.wikipedia.org/wiki/Forward_secrecy
https://en.wikipedia.org/wiki/Transport_Layer_Security   (emphasis on the TLS Handshake section https://en.wikipedia.org/wiki/Transport_..._handshake)
https://en.wikipedia.org/wiki/HTTPS

I don't have access to the last report I ran, but if you send me a PM I will give you my email so you can send your report to me.  ctrl + S on that test webpage and send me the html file it saves.  I can give brief descriptions of the important bits in it.

[bitmap]

For anybody running LSIO swag, you can set this up by editing /swag/nginx/ssl.conf

Comment out the following:

Code:

# intermediate configuration (original to swag -- backup config)
#ssl_protocols TLSv1.2 TLSv1.3;
#ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
#ssl_prefer_server_ciphers off;

And replace it with what's recommended above:

Code:

# disable weak TLS ciphers (may break some things)
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;

While you're in here, you may as well change a few things that were recommended here and are already part of this config but commented out:

Code:

# HSTS (ngx_http_headers_module is required) (63072000 seconds)
#add_header Strict-Transport-Security "max-age=63072000" always;

Which is commented out (just uncomment the second line). The ssl_session_tickets off; option already exists correctly as above in the ssl.conf so there's no need to add this in the swag config files.

You can also change some of the other header-related items that are recommended, but I am still looking at how this affects my other offerings. I turned on:

Code:

add_header X-Content-Type-Options "nosniff" always;

And that hasn't broken anything that I can tell as of yet. I was able to remove this from my Jellyfin proxy-conf file.

I ran the SSL test again right after changing the config and got a LOT more green, but still had some issues I'm not sure are accurate. Anyway, I figured that after I tinkered and figured out how to get this working in Swag, I'd share with other folks as well. Thanks again for your help with explaining what the report meant @TheDreadPirate!