Innovate. Accelerate. Win.
September 18-19 | Las Vegas and Virtual
#MIMSummit2023 Join top security leaders looking to redefine what’s possible at the must-see industry event of 2023.
Websites such as Facebook and CloudFlare are used by billions of people around the world. To cater these users spread in different parts of the world, these websites must host their websites on multiple servers located in different parts of the world.
They might be having thousands of web servers, but they have only one website. Therefore, they must install copies of their SSL/TLS certificate on each of their servers—which can be catastrophic from the security viewpoint as an attacker could steal the private key and execute man-in-the-middle (MiTM) attack and intercept the traffic.
If such an attack takes place, there are two possibilities. The first is that the website administrator doesn’t get to know about it and the attacker has the hold of the server traffic till the certificate expiration date—which could take up to a year. The second possibility is that the website administrator does come to know about it and submits a certificate revocation request to their certificate authority (CA). The former is quite obvious in terms of the implications and the only thing that can help here is reducing the life-span of the certificates. While the latter might sound good on paper but its implementation has always been in question for a couple of reasons. And what if the CA is facing downtime and it’s not able to accept your revocation request? What if the browsers—operating through Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) protocols—get to know late about the revocation? These are serious challenges which need to be solved.
It’s quite obvious that the solution of these problems lies in shortening the life-span of digital certificates but, in that case, the website becomes reliant on the CA. If the CA isn’t able to issue new certificates due to downtime or any other reason, it could turn from a smart solution to a giant security problem. That’s why, shortening certificate life-span is not a full proof solution. We need a solution that reduces the validity of certificates, but doesn’t rely on the CA.
TLS Delegated Credentials: The proposed solution
TLS Delegated Credentials is aimed at thwarting attempts of misuse of stolen SSL/TLS certificates by reducing the life-span of certificates to a great extent. This, in turn, gives a very short time for an attacker even if they have managed to steal the certificate.
TLS Delegate Credentials allows websites to create short-lived TLS private keys known as ‘delegated credentials.’ Website administrators can deploy these private keys on their servers, instead deploying the main TLS private key. The life-span of these private keys could be as short as a few hours.
Website owners might be able to generate their own private key but the process isn’t entirely independent as they’ll have to get a leaf certificate issued from their certificate authority. Using this certificate, website owners can sign delegated credentials to make it legitimate and trusted by browsers.
Apart from the expiration date and the leaf certificate signature, delegated credentials consist of a public key. Using this public key, browsers can establish secure connection with the websites using delegated credentials.
This way, delegated credentials solve this problem by shortening the certificate life-span (without actually shortening it) and reduce complete reliance on certificate authorities. This gives quite short window for an attacker to misuse the stolen private key and they won’t be able to intercept data of all servers as all of them will be having different keys. This enhances the security of the original private key as website owners don’t need to install copies of private key on each of their servers.
Delegated credentials is a modern-day solution that could prevent giant-sized attacks on world’s biggest platforms such as Facebook and Cloudflare. That’s why, they’ve moved quite swiftly to enable support for it. Facebook has already enabled delegated credentials in its Fizz Library, Mozilla has added support for delegated credentials in Firefox Nightly and Google has also provided its support in BoringSSL.
Right now, this technology is under review at IETF but it won’t be a surprise if it becomes an internet standard soon. You can try delegated credentials by visiting the below sites in Firefox Nightly: