In the past, certificates often expired due to the fact that they had to be renewed manually. People just forgot to do it. With the advent of Let's Encrypt and the automatic update procedure, it seems that the problem should be solved. But recent shows that in fact it is still relevant. Unfortunately, the certificates continue to expire.
In case anyone missed this story, at midnight on May 4, 2019, almost all Firefox extensions suddenly stopped working.
As it turned out, the massive failure arose due to the fact that Mozilla , which was used to sign extensions. Therefore, they were marked as "invalid" and did not pass the test (). As a workaround, the forums recommended disabling extension signature verification in about: config or by changing the system clock.
Mozilla promptly released the Firefox 66.0.4 patch, which fixes the invalid certificate issue, and all extensions return to normal. The developers recommend installing it and no workarounds to bypass signature verification because they might conflict with the patch.
However, this story once again shows that certificate expiration remains a pressing issue today.
In this regard, it is interesting to look at a rather original way how the protocol developers coped with this task. . Their solution can be divided into two parts. First, these are short-term certificates. Second, warning users about the expiration of 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 DNS traffic between the client and the server in a cryptographic construct, working over the 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. Several other providers have also announced support, including Google and Cloudflare. Unfortunately, there are not many of them (152 public DNS servers are listed on the official website). But the program can be installed manually on Linux, Windows and MacOS clients. There are also .
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 the identifier of the cipher suite. Clients are encouraged to generate a new key for each request, and servers are encouraged to change keys every 24 hours. When exchanging keys, the X25519 algorithm is used, for signing - EdDSA, for block encryption - XSalsa20-Poly1305 or XChaCha20-Poly1305.
One of the developers of the protocol, Frank Denis that automatic replacement every 24 hours solved the problem of expired certificates. In principle, the reference dnscrypt-proxy client accepts certificates with any validity period, but issues a warning "The period of dnscrypt-proxy keys for this server is too long" if it is valid for more than 24 hours. At the same time, a Docker image was released, in which they implemented a quick change of keys (and certificates).
Firstly, this 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 implementation of the Yarovaya law, which forces providers to store all traffic, including encrypted ones. It is understood that later it can be decrypted if necessary by requesting the key from the site. But in this case, the site simply cannot provide it, because it uses short-lived keys, deleting the old ones.
But most importantly, Denis writes, short-term keys force servers to set up automation from day one. If the server connects to the network and the key change scripts are not configured or not working, this will be detected immediately.
When automation changes keys every few years, it cannot be relied upon, and people can forget about the expiration of the certificate. With a daily key change, this will be detected instantly.
At the same time, if the automation is set up properly, 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, then it will work forever, writes Frank Denis. According to him, recommending a daily rekey in the second version of the protocol, along with a ready-made Docker image that implements this, effectively reduced the number of servers with expired certificates, while improving security.
However, some providers still decided, for some technical reason, to set the validity period of the certificate to more than 24 hours. This problem was mostly solved with a few lines of code in dnscrypt-proxy: users get an informational warning 30 days before the certificate expires, another message with a higher severity level 7 days before the expiration, and a crash message if the certificate has left less than 24 hours. This only applies to certificates that initially have a long validity period.
Such messages give users the opportunity to inform DNS operators of impending certificate expiration before it's too late.
Perhaps if all Firefox users received such a message, then someone would surely inform the developers and they would not allow the certificate to expire. "I don't remember a single DNSCrypt server on the list of public DNS servers that had its certificate expired in the last two or three years," writes Frank Denis. In any case, it's probably better to warn users first rather than disable extensions without warning.
Source: habr.com