How to use SSL/TLS in Node.js

This article is reprinted from the WeChat public account "New Titanium Cloud Service", translated by Wei Jianmin. Please contact the New Titanium Cloud Service public account for reprinting this article.

In 2020, there is no reason not to use HTTPS on your website. Visitors expect it, Google uses it as a ranking factor, and browser makers are happy to call out sites that don’t use it. In this tutorial, I’ll walk you through a real-world example.

[[336316]]

Instructions on how to add a certificate generated by Let's Encrypt to an Express.js server. However, it is not enough to protect our websites and applications with HTTPS. We should also require an encrypted connection to the server we are communicating with. We will see that it is possible to activate the SSL / TLS layer, even if it is not enabled by default.

Note: If you’re looking for instructions on how to set up SSL with NGINX when configuring NGINX as a reverse proxy for a Node application, check out our quick tip “Configuring NGINX and SSL with Node.js”.

Let's start with a brief review of the current state of HTTPS.

1. HTTPS is everywhere

The HTTP/2 specification was published in May 2015 as RFC 7540, which means it is part of the standard. This is an important milestone. Now we can all upgrade our servers to use HTTP/2. One of the most important aspects is the backward compatibility with HTTP 1.1 and the negotiation mechanism to choose a different protocol. Although the standard does not specify mandatory encryption, no browser currently supports unencrypted HTTP/2. This gives HTTPS another boost. Finally, HTTPS is everywhere!

What does our stack actually look like? From the perspective of a website running in a browser (at the application level), we have to traverse the following layers to get to the IP level:

1. Client browser,

2.HTTP,

3.SSL/TLS,

4. TCP protocol,

5. Intellectual Property

HTTPS is nothing more than the HTTP protocol on top of SSL/TLS. Therefore, all HTTP rules still apply. What does this extra layer actually give us? There are many advantages: we have authentication by having keys and certificates; a certain type of privacy and confidentiality is ensured since the connection is encrypted in an asymmetrical way; and data integrity is also preserved since the transmitted data cannot be altered in transit.

One of the most common myths is that using SSL/TLS is computationally intensive and slows down your server. This is certainly no longer true. We also don’t need any specialized hardware with cryptographic units. Even for Google, the SSL/TLS layer accounts for less than 1% of the CPU load, and the network overhead for HTTPS compared to HTTP is less than 2%. All in all, it doesn’t make sense to give up HTTPS just to save some overhead.

The latest version is TLS 1.3. TLS is the successor to SSL and is available in the latest version, SSL 3.0. The change from SSL to TLS excludes interoperability, but the basic process remains the same. We have three different encryption channels. The first one is the public key infrastructure for certificate chains. The second one provides public key cryptography for key exchange. Finally, the third one is symmetric. Here we have cryptography for data transmission.

TLS 1.3 uses hashing for some important operations. In theory, any hashing algorithm can be used, but SHA2 or stronger is strongly recommended. SHA1 has long been the standard but has recently been deprecated.

HTTPS is also gaining more and more attention from customers. Privacy and security issues have always existed, but as the amount of data and services accessible online grows, people are becoming more concerned. For those websites that don't implement this feature, there is a useful browser extension - HTTPS Everywhere by EFF - that encrypts our communications with most websites.

The creators realized that many websites only partially offer HTTPS. This plugin allows us to rewrite requests for websites that only offer partial HTTPS support. Alternatively, we can also block HTTP completely (see the screenshot above).

2. Basic description

The verification process of a certificate includes verifying the certificate signature and validity period. We also need to verify that it chains to a trusted root. Finally, we need to check if it has been revoked. There are specialized trusted authorities in the world that issue certificates. If one of them is compromised, all other certificates from that authority will be revoked.

The sequence diagram of the HTTPS handshake is shown below. We start with the client initialization, followed by messages with certificate and key exchange. After the server sends the completed packet, the client can start the key exchange and cipher specification transmission. At this point, the client is finished. Finally, the server confirms the cipher specification selection and closes the handshake.

This entire sequence is triggered independently of HTTP. If we decide to use HTTPS, only the socket handling changes. The client is still making an HTTP request, but the socket will perform the handshake described earlier and encrypt the content (headers and body). So, what do we need to do to make SSL/TLS work with an Express.js server?

HTTPS

By default, Node.js serves content over HTTP. However, you must also use the HTTPS module in order to communicate with the client over a secure channel. This is a built-in module and the usage is very similar to how we use the HTTP module:

