More and Shorter Certificates with a Lower Lifetime: Where Is TLS Going to?

These are turbulent times for cryptography. Although the ordinary user does not perceive it, the world of encrypted and authenticated websites (although this does not make them safe) is going through a deep renewal of everything established. Something in principle as immutable as cryptography is going through a strange moment and we don’t know how it will end. Of course, what is certain is that we must modify our traditional beliefs about how the web works. Let’s review some recent events that will turn everything upside down.

Apple and Its Increasingly Shorter Certificates

Browsers have been steering the course of the Internet and, in particular, cryptography. Chrome has long been in a relentless fight to do away with HTTP and try to make everything HTTPS. It has been with the “increasingly” strategy for years, flagging as insecure those webpages that do not have encryption and authentication and, in turn, raising the security standard of those that do. For instance, setting aside certificates that use SHA1. First on the sheet, in the middle, etc.

But this time, curiously, it was not Chrome but Apple with Safari the one which has decided to shorten the lifetime of the certificates to a year. This has been discussed and voted several times by the agents involved. The browsers wanted it to be a maximum of one year, the CAs did not. Now Safari says it will flag certificates of more than one year from September 2020 as invalid.

The main agents of the Internet and the CAs voted in September 2019 if the lifetime of the TLS / SSL certificates should be reduced (even more), forcing them to have a maximum lifetime. The result was (again) no. 35% voted for the reduction, including Google, Cisco, Apple, Microsoft, Mozilla, Opera and Qihoo360. The rest, particularly the CAs, voted against, so we officially continue with the maximum certificates’ lifetime of 825 days.

However, in February, at the CA/B Forum in Bratislava, Apple announced that its maximum will be 398 days. Just like that, without notice or statements about it. From September 1, it will flag as distrusted the certificates created from that date and whose lifetime is more than 398 days. Will this sweep the other browsers along? The whole industry? Safari, thanks to iPhone, has 18% of the market, so it has enough popularity to push it. In our view, it is a way of taking the pulse of their own leadership.

Facebook and Its Ephemeral Certificates

There are essentially three technologies that browsers can implement to check the revocation status of a digital certificate:

• The downloadable revocation blacklist known as Certificate Revocation List (CRL), defined in RFC 5280. History has shown that it does not work.
• OCSP, defined in RFC 6960. OCSP works with a request-response mechanism that requests information about a specific certificate from the CA. The most effective so far (without really being it) is the OCSP Staple required variant, but it is not widely used.
• CRLSets: it is a “fast” revocation method used only in Chrome, as it is said, for “emergency situations”. They are a set of certificates that gather information from other CRLs, are downloaded from a server and are processed by Chrome. Although the method is fully transparent, the management of which certificates are on the list is completely opaque and the certificates used to update it are not known (unless it may be found by other means).

As none of this works as it should, the ‘delegated credentials’ are born. They mean shortening to a few hours the certificates’ lifetime, but not exactly, although they play with the concept of the ephemeral to tackle the problem. What a server will do is sign with its certificate small data structures valid for days or hours and delegate them to the servers that will actually manage the TLS with the browser. That is, instead of creating shorter certificates signed by the intermediate CA and deploying them, they are simplified into a kind of ‘mini-certificates’ signed by the leaf certificate.

With the leaf certificate’s private key, we leave behind all the complexity of the intermediate and root CAs. The system would delegate this delegated credential to the front-end servers and, if the browser supports it, the system would verify it rather than the ‘traditional’ certificate. If the delegated credential is signed by the leaf certificate (it has the public key to verify it), then the public key in the delegated credential itself is used for the TLS connection and not the certificate’s public one.

This is the key: there is a much more dynamic formula in case of revocation that would not depend on any CA and that would be very quick to deploy (as soon as the delegated credentials expired, attackers looked for others and could not sign them). In addition, it is not necessary to leave the private key on all servers or intermediate proxies. A single server could serve all credentials delegated to web servers, balancers, etc.

Let’s Encrypt and Its Large Certificates

Let’s Encrypt broke off the engagement and offered free certificates that may be issued automatically. Their philosophy was to go towards ‘HTTPS everywhere’ and not have to pay for it. Their first certificate was born in September 2015. In June 2017 they had issued 100 million certificates and on February 27 they reached a billion certificates.

That’s a lot of certificates and means a clear success of the company involved, but also a little problem for other projects such as Certificate Transparency. While it cannot be used for revocation, it does allow all certificates (fraudulent or not) to be registered and, therefore, it is easier to detect the fraudulent ones and then revoke them by the “usual” methods.

Certificate Transparency was already born with a privacy issue, and delayed its enforceability for several reasons: implementations that were not achieved, headers that were adopted with very little room, RFCs that were starting too tight, and so on. Even so, Certificate Transparency is in good health (or at least not as bad as HPKP), but Google has been overly ambitious with the proposal. Bringing together so many actors is complicated, even more so in such a critical environment as TLS security. Moreover, it now faces an insane growth that may complicate infrastructure.

Some Certificate Transparency logs are close to one billion certificates. To better manage this system that aims to cover everything and be ‘read only’, they ended up creating logs for years. The certificates that expire within those years get into different log servers that later (normally) will no longer receive certificates.

But if we take, for example, Google Argon 2019 servers (already almost stable at 850 million certificates throughout 2019) and compare it with Argon 2020, we see that the latter has 400 million in just two months, almost half of the former. At this rate, it would reach 2400 million certificates (if not more) thanks precisely to the growth of Let’s Encrypt and the policy of increasingly shorter certificates.

How will all this fit into the future TLS ecosystem? We will see it little by little.