Some in the industry have responded to my post about the need for the revocation infrastructure.
They put forward an argument defending the need for short lived certificates by saying: “the main reason for them is to address the issue of key compromise“. They followed it by “The most important thing to keep in mind is that the nature of key compromise is such that you almost never know it has happened until it is too late.”
Well, I would say that, revocation can easily handle “key compromise” situation and do so by offering more security than short lived certs. Let me explain my logic.
First of all lets identify the parties involved:
SSL Owner (a website owner)
CA (Certification Authorities)
Now lets identify possible attacks:
Server compromise (somehow the server is hacked and owned)
Vulnerability (lets say a protocol vulnerability)
So lets draw a matrix with all potential scenarios of attacks on the parties and write down every single use case for when they are “aware” and “un-aware” of these attacks and what they would do in each and every scenario. Afterall, their action or inaction will be based on if they are aware or not.
Hmm….we have 8 different scenarios….Lets start with A1
A1) “SSL Owner” who has a “Server Compromise” and is “Aware” of the Compromise:
With Revocation infrastructure: The owner will simply revoke the certificate immediately and get a new one.
With Short Lived Certs: The owner will pray that the 89 days left on his/her certificate will expiry quickly!
A2) “SSL Owner” who has a “Vulnerability” and is “Aware” of the vulnerability:
With Revocation infrastructure: The owner will simply revoke the certificate immediately and get a new one.
With Short Lived Certs: The owner will pray that the 89 days left on his/her certificate will expiry quickly!
A3) “CA” who is aware of a customer’s “Server Compromise”:
With Revocation infrastructure: The CA will simply revoke the certificate immediately and inform the customer.
With Short Lived Certs: The Short lived cert CA does not care about revocation hence won’t do anything until 89 days passes and after 89 days if the compromise is still there the CA hopefully won’t issue the cert again.
A4) “CA” who is aware of a “Vulnerability”:
With Revocation infrastructure: The CA will simply revoke the certificate immediately and inform the customer.
With Short Lived Certs: The Short lived cert CA does not care about revocation hence won’t do anything until 89 days passes and after 89 days if the vulnerability is still there the CA hopefully won’t issue the cert again.
So if either CA or the SSL Owner is aware, then the advantages of a Revocation system is very clear to see……but how about if they are not aware……isn’t in this “un-aware” case that Short Lived Certs help? ….Lets take a look…..
U1) “SSL Owner” who has a “Server Compromise” and is “Un-Aware” of the Compromise:
With Revocation infrastructure: The owner is unaware hence won’t take any action.
With Short Lived Certs: The owner is unaware hence when the short term cert expires, he/she will get another one. (the knowledge about compromise is absent to prevent certificate acquisition).
U2) “SSL Owner” who has a “Vulnerability” and is “Un-Aware” of the vulnerability:
With Revocation infrastructure: The owner is unaware hence won’t take any action.
With Short Lived Certs: The owner is unaware hence when the short term cert expires, he/she will get another one. (the knowledge about vulnerability is absent to prevent certificate acquisition).
U3) “CA” who is un-aware of a customer’s “Server Compromise”:
With Revocation infrastructure: The CA is un-aware hence won’t do anything.
With Short Lived Certs: The Short lived cert CA is un-aware hence when the renewal is due it will simply re-issue. (the knowledge about compromise is absent to prevent certificate acquisition).
U4) “CA” who is un-aware of a “Vulnerability”:
With Revocation infrastructure: The CA is un-aware hence won’t do anything.
With Short Lived Certs: The Short lived cert CA is un-aware hence when the renewal is due it will simply re-issue.(the knowledge about vulnerability is absent to prevent certificate acquisition).
As you can see…Revocation infrastructure provides higher security for Internet users and Site owners if either CA or the SSL Owner is aware of the problem…..and neither revocation system nor the Short lived certs have any advantage over each other if parties are un-aware of the problem.
So in summary, short term certificates are NOT a replacement of “Awareness”. Just because you issue them at short intervals does not make you aware of the problem! And if you are unaware of the problem you will keep re-issuing short lived certificates “automatically”, because the knowledge about the problem is absent from the decision making process that triggers certificate issuance. And if you are aware of the problem, then with a revocation infrastructure you can revoke immediately and provide higher security than having to wait for a natural expiry of short term lived certificate which could be upto 89 days!
The benefits of a revocation infrastructure that is scale-able is unquestionable. Being able to provide a “status” information about a certificate instantly and on demand is a much better security posture than “having to wait” until certificate expiry (however short it maybe).
Creating standards for Revocation policies, arming browsers with detailed information about the reasons for revocation, creating SLAs for revocation that we can hold CAs accountable to is a safer world for end user, more secure world for site owners and less onerous world for computing infrastructure providers.
Revocation infrastructure that can support this is within reach! Lets protect 100% of the web, but do it without compromising end user security!
and now answering some questions…
Question: Doesn’t this kind of blind encryption provide privacy? Shouldn’t we be grateful that this encryption provides privacy?
Answer: That depends on how you define the word “Privacy”. If you can be sure that the “recipient” of the encrypted data is not the person you are trying to avoid, then you can say you have achieved privacy. As long as you do not know who ends up with your data, eg: you do not know who you are encrypting the data for, it is hard to claim you have privacy. Therefore any encryption that does not empower you with that knowledge of the “recipient’s identity” it will be very difficult to claim privacy. Contrary, people will have false sense of security and will think that they are being afforded privacy!