Delegated Credentials for TLS is a new simplified way to implement "short-lived" certificates without sacrificing the reliability of secure connections.
In short, the new TLS protocol extension aims to effectively prevent the misuse of stolen certificates by reducing their maximum validity period to a very short span of time, such as a few days or even hours.
Before jumping into how Delegated Credentials for TLS works, you need to understand the current TLS infrastructure, and of course, about the core problem in it because of which we need Delegated Credentials for TLS.
The Current TLS Infrastructure
More than 70% of all websites on the Internet today use TLS certificates to establish a secure line of HTTPS communication between their servers and visitors, ensuring the confidentiality and integrity of every bit and byte of data being exchanged.
Websites obtain a TLS certificate from a Certificate Authority (CA) that must be trusted by all major web browsers. CA organization digitally signs a certificate that remains only valid for a specific period, typically for a year or two.
When you connect to an HTTPS-protected website, the server provides its TLS certificate to your web browser for confirming its identity before exchanging any information that could include your passwords and other sensitive data.
Ideally, certificates are expected to be used for their entire validity period, but unfortunately, a certificate can go bad before its expiration date for many reasons.
For example, the secret private key corresponding to a certificate can be stolen, or the certificate can be issued fraudulently, allowing an attacker to impersonate a targeted server or spy on encrypted connections through a man-in-the-middle attack.
Moreover, big tech companies like Facebook, Google, and Cloudflare offer their services from thousands of servers implemented worldwide. They distribute private certificate keys to each one of them, a process where the risk of compromise is higher than usual.
Problem: Why We Need Delegated Credentials For TLS?
If a certificate gets compromised before its expiration date, the only option a website operator currently has is to request the certificate authority to revoke the stolen certificate and reissue a new one with a different private key.
However, unfortunately, the current revocation mechanisms are also broken in practice.
Ideally, browsers should be able to promptly detect no-longer-trusted certificates to proactively prevent their users from further connecting to a compromised server until it gets back online with a new valid certificate.
But since frequently querying a CA server imposes a massive performance penalty on the web traffic, modern browsers either use cached validation status of a certificate for some time or assume that it is still valid in case the browser doesn't receive a response from the CA on time or encounter any connection error.
That means that an attacker can launch cyberattacks against a targeted website only in the time frame between the revocation of its stolen certificate and when the browsers learn about it and block it.
In an attempt to further reduce this sensitive time frame, some companies have started experimenting with certificates with a shorter validation period, after which browsers itself reject them instead of waiting for the revocation signal.
Facebook is also among those companies that use this approach, as the company explains:
"The shorter the certificate lifetime, the less likely a certificate will need to be revoked before it expires. We have shortened the validity lifetime of our certificates from the current industry standard of one year to just a few months."
"This boosts our security by reducing the period during which a potential attacker could use a compromised certificate."
However, since CA is a separate organization and a website server would need to fetch new certificates from them much more frequently, there is no reliable way available for the companies to continuously rotate certificates after every few hours or days.
"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," Firefox warned.
"To mitigate this risk, services like ours [Facebook] generally opt for longer expiration time, so there is time to recover from any failures," Facebook said.
Solution: How Does 'Delegated Credentials for TLS' Work?
Finally, let's talk about the solution.
To solve the issues mentioned above, IETF community members have now proposed Delegated Credentials for TLS, a new cryptographic protocol that balances the trade-off between lifetime and reliability.
Delegated Credentials for TLS allows companies to take partial control over the process of signing new certificates for themselves—with a validity period of no longer than 7 days and without entirely relying on the certificate authority.
"Delegated Credentials permit holders of specially-enrolled certificates to use those certs as a kind of sub-sub-CA to construct sub-certificates whose authority is delegated by the actual end-entity cert," said J.C. Jones, cryptography engineering lead at Mozilla.
"These delegated certificates are particularly useful when needing to act on behalf of the end-entity in lower-trust environments, like those sometimes found in CDN edge networks."
In layman's terms, a company can obtain a signed "leaf certificate" from its certificate authority, using which it can then generate and sign a delegated credential with an expiration time as little as a few hours.
On the client-side, browsers and software supporting the new protocol would use the public key of the short-lived delegated credential of a website to establish a secure TLS connection with its server.
So instead of deploying the actual private key associated with the certificate to all servers, companies can now internally create, deploy, and issue delegated credentials.
"It is much easier for a service to create delegated credential than a certificate signed by a CA," IETF draft says.
"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," Facebook said.
Let's wrap it up:
When you connect to a website with a browser that supports delegated credentials, then instead of using the regular TLS certificate, the server provides a short-lived token to your browser for authentication, which satisfies the chain of trust because delegated credentials are still signed by the certificate obtained from the CA.
"Since the delegated credential has its own public key, a server can also experiment with new public key algorithms for TLS (including Ed25519 public keys) even before CAs support it," Facebook said.
"A fresh delegated credential can be created and pushed out to TLS servers long before the previous credential expires. Momentary blips in availability will not lead to broken handshakes for clients that support delegated credentials," Cloudflare said.
Support for Delegated Credentials
Facebook has already added support for Delegated Credentials in Fizz library, its open source implementation of TLS 1.3 designed for performance and security.
Google's open source fork of OpenSSL, BoringSSL, also supports Delegated Credentials for TLS protocol.
As one of the partners in standardizing the protocol, the Mozilla now supports Delegated Credentials in the latest version of Firefox web browser.
Though the feature is not enabled by default at this moment, users can turn it on by navigating to about:config → search for the "security.tls.enable_delegated_credentials" preference → double click on it to set its value to true.
To test if your browser supports Delegated Credentials for TLS, you can visit the following sites:
- fbdelegatedcredentials.com ← By Facebook
- kc2kdm.com/delegated.html ← By Mozilla
