The next step in web app security

In short

To improve the security of your web services, ACME can be used to automate the requesting and instalment of server certificates on web servers. This allows you to let certificates have a shorter lifespan, reducing the dependency on Certificate Revocation Lists (CRLs) and thus improving on security.

Introduction

As the CIA triad (Confidentiality, Integrity, Availability) suggests, confidentiality of data is very important. Both data-at-rest and data-in-transit need to be kept confidential, and what better way to do this than to encrypt it.

In this article we’ll be going over confidentiality of data-in-transit for something that is becoming the standard for applications more and more, namely Web Applications.

TLS

Nowadays, most web apps encrypt the traffic between you and them, almost always done using TLS (Transport Layer Security – RFC8446). TLS, the successor of SSL (Secure Socket Layer – RFC6101), is a cryptographic protocol most notably known by the public to be used in HTTPS.

To enable traffic to be encrypted, keys are needed, just like you would need the key to open a lock someone else locked.

To put it briefly, without going too deep into the technical details, TLS uses a public-private key-pair to exchange these keys with an end-user connecting to, for example, a web app.

As the key exchange needs to happen securely as well, these public-private key-pairs usually come in the form of X.509 certificates and are commonly known as server certificates. These are certificates handed out by a trusted Certificate Authority (CA) and are valid for a certain period e.g. a few months or even years.

PKI

In Public Key Infrastructure (PKI) there are more entities than just the Certificate Authorities, such as registration authorities. For simplicity’s sake, let’s assume only a Certificate Authority is needed, besides the requester of a certificate.

Certificate Authorities usually consist of different layers of certificates, which then establish a “chain of trust” and can hand out certificates themselves.

The first layer is the root certificate; sometimes referred to as the root Certificate Authority (root CA). This one is usually only used to sign the layer following that, and is never used to hand out certificates to requesters of server certificates. The root certificates tend to have a very long lifespan, such as 10 years or more.

The following layer, signed by the root certificate, are intermediate certificates, sometimes referred to as intermediate Certificate Authorities (intermediate CAs). In some setups, there are multiple layers of these intermediate CAs, but for this example, assume there is only one, as illustrated below.

As you can see in the image above, the intermediate CA then hands out a certificate to the server, which it can use to encrypt data between itself and end-users.

To securely transfer data between a server and one single end-user, the end-user (usually done by your browser) encrypts a request to agree on a key with the server’s public key. Encrypting anything with a server’s public key means only the server’s private key can decrypt it.

Problems with traditional PKI

As you know by now, certificates have a limited lifespan and are handed out by a Certificate Authority, which on his turn also has a (longer) lifespan. These trusted root certificates are installed on your system, because your PC needs to know what it can trust and what not.

Say you’d want to revoke your certificate because there are signs your private key was compromised or when the domain you requested it for is no longer in use. You could request your certificate to be revoked, then the CA (certificate authority) will put it on it’s certificate revocation list (CRL).

A CRL is a list of certificates that have been revoked by their issuing CA (Certificate Authority) before their expiration date. These should no longer be trusted. Your PC knows certificates are revoked by checking this list. To save on network traffic and response speed, a cache is kept locally.

But what would happen if a certificate is on the CRL, but your PC doesn’t get an update in time?

You could (unknowingly) try to communicate with a compromised server for which your CRL has not been updated yet. This could mean an attacker could read your sensitive data!

But can you resolve this?

As you know by now, server certificates are valid for a set period of time. As an example, let’s take 1 year.

A standard Windows PC only updates its CRL cache every week.

Let’s take the worst case scenario, where a server private key is compromised right after your PC updates its CRL cache. This means you practically have a week where you could be communicating with a compromised server.

The resolution to this is fairly simple: Instead of using a certificate validity lifespan of 1 year, set it to a shorter lifespan, such as a single day.

You might think that’s absurd, replacing your server certificates daily would take up too much time! That’s true, if you were to do it manually, but what if you could automate this process?

Enter ACME

ACME, short for Automated Certificate Management Environment, is a protocol used for automating interactions between Certificate Authorities and owners of (web) servers.

The most famous implementation of an ACME certificate authority is Let’s Encrypt. Let’s Encrypt let’s you request free TLS certificates over the ACME protocol.

How does it work?

There are various ACME clients available today, such as Certbot (Python script), acme.sh (Bash script) or even a web server with built-in ACME client like Caddy.

These clients have a number of different “challenges”. These so-called challenges are the ways an ACME client can request a certificate from a ACME-enabled certificate authority.

These challenge types are:

• HTTP-01
• DNS-01
• TLS-SNI-01
• TLS-ALPN-01

HTTP-01 sets up a path on a web server on port 80/TCP on your server which the certificate authority can reach. The ACME client can either do this standalone, or it can interact with your running web server to put it on the right path/url. The ACME client then communicates this path to the certificate authority, who will then check the path to verify you are who you claim to be.

DNS-01 requires you to put a TXT-record on your DNS server, which the certificate authority can check to verify you are who you claim to be. This might seem annoying to do as well, but many DNS providers also provide an API to create and delete records. ACME clients have built-in support to interact with DNS servers through such an API to create and delete these TXT-records.

TLS-SNI-01 was defined in draft versions of ACME. It did a TLS handshake on port 443/TCP to the certificate authority and sent an SNI-header, hence the name. It was disabled in March 2019 because it was not secure enough. In practice you should never use this.

TLS-ALPN-01 is similar to TLS-SNI-01, in the way that it also performs TLS on port 443/TCP. The main difference is TLS-ALPN-01 uses a custom ALPN protocol to ensure only servers aware of this challenge type answer its requests. This challenge type is most suited for maintainers of TLS-terminating reverse proxies that want to perform host-based validation, but want to do it at the TLS layer. At the time of writing this blog, this is not supported by Apache, Nginx or Certbot. Caddy however already supports this challenge type.

Your ACME client will request certificates and install them on the right location. It can also be configured to restart your web server after the new certificate is installed to completely automate the process.

In a future where more and more servers are becoming stateless, requesting certificates automatically could improve its flexibility as well.

Do your web apps need more protection?

Do you want to know if your web apps are secure, or do you need help securing them? Do you want help implementing ACME into your environment? Reach out to us, we’re happy to help.

You can contact us through our contact form or LinkedIn.