Previously, certificates often expired due to the fact that they needed to be updated manually. People just forgot to do it. With the advent of Let’s Encrypt and the automatic update procedure, the problem seems to be solved. But recent Firefox history shows that it’s still relevant. Unfortunately, certificates continue to expire.

If someone missed this story, at midnight on May 4, 2019, almost all Firefox extensions suddenly stopped working.

As it turned out, a massive failure occurred due to the fact that Mozilla has expired certificate that was used to sign extensions. Therefore, they were marked as "invalid" and did not pass the test (technical details). On forums, it was recommended to disable the verification of extensions signatures in about: config or transfer of the system clock.

Mozilla promptly released the patch Firefox 66.0.4, which solves the problem with an invalid certificate, and all the extensions return to their normal form. The developers recommend installing it and not using any workarounds to bypass signature verification, because they may conflict with the patch.

Nevertheless, this story once again shows that the expiration of certificates remains an actual problem today.

In this regard, it is interesting to look at a rather original way of how the developers of the DNSCrypt protocol coped with this task. Their solution can be divided into two parts. Firstly, these are short-term certificates. Secondly, warning users about the expiration of the long-term.

DNSCrypt

DNSCrypt is a DNS traffic encryption protocol. It protects DNS communications from interceptions and MiTM, and also allows you to bypass blocking at the level of DNS queries.

The protocol wraps the DNS traffic between the client and the server into a cryptographic structure, working over UDP and TCP transport protocols. To use it, both the client and the DNS resolver must support DNSCrypt. For example, since March 2016, it has been enabled on its DNS servers and in the Yandex browser. Support was also announced by several other providers, including Google and Cloudflare. Unfortunately, there are not so many of them (152 public DNS servers are listed on the official website). But the dnscrypt-proxy program can be installed manually on clients running Linux, Windows and MacOS. There are server implementations.

How does DNSCrypt work? In short, the client takes the public key of the selected provider and uses it to verify its certificates. Already there are short-term public keys for the session and an identifier for the cipher suite. Clients are encouraged to generate a new key for each request, and for servers to change keys. every 24 hours. When exchanging keys, the X25519 algorithm is used, EdDSA is used for signing, and XSalsa20-Poly1305 or XChaCha20-Poly1305 is used for block encryption.

One of the developers of the protocol, Frank Denis, writes that an automatic replacement every 24 hours solved the problem of expired certificates. In principle, the dnscrypt-proxy reference client accepts certificates with any expiration date, but issues a warning “The dnscrypt-proxy key period for this server is too long” if it is valid for more than 24 hours. At the same time, the Docker image was released, which implemented a quick change of keys (and certificates).

First, it is extremely useful for security: if the server is compromised or the key is leaked, then yesterday's traffic cannot be decrypted. The key has already changed. Probably, this will be a problem for the execution of the “Law of Spring”, which forces providers to keep all traffic, including encrypted traffic. It is understood that later it will be possible to decrypt it if necessary, by requesting the key from the site. But in this case, the site simply can not provide it, because it uses short-term keys, deleting old ones.

But most importantly, Denis writes, short-term keys force servers to configure automation from day one. If the server connects to the network, and the key exchange scripts are not configured or do not work, it will be immediately detected.

When automation changes keys every few years, you cannot rely on it, and people can forget about the expiration of the certificate. With a daily change of keys, it will be detected instantly.

At the same time, if the automation is set up normally, then it does not matter how often the keys are changed: every year, every quarter or three times a day. If everything works for more than 24 hours, it will work forever, writes Frank Denis. According to him, recommending daily key changes in the second version of the protocol, along with a ready-made Docker method that implements this, effectively reduced the number of servers with expired certificates, while at the same time improving security.

However, some providers still decided for some technical reasons to establish the certificate validity period of more than 24 hours. This problem was mostly solved with a few lines of code in dnscrypt-proxy: users receive an informational warning 30 days before the certificate expires, another message with a higher severity level 7 days before the expiration date and a critical message if the certificate has less than 24 hours. This only applies to certificates that are initially long lasting.

Such messages provide users with the opportunity to inform DNS operators about the upcoming certificate expiration, before it is too late.

Perhaps, if all Firefox users received such a message, then someone would probably tell the developers and they would not allow the certificate to expire. “I don’t remember a single DNSCrypt server from the list of publicly available DNS servers that have expired in the last two or three years,” writes Frank Denis. In any case, it is probably better to warn users first, and not to disable extensions without warning.