This tutorial shows you how to set up strong SSL security and reduced latency/lookup on the nginx webserver. We do this by updating OpenSSL to the latest version to mitigate attacks like Heartbleed, CRIME and LogJAM. We’ll disable weak ciphers because of vulnerabilities and set up a strong cipher suite that enables Forward Secrecy when possible. We also enable HSTS and HPKP, along with other SSL directives incl. valid CAA and proper SSL protocols. This way we have a strong future proof ssl configuration.
We are going to edit the nginx.conf file (
/etc/nginx/nginx.conf) or wherever you have the nginx.conf located. Make a backup to ensure a easy rollback in case an error occurs.
OpenSSL is a tool which implements cryptographic protocol functions and standards of SSL and TLS. In short, it is the tool which deals with cryptography, encryption and security in linux. The major use of OpenSSL is to generate self-signed certificates.
Why do we need an SSL certificate?
When communicating with a server a intruder can see the details you are sending to a server. The information can be sensitive like credit card number etc. So to keep this information secure between your browser and the server, you can use SSL certificate. These certificates are used when you want your site to change from http to https. Updating OpenSSl can have benefits regarding latency and security, it is not a must but a surplus to have.
View our quick guide on how to update on Linux and FreeBSD here.
As of March 21, 2018, TLS 1.3 has arrived as the new standard in encryption protocol for websites. It’s been eight years since TLS has been updated (TLS 1.2 / 2010), and the new 1.3 version offers enhanced security and performance. Increased speed for encrypted connections stems from features such as Zero Round Trip Time (0-RTT) and TLS false start. We advise you not to use TLSv1.0 and TLSv1.1 as they are outdated protocols.
Change (add) the following to the file:
ssl_protocols TLSv1.2 TLSv1.3;
note: You should remain the use of TLSv.1.2 due compatibility since not all browsers support TLSv1.3 yet, same goes for nginx which only supports TLSv1.3 after version 1.13.0
The definition of a cipher suite is basically a complete set of methods (technically known as algorithms) needed to secure a network connection through SSL (Secure Sockets Layer) / TLS (Transport Layer Security). The name of each set is representative of the specific algorithms comprising it. Cipher suites are used in network connections secured by SSL/TLS. Before a client application and a server can exchange data over a SSL/TLS connection, these two parties need to agree first on a common set of algorithms to secure the connection. If the two parties fail to reach an agreement, then a connection won’t be established.
recommended TLSv1.3 suite:
These are outdated ciphers or had issues/attacks in the past and shouldn’t be used:
The fastest cipher is (or better said was) RC4, but since recent attacks it made the cipher unsafe. The next following in-line is AES-128 @ avg 97Mb-178Mb/s depending on resources. It is worth mentioning that on some of the newer Intel processors, there are AES-specific instructions, which will make AES faster than RC4 on those systems.
The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The recommendation above prioritizes algorithms that provide perfect forward secrecy. Older versions of OpenSSL may not return the full list of algorithms. AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Ubuntu or RHEL.
- ECDHE+AESGCM ciphers are selected first. These are TLS 1.2 ciphers. No known attack currently target these ciphers.
- PFS ciphersuites are preferred, with ECDHE first, then DHE.
- AES 128 is preferred over AES 256. There has been discussions on whether AES256 extra security was worth the cost , and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and more resistant to time attacks.
Online Certificate Status Protocol (OCSP) was created as an alternative to the Certificate Revocation List (CRL) protocol. Both protocols are used to check whether an SSL Certificate has been revoked. OCSP stapling can be used to enhance the OCSP protocol by letting the webhosting site be more proactive in improving the client (browsing) experience. OCSP stapling allows the certificate presenter (i.e. web server) to query the OCSP responder directly and then cache the response. This securely cached response is then delivered with the TLS/SSL handshake via the Certificate Status Request extension response, ensuring that the browser gets the same response performance for the certificate status as it does for the website content.
OCSP stapling addresses a privacy concern with OCSP because the CA no longer receives the revocation requests directly from the client (browser). OCSP stapling also addresses concerns about OCSP SSL negotiation delays by removing the need for a separate network connection to a CA’s responders.
Enable OCSP by adding the following: (only supported on nginx 1.3.7+)
resolver 188.8.131.52 184.108.40.206 valid=300s;
HTTP Strict Transport Security (often abbreviated as HSTS) is a security feature that lets a web site tell browsers that it should only be communicated with using HTTPS, instead of using HTTP. The following was quoted by “Mozilla Developer Network“:
“If a web site accepts a connection through HTTP and redirects to HTTPS, the user in this case may initially talk to the non-encrypted version of the site before being redirected, if, for example, the user types http://www.foo.com/ or even just foo.com.
This opens up the potential for a man-in-the-middle attack, where the redirect could be exploited to direct a user to a malicious site instead of the secure version of the original page.
The HTTP Strict Transport Security feature lets a web site inform the browser that it should never load the site using HTTP, and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.”
- Any attempts by visitors to use the unsecured version (HTTP://) of a page on your site will be automatically forwarded to the secure version (HTTPS://).
- Old HTTP bookmarks and people typing the HTTP version of your site are open you up to man-in-the-middle attacks. These are attacks where the attacker alters communication between parties and tricks them into thinking they are still communicating with each other.
- Doesn’t allow for the overriding of the invalid certificate message.
- Cookie hijacking: This can occur when someone steals a session cookie over an unsecured connection. Cookies can contain all sorts of valuable information such as credit card information, names, addresses, etc.
Add this config to enable HTST:
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload; always";
Additional: There is also HSTS preloading. This is basically getting your website and or domain on an approved HSTS list that is actually built into the browser. Google officially compiles this list and it is utilized by Chrome, Firefox, Opera, Safari, IE11, and Edge.
Submit your site to the official HSTS preload list.
Other SSL Directives
- Specifies a time during which a client may reuse the session parameters.
- a cache shared between all worker processes. The cache size is specified in bytes; one megabyte can store about 4000 sessions. Each shared cache should have an arbitrary name. A cache with the same name can be used in several virtual servers.
- Some OpenSSL implementations don’t provide a default for nginx to inherit, so it becomes a good idea to specify this manually. X25519 is considered a more secure elliptic curve, but less compatible. Try what’s best.
- The Nginx ssl_buffer_size config option sets the size of the buffer used for sending data via HTTPS. Default value is 16k, but is way over-sized. 4k or 8k should be more then sufficient. Try to find what’s best for your connection.
- By default, Nginx will use the default DHE (Ephemeral Diffie-Hellman) paramaters provided by openssl. This uses a weak key that gets lower scores. The best thing to do is build your own. First, you need to build the file. I’m going to assume you keep SSL files in /etc/nginx/ssl. If this is not the case, change the path or create a dictionary under /etc/nginx/(ssl)
Execute the follow command in your kernel:
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
For best performance/security we recommend 2048 bit or 4096 bit key. In general, the higher the key, the better the security and the lower the performance.
add_header Referrer-Policy "no-referrer, strict-origin-when-cross-origin";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
- The Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests.
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a frame, iframe, embed or object. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
The X-Content-Type-Options header is used to protect against MIME sniffing vulnerabilities. These vulnerabilities can occur when a website allows users to upload content to a website however the user disguises a particular file type as something else.
The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.
- Enables TLS session tickets, allowing for the client to reconnect faster, skipping renegotiation. Should be
- . Why? Because proper rotation of session ticket encryption key is not implemented in Nginx or Apache. Thus it is easier to recommend against its use then suggest the use of 3rd party software to fix it.