Ignore the /srv/www/keys/my-site-key.pem and and /srv/www/keys/chain.pem files for now. These are what we need to generate an SSL certificate, which we will do later. This is the Let’s Encrypt part. Before, we had to generate a private/public key pair, send it to a trusted authority, pay them and potentially wait a little while to get an SSL certificate. Nowadays, Let’s Encrypt generates and validates your certificates instantly and for free!

4. Generate Certificate

(1) Certbot

The TLS specification requires certificates, which are signed by a trusted Certificate Authority (CA). The CA ensures that the certificate holder is indeed who they claim to be. So basically, when you see a green lock icon (or any other green symbol to the left of the URL in your browser), it means that the server you are communicating with is indeed who it claims to be. If you are on facebook.com and you see a green lock, you can almost certainly be sure that you are indeed communicating with Facebook, and no one else can see your communication, or, for that matter, read it.

It's worth noting that this certificate doesn't necessarily have to be verified by an authority like Let's Encrypt. There are other paid services out there. You could technically sign it yourself, but (since you're not a trusted CA) users visiting your site would likely see a ton of scary warnings to get them back to safety.

In the following examples, we will use Certbot, which is used to generate and manage certificates with Let's Encrypt. On the Certbot website, you can find instructions on how to install Certbot for almost any OS/server combination. You should choose the option that works for you.

NGINX is a common combination for deploying Node applications on the latest LTS Ubuntu, and that’s what I’ll use here.

(2) Webroot

Webroot is a Certbot plugin that, in addition to the Certbot default functionality (which automatically generates your public/private key pair and generates an SSL certificate for it), copies the certificate to your webroot folder and verifies the server by placing some verification code into a hidden temporary directory called .well-known. In order to skip some of the steps that have to be done manually, we will use this plugin. This plugin is installed by default with Certbot. To generate and verify our certificate, we will run the following command: certbot certonly --webroot -w /var/www/example/ -d www.example.com -d example.com

You may have to run this command as sudo as it will attempt to write to /var/log/letsencrypt.

You will also be asked to provide your email address. It is best to enter a real address that you use regularly because you will be notified if the certificate is about to expire. The trade-off with Let’s Encrypt issuing a free certificate is that this certificate expires every three months. Luckily, renewal is as easy as running a simple command that we can assign to a cron job without having to worry about expiration. Additionally, renewing SSL certificates is a good security practice because it gives attackers less time to compromise the encryption. Sometimes, developers even set this cron to run every day, which is perfectly fine and even recommended.

Keep in mind that you must run this command on a server that the domain specified under the -d (for domain) flag resolves to (i.e. a production server). This won't work even if you have DNS resolution in your local hosts file because the domain will be verified from the outside. So if you do this locally, it will most likely fail unless you have opened a port from your local machine to the outside world and have that port running behind a domain name that resolves to your machine. This is a highly unlikely scenario.

Last but not least, after running this command, the output will contain the paths to the private key and certificate files. Copy these values ​​into the previous code snippet - into the key property of the certificate and the cert property of the key:

5. Thinking

(1) HTTP Strict Transport Security

Have you ever switched from HTTP to HTTPS on a website and there were some residual redirects still redirecting to HTTP? HTTP Strict Transport Security (HSTS) is a web security policy mechanism that mitigates protocol downgrade attacks and cookie hijacking.

HSTS effectively forces the client (browser accessing your server) to direct all traffic over HTTPS, it’s a “secure or not secure at all” mentality!

Express JS does not allow us to add this header by default, so we will use Helmet, a Node module that allows us to do this. Install helmet by running: npm install helmet Then, we just need to add it as a middleware in our Express server:

(2) Diffie-Hellman Strong(er) parameters

To skip some of the complicated math, let's cut to the chase. In very simple terms, there are two different keys used for encryption: the certificate you get from your certificate authority, and the certificate generated by your server for key exchange. The default key for key exchange (also known as Diffie-Hellman key exchange, or DH) uses a "smaller" key than the certificate's key. To get around this, we'll generate a strong DH key and give it to our secure server to use.

In order to generate longer keys (2048 bits), you will need openssl which is installed by default. If you are unsure, run openssl -v. If you can't find the command, install openssl by running sudo apt install openssl (or visit its download page here): openssl dhparam -out /var/www/example/sslcert/dh-strong.pem 2048

Then copy the path to the file into our configuration:

VI. Conclusion

In 2020 and beyond, there is no reason not to support HTTPS. The direction of the future is clear: HTTPS everywhere! In Node.js, we have many options for leveraging SSL/TLS. We can publish websites using HTTPS, we can create requests to encrypted websites, and we can authorize otherwise untrusted certificates.