HTTPS is everywhere these days, but not many people think that much about which cipher suites are considered safe. Cipher suites determines what encryption algorithms are used to secure the communication over HTTPS, and as time goes on older cipher suites fall out of fashion as they are are proven to be weak or vulnerable to certain attacks.

If you followed my guide on how to enable HTTP/2, we’ve already fixed some of the issues with TLS, namely disabling TLSv1 and TLSv1.1 and enabling TLSv1.3.

We’ll need to add the ciphers we want to NGINX use. This can be done in a specific server block, or in the /etc/nginx/nginx.conf file. Keep in mind that anything added in a server block supersedes the main configuration file.

I’ve used the Mozilla Foundation’s Intermediate cipher list, which is available preformated for your specific web server, which is rather handy. The Intermediate cipher suite list is the best I’ve found, it offers good security without compromising on compatibility.

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;

That’s it, but there’s one caveat. If you followed my guide on how to Get Started with Let’s Encrypt there’s another place that this can definied. Certbot, being forever almost too helpful, add the following line to your server blocks

include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

This file contains the SSL options that Certbot thinks are optimal, but they are a bit outdated.

# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file.

ssl_session_cache shared:le_nginx_SSL:1m;
ssl_session_timeout 1440m;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS";

The easiest way to get around this problem is to comment out the line starting with ssl_ciphers, and adding your own in your server block or in the same file below. Keep in mind that editing this file stops Certbot from updating it in the future, but since you’re reading this guide, that shouldn’t be a problem since you’re already managing these options yourself.

Make sure to check out the previous parts of this series, some of them more useful than others.
Part 1 – Redirecting IP Traffic to HTTPS with NGINX
Part 2 – Implementing HTTP 418 Errors on NGINX
Part 3 – Enabling HTTP/2 on NGINX

Categories: Tech

Tags: https, Internet, linux, nginx, security, SSL, TLS, web server