Nginx Tutorial #3: SSL Setup

Hello! Sharing is caring so we'd love to share another piece of knowledge with you. We prepared three-part series with the Nginx tutorial. If you already know something about Nginx or you'd just like to expand your experience and understanding - this is the perfect place for you!

We will tell you how Nginx works, what concepts are behind it, how could you optimize it to boost up your app's performance or how to set it up to have it up and running.

This tutorial will have three parts:

Basics concepts- where you get to know the difference between directive and context, inheritance model, and the order in which Nginx pick server blocks, and locations.

Performance- tips and tricks to improve speed. We will discuss here gzip, caching, buffers, and timeouts.

We aimed to create a series in which you can easily find the proper configuration for a particular topic (like gzip, SSL, etc.), or simply read it all through. For the best learning experience, we suggest to set Nginx up on your own machine and try some practice.

SSL and TLS

SSL (standing for Socket Secure Layer) is a protocol providing a secure connection over HTTP.

SSL 1.0 was developed by Netscape, and never publicly released due to serious security flaws. SSL 2.0 was released in 1995, with some issues, which lead to final SSL 3.0, released in 1996.

The first version of TLS (Transport Layer Security) was written as an upgrade to SSL 3.0. Then TLS 1.1, and 1.2 came out. Right now, just behind the door, there is TLS 1.3 coming soon (which is truly something worth waiting for) and is supported already by some browsers.

Technically SSL and TLS are different (as each is describing the different version of a protocol) - but many use those names interchangeably.

Base SSL/TLS setup

In order to handle HTTPS traffic, you need to have SSL/TLS certificate in place. You can check appendix to generate free certificate via Let’s encrypt.

When you have the certificate in place, you can simply turn HTTPS by:

start listening on a port 443 (default port that browsers will use when you type https://sample.co)

TLS Session Resumption

Using HTTPS, imposes TLS handshake, on top of TCP one. This increase significantly time, before actual data transfer is made. Assuming that you are requesting /image.jpg from Warsaw, and connecting to the nearest server in Berlin:

To save one roundtrip during TLS handshake, and computational cost of generating a new key, we could reuse session parameters generated during the first request. Client and the server could store session parameters behind the Session ID key. During the next TLS handshake, the client can send the Session ID, and if the server will still have a proper entry in cache - parameters generated during the previous session will be reused.

server {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;
}

OCSP Stapling

SSL certificate can be revoked at any time. Browsers, in order to know if given certificate is no longer valid, need to perform an additional query via Online Certificate Status Protocol (OCSP). Instead of requiring users to perform given OCSP query, we could do it on the server, cache the result, and serve OCSP response to our clients, during TLS handshake. It is called OCSP stapling.

Summary

Thank You for reading. This series could not be possible without plenty of resources found in the depths of the internet. Here are few great websites we found especially useful, during writing this series:

We would be grateful for your feedback and comments, so feel free to discuss! Did you like this series? Do you have some suggestions what topic should be tackled next? Or maybe did you spot a bug? Let us know and see you next time!