TLS is a vitally important encryption technology.
Ordinary people use the web every day, and well implemented TLS protects the sensitive data they transmit through the web from man-in-the-middle attacks. For example, I bought a few things from a website today. I would not be inputting my credit card data with confidence if I didn’t think the retailer had implemented TLS properly. And even if I’m doing something innocuous like checking Twitter or reading the news, I would not want to be doing that through cleartext. If a cyber attacker performs a man-in-the-middle attack on even my less sensitive data, they could acquire access to my phone or PC endpoint. In my opinion, there’s no such thing as too much encryption as long as it works.
It’s up to the developers and providers of websites and web apps to make sure that their TLS encryption works so smoothly that users don’t even notice it. Here’s what it takes. With harmony between the Certificate Authority, public key infrastructure, good certificate management, and well-designed web browsers, the web can be well encrypted with as little friction from the user’s end as possible.
In case you were wondering, here's what happens when TLS encryption doesn't work so smoothly - from the side of the enterprise.
Currently, existing TLS technology, such as typical implementations of TLS 1.2 and TLS 1.3, can work very well for websites and apps with moderate traffic. Depending on the type of validation the TLS certificate uses, it could have a lifespan of anywhere from a few months to twenty-six months.
Certificate management gets a lot more complicated when a website or web app gets many millions of hits per month. The most frequently used websites, such as Facebook, could possibly get a whopping billion hits per month! And if a cyber attacker maliciously acquires a certificate, they can have unauthorized access to lots of web traffic for months or even years.
TLS Delegated Credentials is a new technology that was developed to address the certificate management problems that super high traffic websites may have. Here’s an example. With current TLS technology, a really high traffic website like Facebook or Google has to place a copy of its TLS certificate private key on each of its thousands of web servers around the world in order to provide continuous HTTPS service. If a certificate is maliciously acquired by a cyber attacker, they could impersonate Facebook or Google servers for a few months to a couple of years. Given the very high amount of web traffic those sites generate, the impact of a man-in-the-middle attack could be immense and very expensive.
With the new TLS Delegated Credentials standard that Facebook, Mozilla, and Cloudflare announced on November 1, very high traffic sites can deploy TLS private keys that only last for a few hours through multi-server setups. Those types of websites can deploy Delegated Credentials for individual sessions instead of using their proper and riskier real TLS private keys.
Think of it this way. Real estate agents often use temporary realtor locks on the doors of the properties they’re selling, so they can show them to multiple prospective tenants per day by using a keypad code rather than having to carry the real physical keys for each property. If they sell a house or a condo apartment, they can remove the realtor lock and give the buyer the permanent physical key. A website that gets 100,000 hits per month could work just fine by giving each visitor the real TLS private key. But if a website gets 500 million hits per month, certificate management can get really complicated if real TLS private keys are used for each session. TLS Delegated Credentials were designed to be compatible with TLS 1.3 and future versions. Delegated Credentials can have a lifespan ranging from few hours to seven days and they can be rotated automatically once they expire, simplifying heavy traffic certificate management.
Here’s how Mozilla explained Delegated Credentials on their blog:
“Traditionally, end-entity certificates are long-lived, exhibiting lifetimes of more than one year. For server operators making use of Content Delivery Networks (CDNs) such as Cloudflare, this can be problematic because of the potential trust placed in CDNs regarding sensitive private key material. Of course, Cloudflare has architectural solutions for such key material but these add unwanted latency to connections and present with operational difficulties. To limit exposure, a short-lived certificate would be preferable for this setting. 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.
The Delegated Credentials mechanism decentralizes the problem by allowing a TLS server to issue short-lived authentication credentials (with a validity period of no longer than 7 days) that are cryptographically bound to a CA-issued certificate. These short-lived credentials then serve as the authentication keys in a regular TLS 1.3 connection between a Firefox client and a CDN edge server situated in a low-trust zone (where the risk of compromise might be higher than usual and perhaps go undetected). This way, performance isn’t hindered and the compromise window is limited.”
I’m really glad that Facebook, Mozilla, and Cloudflare collaborated to develop the new Delegated Credentials TLS technology. They obviously saw a need for how high traffic sites can implement continuous HTTPS service with better security.
Mozilla will soon test Delegated Credentials in Firefox Nightly with the TLS Delegated Credentials Experiment add-on, with beta support from Cloudflare’s backend. I’m really optimistic about this exciting new experiment!
Are you ready for delegated TLS?
Watch our "Worst Case Scenario of a TLS Certificate Outage"