Let\u2019s hash it out.<\/span><\/p>\n\n\n\n The reason why Facebook & Cloudflare\nteamed up on this is because they\u2019re facing a common problem: SSL\/TLS security\non multiple web servers. Platforms such as Facebook and Cloudflare are used by\nhundreds of millions of people around the world. And therefore, they need to\nset up hundreds of servers across the globe to serve their customers. <\/p>\n\n\n\n Because Facebook or Cloudflare need to\nimplement HTTPS connections on their platform, there’s no good option but to\ninstall a copy of their SSL\/TLS certificate on each server. That also means\nthat each of their servers will have the private key of their certificate. Now\nthat’s quite a danger as hacking one web server and stealing the private key\nfrom it could allow a hacker to: <\/p>\n\n\n\n Of course, it’s not as simple as it sounds,\nbut it\u2019s a possibility, and that’s why innovative solutions such as delegated credentials\nare valuable. <\/p>\n\n\n\n If an SSL\/TLS certificate is compromised,\nthe only option server operators have is to revoke the SSL\/TLS certificate via\nthe certificate authority (CA) that issued the certificate. To do so, they must\ncontact the CA and ask them to revoke the certificate. In the process, they\nmust prove their ownership. Once that is determined, the CA revokes the\ncertificate. So far, it’s all good \u2013 your certificate was compromised and you\ngot it revoked. But, there’s one major challenge remaining: How would your\nclients (web browsers) know about this revocation? What’s the point if the\nbrowsers don’t know about it, right? <\/p>\n\n\n\n Of course, there’s a solution \u2014 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<\/a> \u2013 especially when the data of millions of people is at stake. <\/p>\n\n\n\n In the worst case, there’s also a\npossibility of the CA having a lousy day and facing downtime. You know what\nthis means, don’t you?<\/p>\n\n\n\n Another solution that some organizations\npromote is to shorten the validity period of SSL\/TLS certificates. <\/p>\n\n\n\n It’s quite evident that the time between\nthe compromise and certificate revocation is the only time that a hacker has to\nexecute a man-in-the-middle attack and intercept traffic (although a hacker\ncould kind of bypass certificate revocation, but that’s a topic for another\nday). So, it makes sense to have certificates issued with a shorter lifespan of\njust hours or days. This way, because the certificate is renewed frequently, a\nhacker will have a very narrow window to execute the attack.<\/p>\n\n\n\n This might sound good on the surface, but\nit isn’t a practical solution \u2014 and here\u2019s why.<\/p>\n\n\n\n SSL\/TLS certificates are issued centrally\nby certificate authorities (CAs). This means that if you\u2019ve got short duration\ncertificates, you must issue certificates time and time again. This, of course,\nincreases the possibility of failures. And you could be in a real jam if the\ncertificate authority issuance process is offline for whatever reason. So, it’s\nclear that reducing the certificate lifespan isn’t a solution that we can\nimplement in the real world.<\/p>\n\n\n\n The TLS delegated credentials extension solves\nthis problem by using private keys with a shorter lifespan than your actual (leaf)\ncertificate. These private keys are called delegated credentials and are\ngenerated by the web server, not the certificate authority (CA). This delegated\ncredential structure consists of: <\/p>\n\n\n\n Because the delegated credential has its\nown public key, it can be used to establish secure connections with web\nbrowsers. And the leaf certificate (a separate certificate issued by the publicly\ntrusted certificate authority) signs the credentials so that they are trusted.<\/p>\n\n\n\n This way, by delegating the issuing\nprocess, we can achieve what we want \u2014 shorter private key expiration time. In\nother words, site owners don\u2019t need to contact their certificate authority (CA)\nto issue certificates time and again. However, the leaf certificate \u2014 issued by\na certificate authority \u2014 must sign the delegated credentials for browsers to\nconsider it legitimate.<\/p>\n\n\n\n This also means that site owners don’t need\nto put their real private key on each of their servers. They can issue a distinct\nprivate key (with a much shorter lifespan) to each of their servers. So, even\nif the private key (delegated credentials) of one web server gets compromised,\nit won’t affect others, and a hacker will have a much shorter (and smaller) window\nof opportunity.<\/p>\n\n\n\n Right now, the public key infrastructure\n(PKI) that we all use supports a limited set of algorithms to encrypt the\ninformation as it is limited by the algorithms that certificate authorities\n(CAs) support. However, with delegated credentials in place, the server operators\nhave the flexibility to experiment with newer and more advanced algorithms\nsince the server also computes and signs the keys. For example, delegated\ncredentials could work as a bridge for the public key infrastructure to\ntransition into post-quantum cryptography.<\/p>\n\n\n\n Facebook has already implemented delegated\ncredentials in Fizz, its open-source implementation of TLS 1.3. You can try it\nby implementing the following steps:<\/p>\n\n\n\n Once you complete all the steps, you should\nsee this in your browser window:<\/p>\n\n\n\n Even though the delegated credentials\nprotocol is about to be adopted by the IETF, its full implementation will take\ntime as it must be supported by all browsers, and users must be using updated\nbrowsers. Since a good percentage of users browse through older browsers, it\nwill take time for the web to fully benefit from this innovation.<\/p>\n\n\n\nThe Security Problem Facebook & Cloudflare Are Facing<\/h2>\n\n\n\n
What Happens When a Certificate\/Private Key is\nCompromised?<\/h2>\n\n\n\n
It May Sound Good, But Shortening Certificate Lifespan Isn’t\nPractical<\/h2>\n\n\n\n
How the TLS Delegated Credentials Extension Solves the\nProblem<\/h2>\n\n\n\n
![\"Graphic:](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/11\/delegated-credentials-1024x576.jpg\")
Greater Flexibility to Experiment with More Advanced\nEncryption Algorithms<\/h2>\n\n\n\n
You Can Try Delegated Credentials Yourself<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2019\/11\/fb-delegated-credentials-success2.png\")
<\/figure>\n\n\n\nA Final Word<\/h2>\n\n\n\n