Use LetsEncrypt to Enable HTTPS on your Web Server for Free

LetsEncrypt offers free SSL certificates for websites, allowing you to protect users who access your site.

This guide will go step by step moving an unencrypted HTTP website to using HTTPS on Nginx. For the purpose of this guide, I’ll be using the website guide.highguard.net. There is no content there.

Lets start with the site in nginx.

server {
server_name guide.highguard.net;
listen 80;
listen [::]:80;
root /var/www/guide;
index index.html;
access_log off;
error_log off;
location /favicon.ico {
log_not_found off;
access_log off;
}
location ~ /\.ht {
deny all;
}
}

Right now the URL guide.highguard.net will show whatever is located at /var/www/guide/index/html on the server. To enable HTTPS we will need to get a certificate from LetsEncrypt using CertBot, then set up the site to use it and also redirect HTTP requests to use HTTPS in an intelligent manner. Lets start with getting the certificate.

Install Certbot with apt install python-certbot python-certbot-nginx, if you are using a distribution other than Debian, the package may have a different name or might not be available. The binary can be downloaded from the EFF.

Use Certbot to automatically create a challenge, request the certificate, download it, and install it.

certbot --nginx certonly

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: guide.highguard.net
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for guide.highguard.net
Generating key (1024 bits): /var/lib/letsencrypt/snakeoil/0000_key.pem
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0015_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0015_csr-certbot.pem

The certificate is generated and dropped into /etc/letsencrypt/live/guide.highguard.net/. Now we can make changes to the config file for the site to take advantage of the certificate. The easiest way to do that is to change the top of the server block so that it will use SSL, then add a new server block that uses non-SSL to redirect unencrypted connections to HTTPS.

The new server block:

server {
server_name guide.highguard.net;
listen 80;
listen [::]:80;
return 301 https://$host$request_uri;
access_log off;
log_not_found_off;
}

Then put the old server block right below that with minor changes. Change the listen ports from 80 to 443 ssl and add the path to the cert.

server {
server_name guide.highguard.net;
listen 443 ssl;
listen [::] 443 ssl;
ssl_certificate /etc/letsencrypt/live/guide.highguard.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/guide.highguard.net/privkey.pem;
root /var/www/guide;
index index.html;
access_log off;
error_log off;
location /favicon.ico {
log_not_found off;
access_log off;
}
location ~ /\.ht {
deny all;
}
}

Google and Mozilla are pushing for HTTPS to be everywhere

If your default browser is Firefox or Chrome you have have notice recently that both browsers are starting to take a harder stance on insecure login pages.

Whenever inputting text to a field, or when on a login page not secured with HTTPS, both Firefox and Chrome have their own ways of notifying users that the data they are sending, such as passwords or credit card numbers could be intercepted by someone bad.

Chrome is showing “Not secure” next to the URL bar and Firefox puts a banner under the password field of text boxes.

Firefox:

Chrome:

Users on twitter are seeing these notifications and taking it up with the companies that run the sites.

https://twitter.com/search?q=%22log%20in%22%20%22not%20secure%22&src=typd

https://twitter.com/search?q=%22log%20in%22%20%22not%20secure%22&src=typd

Annoying Web Scanners with Zip Bombs

This one can be filed squarely under “so dumb it works”. This practice wont really do much to increase practical security of a website, but it does create roadblocks for the guys running the tools that look for holes in your security.

Zip Bombs are really large files that are basically empty, so that when you zip the file up it becomes way smaller. For example, 42.zip is a 4.3 GB file that when fully decompressed is 4.5 PB (petabytes) of data. Thats 4,718,592 GB of data. When vulnerability scanners come in contact with these files they download it and try to unzip it to see whats inside, but because of the huge size of the file they crash or hang and give up with an error.

Vulnerability scanners are kind of annoying because they clog up your logs and don’t actually contribute to your site being any more popular. If your site ever does become vulnerable you could get hacked because everyone and their brother is trying to get in. By looking in access logs, we can see patterns of what resources bots are requesting and what their user agents are. With a simple bit of scripting, we can deliver a zip bomb to the scanner instead of a legitimate resource, wasting their time and hopefully crashing their software.

Read more at Christian Haschek’s blog.