Delegated Credentials: Facebook, Mozilla & Cloudflare’s New TLS Protocol Explained
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…
*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ authored by Jay Thakkar. Read the original post at: https://www.thesslstore.com/blog/delegated-credentials-facebook-mozilla-cloudflares-new-tls-protocol-explained/
