New Post has been published on TechLabs - Beyond Technology
New Post has been published on http://bit.ly/2lJMHnT
Optimizing HTTPS for speed and security on Nginx with Let's Encrypt
Until some years ago only financial, booking sites, or online webstore were we use our Creditcard and personal information stored use https for security reasons. They even can’t get CreditCard acception without a certificate.
Today we see that most of the sites use https to encrypt the information that passes the internet. A simple blog has https to protect the login and password.  There are some different types of certificates to protect a website, that depends on the kind of information that is on that site. There are free ones and the expensive ones that cost more that US500,00. If you are a bank you should buy an expensive certificate with insurance. If you have a blog, then you can use a free valid certificate, namely, Let’s Encrypt. Most Linux distributions have packages for it so is really easy to install. On Ubuntu you just install it like with apt-get.
sudo apt-get update sudo apt-get install letsencrypt
Most control panels have to option to select if you want to use a certificated or not. A connection with a site that uses https slows down the connection time a bit because it has to verify the validation of the certificate on the site. With the instructions below this time is reduced and we still keep a good security level for our site and gain a 150ms or more back again.
NOTE: All of the configuration directives explained here will be for your server block in your Nginx config.
1. Setting up OCSP stapling for Let’s Encrypt certificates under nginx
Thanks to a free certificate from Let’s Encrypt, this site is now accessible over SSL. Instead of using the official Let’s Encrypt client to obtain the certificate I used first used letsencrypt-nosudo. This client has a number of advantages: it doesn’t need to run as root, it doesn’t take over port 80 on your server, it doesn’t run continuously in the background, and it doesn’t touch your server configuration. But recently with a new server setup I used the apt-get manner. The only thing I missed from the official client was setting up OCSP stapling, which the official client will do but letsencrypt-nosudo won’t. Through some trial and error I figured out which certificates need to go where in order to get stapling working from nginx.
Figure out which of the Let’s Encrypt certificates was used to sign your certificate. From the command line, run the command
openssl x509 -noout -text -in ssl/signed.crt | grep Issuer:
replacing “ssl/signed.crt” with the path to the certificate you just obtained. (The OpenSSL command prints a bunch of somewhat-human-readable information about the certificate; the grep command extracts the line we care about.) The output will be something likeIssuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 That last bit (“Let’s Encrypt Authority X3”) is the name of the Let’s Encrypt certificate that was used to sign your new certificate. Note: Since the new apt-get install the Issuer: C=US, O=Let’s Encrypt, CN=Let’s Encrypt Authority X3
Download that certificate in PEM format.You need to download the PEM version of this certificate. You can find all of the Let’s Encrypt intermediate certificates on the Let’s Encrypt site; click on the “PEM” link for the appropriate certificate to get the file you need. Or, from the command line,
wget -O /etc/ssl/chain.pem "https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem"
replacing “x3” with a different certificate name if necessary.
Point Nginx to this file as the “trusted certificate”. In your nginx.conf file, add these directives to the same block that contains your other ssl directives:
ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/ssl/chain.pem; resolver 8.8.8.8 8.8.4.4;
You also need to provide one or more DNS servers for Nginx to use. Here I’m using Google’s public DNS servers, but you are free to use whichever works for you (if you don’t like Google or are worried about privacy, OpenDNS might be a good option for you). The resolvers are used in a round-robin fashion, so make sure all of them are good ones.
Make sure you verify your setup using
sudo nginx -t
If the test is successful, restart Nginx
 sudo nginx -s reload
and you should be up and running with OCSP stapling!
2. Connection credentials caching
Almost all of the overhead with SSL/TLS is during the initial connection setup, so by caching the connection parameters for the session, will drastically improve subsequent requests (or in the case of SPDY, requests after the connection have closed – like a new page load).
All we need is these two lines:
ssl_session_cache shared:SSL:20m; ssl_session_timeout 180m;
This will create a cache shared between all worker processes. The cache size is specified in bytes (in this example: 20 MB). According to the Nginx documentation can 1MB store about 4000 sessions, so for this example, we can store about 80.000 sessions, and we will store them for 180 minutes. If you expect more traffic, increase the cache size accordingly.
I usually don’t recommend lowering the ssl_session_timeout to below 10 minutes, but if your resources are sparse and your analytics tells you otherwise, go ahead. Nginx is supposedly smart enough to not use up all your RAM on session cache, even if you set this value too high, anyways.
3.Optimizing the cipher suites
The cipher suites are the hard core of SSL/TLS. This is where the encryption happens, and I will really not go into any of that here. All you need to know is that there are very secure suits, there are unsafe suites and if you thought browser compatibility issues were big on the front-end, this is a whole new ballgame. Researching what cipher suites to use, what not to use and in what order takes a huge amount of time to research. Luckily for you, I’ve done it.
First you need to configure Nginx to tell the client that we have a preferred order of available cipher suites:
ssl_prefer_server_ciphers on;
The most recent version of TLS is 1.2, but there are still modern browsers and libraries that use TLS 1.0. I left out the suport for TLS 1.0
So, we’ll add this line to our config then:
ssl_protocols TLSv1.1 TLSv1.2;
Next we have to provide the actual list of ciphers:
ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
All of these suites use forward secrecy, and the fast cipher AES is the preferred one. You’ll lose support for all versions of Internet Explorer on Windows XP. But that ancient OS, who cares?
4 .Generate DH parameters
Create the DH parameters file with 2048 bit long safe prime:
mkdir /etc/nginx/cert openssl dhparam 2048 -out /etc/nginx/cert/dhparam.pem
And add it to your Nginx config:
ssl_dhparam /etc/nginx/cert/dhparam.pem;
Note that Java 6 doesn’t support DHParams with primes longer than 1024 bit. If that really matters to you, something is a bit wrong somewhere.
5.Strict Transport Security
Even though you already should have made all regular HTTP requests redirect to HTTPS when you enabled SPDY, you do want to enable Strict Transport Security(STS or HSTS) to avoid having to do those redirects. STS is a nifty little feature enabled in modern browsers. All the server does is to set the response header Strict-Transport-Security with a max-age value.
If the browser have seen this header, it will not try to contact the server over regular HTTP again for the given time period. It will actually interpret all requests to this hostname as HTTPS, no matter what. You can even tell the browser to enable the same behavior on all subdomains. It will make MITM attacks with SSLstrip harder to do.
All you need is this little line in your config:
add_header Strict-Transport-Security "max-age=31536000" always;
The max-age is set in seconds. 31536000 seconds is equivalent to 365 days.
6.Wrap-up
I know how annoying it is to follow guides like this. You just want the config, right? Well, here it is:
user www-data; worker_processes auto; pid /run/nginx.pid; events worker_connections 1024; use epoll; multi_accept on; http { [...] ## # SSL Settings ## ssl_protocols TLSv1.1 TLSv1.2; # Dropping TLSv1 and SSLv3, ref: POODLE ssl_prefer_server_ciphers on; ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5; ssl_session_cache shared:SSL:20m; ssl_session_timeout 180m; ssl_dhparam /etc/nginx/cert/dhparam.pem; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/ssl/chain.pem; resolver 8.8.8.8 8.8.4.4; add_header Strict-Transport-Security "max-age=31536000" always; ## Detect when HTTPS is used map $scheme $fastcgi_https default off; https on; # Rest of your regular config goes here:         # [...]
That’s it.
