Here’s what you need to know about delegated credentials and how they’ll affect your certificate management
Facebook, Mozilla, and Cloudflare just announced the development of delegated credentials, a new cryptographic protocol that’s expected to bolster the TLS security of multi-server websites and websites operating through Content Delivery Networks (CDN).
After three years of combined efforts by these tech giants, this new protocol is on the path to becoming an internet standard. Currently, it’s undergoing standardization at the Internet Engineering Task Force (IETF), the international body responsible for defining internet standards. And soon, it could become an internet standard.
Delegated credentials is an extension to SSL/TLS certificates, which are installed on web servers and are responsible for encrypted connections between web browsers and web servers. Before we get to the ins and outs of delegated credentials, let’s first understand why it’s been created in the first place.
Let’s hash it out.
The Security Problem Facebook & Cloudflare Are Facing
The reason why Facebook & Cloudflare teamed up on this is because they’re facing a common problem: SSL/TLS security on multiple web servers. Platforms such as Facebook and Cloudflare are used by hundreds of millions of people around the world. And therefore, they need to set up hundreds of servers across the globe to serve their customers.
Because Facebook or Cloudflare need to implement HTTPS connections on their platform, there’s no good option but to install a copy of their SSL/TLS certificate on each server. That also means that each of their servers will have the private key of their certificate. Now that’s quite a danger as hacking one web server and stealing the private key from it could allow a hacker to:
- run a man-in-the-middle (MitM) attack,
- imitate their web servers, and
- intercept all of their traffic.
Of course, it’s not as simple as it sounds, but it’s a possibility, and that’s why innovative solutions such as delegated credentials are valuable.
What Happens When a Certificate/Private Key is Compromised?
If an SSL/TLS certificate is compromised, the only option server operators have is to revoke the SSL/TLS certificate via the certificate authority (CA) that issued the certificate. To do so, they must contact the CA and ask them to revoke the certificate. In the process, they must prove their ownership. Once that is determined, the CA revokes the certificate. So far, it’s all good – your certificate was compromised and you got it revoked. But, there’s one major challenge remaining: How would your clients (web browsers) know about this revocation? What’s the point if the browsers don’t know about it, right?
Of course, there’s a solution — two, in fact. To communicate the revocation information to the browsers, two mechanisms are used: 1) Certificate Revocation List (CRL) and 2) Online Certificate Status Protocol (OCSP). We won’t go into the details, but they both come with significant pitfalls, and that’s why they’re hard to rely upon – especially when the data of millions of people is at stake.
In the worst case, there’s also a possibility of the CA having a lousy day and facing downtime. You know what this means, don’t you?
Another solution that some organizations promote is to shorten the validity period of SSL/TLS certificates.
It May Sound Good, But Shortening Certificate Lifespan Isn’t Practical
It’s quite evident that the time between the compromise and certificate revocation is the only time that a hacker has to execute a man-in-the-middle attack and intercept traffic (although a hacker could kind of bypass certificate revocation, but that’s a topic for another day). So, it makes sense to have certificates issued with a shorter lifespan of just hours or days. This way, because the certificate is renewed frequently, a hacker will have a very narrow window to execute the attack.
This might sound good on the surface, but it isn’t a practical solution — and here’s why.
SSL/TLS certificates are issued centrally by certificate authorities (CAs). This means that if you’ve got short duration certificates, you must issue certificates time and time again. This, of course, increases the possibility of failures. And you could be in a real jam if the certificate authority issuance process is offline for whatever reason. So, it’s clear that reducing the certificate lifespan isn’t a solution that we can implement in the real world.
How the TLS Delegated Credentials Extension Solves the Problem
The TLS delegated credentials extension solves this problem by using private keys with a shorter lifespan than your actual (leaf) certificate. These private keys are called delegated credentials and are generated by the web server, not the certificate authority (CA). This delegated credential structure consists of:
- the public key,
- the expiration date of delegated credentials (the new private key), and
- the signature of delegated credentials signed by the server’s leaf certificate.
Because the delegated credential has its own public key, it can be used to establish secure connections with web browsers. And the leaf certificate (a separate certificate issued by the publicly trusted certificate authority) signs the credentials so that they are trusted.
This way, by delegating the issuing process, we can achieve what we want — shorter private key expiration time. In other words, site owners don’t need to contact their certificate authority (CA) to issue certificates time and again. However, the leaf certificate — issued by a certificate authority — must sign the delegated credentials for browsers to consider it legitimate.
This also means that site owners don’t need to put their real private key on each of their servers. They can issue a distinct private key (with a much shorter lifespan) to each of their servers. So, even if the private key (delegated credentials) of one web server gets compromised, it won’t affect others, and a hacker will have a much shorter (and smaller) window of opportunity.
Greater Flexibility to Experiment with More Advanced Encryption Algorithms
Right now, the public key infrastructure (PKI) that we all use supports a limited set of algorithms to encrypt the information as it is limited by the algorithms that certificate authorities (CAs) support. However, with delegated credentials in place, the server operators have the flexibility to experiment with newer and more advanced algorithms since the server also computes and signs the keys. For example, delegated credentials could work as a bridge for the public key infrastructure to transition into post-quantum cryptography.
You Can Try Delegated Credentials Yourself
Facebook has already implemented delegated credentials in Fizz, its open-source implementation of TLS 1.3. You can try it by implementing the following steps:
- Download the latest version of Mozilla Firefox.
- Type about:config in the address bar and go to security.tls.enable_delegated_credentials.
- Now change its default value to true (you need to double-click on false).
- Go to this website.
Once you complete all the steps, you should see this in your browser window:
A Final Word
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. Since a good percentage of users browse through older browsers, it will take time for the web to fully benefit from this innovation.
Having said that, the introduction of delegated credentials is undoubtedly a step forward as far as security and privacy are concerned. It reduces the possibility of issues such as Heartbleed. Although it’s mainly for the likes of multi-server websites and CDNs, it’s going to add an additional safeguard to privacy for millions of end users. (If you have a website that runs on a single server, it’s not going to have many benefits since implementing it could be a hassle and your certificate private key would still be stored on the same server as the delegated credential anyhow.)
As always, leave any comments or questions below…