Although Public Key Infrastructure (PKI) is securing our online transactions, it can be very fragile too. From fraudulent Certification Authorities (CAs) to implementation errors that expose private keys, managing machine identities securely can present technical challenges.
CAs are responsible for the creation of machine identities and they dictate the lifetime of an issued certificate. Traditionally, end-entity certificates are long-lived, with lifetimes of more than one year. For multi-server operators and Content Delivery Networks (CDNs) such as Cloudflare, this can be problematic because of the potential trust placed in sensitive private key material. To limit exposure, a short-lived certificate would be preferable. However, constant communication with an external CA to obtain short-lived certificates could result in poor performance or even worse, lack of access to a service entirely.
To address these challenges, Facebook, Cloudflare and Mozilla have been working together to develop an extension to the TLS protocol, called delegated credentials. Delegated credentials are an extremely effective method for securing certificates and this extension is in the process of being adopted as a standard by IETF.
The reason why Facebook, Cloudflare and Mozilla teamed up is that they are all facing a common problem: SSL/TLS security on multiple web servers. In modern server deployments, a certificate could be deployed to thousands of servers, which could be distributed all over the world. It is important to ensure the security of the certificate to prevent potential attackers from gaining control of a certificate, which would enable them to perform a man-in-the-middle (MITM) attack on traffic to the server.
If a certificate becomes compromised before it expires, the only option currently available to server operators is to revoke the certificate. However, certificate revocation does not work well for modern browsers. Revocation checking mechanisms such as Online Certificate Status Protocol (OCSP) may require browsers to speak to a certificate authority and can thus be blocked. They can also add latency to the establishment of the connection.
The other approach to minimizing the effects of certificate compromise is to reduce the validity of the certificates—this frees users from relying solely on revocation. The shorter the certificate lifetime, the less likely a certificate will need to be revoked before it expires. This boosts security by reducing the period during which a potential attacker could use a compromised certificate.
However, shortening certificate lifetimes is not always very practical. If we shorten the expiration time of a certificate, PKI teams will have to request and replace certificates from a CA much more frequently. If this process is not fully automated, it increases the possibility of failures. And you could be in real trouble if the certificate authority issuance process is offline for whatever reason. Reducing the certificate lifespan isn’t a solution that’s easy to implement in the real world.
Delegated credentials allow a server to better balance this trade-off between security and reliability. A web server can be configured to generate a new delegated credential structure containing a public key and an expiration time, which can be as little as a few hours. It can then use its signed certificate (also known as a leaf certificate) obtained from a CA to sign the delegated credential. Since this delegated credential is generated and signed by the web server, it is not required to contact the CA every time a new delegated credential needs to be created.
Figure 1: How delegated credentials work. Image courtesy of Facebook.
Clients would tell the server that they support delegated credentials and verify that the delegated credential is correctly signed by the server’s leaf certificate. The public key of the delegated credential is then used as the key for the TLS connection.
Delegated credentials provide greater flexibility to server operators. Operators can issue each of their servers a separate delegated credential with a short validity time, instead of the real certificate private key, to add defense in depth. Since the delegated credential has its own public key, a server can also experiment with new public key algorithms for TLS even before CAs support it. For example, delegated credentials could work as a bridge for the public key infrastructure to transition into post-quantum cryptography.
You can try it by implementing the following steps:
Once you complete all the steps, you should see this in your browser window:
Figure 2: A browser supporting delegated credentials. Image source: Hashed Out by The SSL Store
Even though the delegated credentials protocol is about to be adopted by the IETF, its full implementation will take time as it must be supported by all browsers, and users must be using updated browsers to take benefit from it. Since a good percentage of users browse through older browsers, it will take time for the web to fully benefit from this innovation. However, the introduction of delegated credentials is undoubtedly a step forward as far as security and privacy are concerned as it reduces the possibility of issues such as Heartbleed. Although delegated certificates are mostly useful for multi-server websites and CDNs, they are going to add an additional safeguard to privacy for millions of end-users.
How well are you managing your machine identities to protect your enterprise?