Certificate revocation does not work
Right now we have a small problem, but in my opinion, over time, the situation can only get worse. More and more sites are receiving certificates - the necessary documents for implementing HTTPS - but we do not have a mechanism to protect against abuse.
We are now seeing a real gold rush around certificates, as more and more websites are adopting HTTPS. In addition to the obvious advantages of security and privacy, there are other benefits from the introduction of secure connections, which I listed in the article “ Do you still think that you do not need HTTPS? ". Usually referred to as "SSL certificates" or "HTTPS certificates" fly away at a speed that we have never seen in the history of the Internet. Every day I research sites from the first million in attendance and analyze various aspects of their security, and every 6 months I publish a report. You can study these reports here , but for now let's take a look at the pace of HTTPS implementation.
Percentage of sites from the first million of the most popular sites according to Alexa statistics, where there is a redirect to the HTTPS version
We do not just continue to implement HTTPS, but the speed of implementation also increases. This is what real progress looks like. The process of obtaining a certificate over time becomes more simple, thanks to the great Let's Encrypt , moreover, certificates have also become free. In short, we simply send a request for a certificate (Certificate Signing Request, CSR) to a certificate authority (CA), and he offers to prove the fact of ownership of the domain. This is usually done by changing the DNS TXT record or placing a special code somewhere at a random URL on our domain. Once the task is completed, CA issues a certificate, and we can show it to browsers and enjoy the green lock and an indication of HTTPS in the address bar.
')
I wrote a few instructions on this process, including where to start , how to correctly update and how to use double certificates . It's all great, isn't it? But what's the problem? And the problem will arise when everything goes wrong and you have a bad day.
No one would ever want to hear these words, but the reality is that we have to hear them more often than we would like. Hackers can get anything when they have access to our server, and often they need a secret key. HTTPS certificates are public documents that we send to each visitor to our site, but the only thing that prevents others from using the same certificate is the lack of our private key. When the browser establishes a secure connection to the site, it checks that the server has a secret key for the certificate used. That is why no one can use our certificate. If a hacker gets a secret key, the situation changes.
If the attacker has taken possession of our secret key, then he can impersonate us. To repeat it: someone on the Internet can prove that he is you, although in reality he is not. This is a real problem, and before you think, “This will never happen to me,” remember Heartbleed . This tiny bug in the OpenSSL library allowed an attacker to steal your secret key, even if you complied with all security measures. In addition, there were countless cases in which secret keys flowed due to chance or negligence. The reality is that we may lose our secret key, and when this happens, we need a way to prevent an attacker from using our certificate. We need to withdraw it.
In the event of compromise, we must revoke the certificate in order to eliminate the possibility of abuse. As soon as the certificate is marked as revoked, the browser knows that it cannot be trusted, even if it has not expired. The owner requested a review, and no client should accept this certificate anymore.
As soon as we learn about the hacking fact, we contact the CA and ask to revoke our certificate. You need to prove ownership of the certificate, and as soon as we have done this, the CA marks the certificate as revoked. Now we need a way to communicate this fact to every client who may need this information. Right at this moment the browser, of course, knows nothing, and this is a problem. There are two mechanisms that are used to disseminate information: these are the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP).
The CRL is really a very simple concept; it’s just a list of all the certificates that CA has marked as revoked. The client can send a request to the CRL server and download a copy of the list. Having a copy of this list, the browser verifies with him the certificate presented. If it is present there, then the browser knows that the certificate is invalid and cannot be trusted, it will then issue an error and break the connection. If the certificate is not listed, then everything is fine - and the browser will continue to work.
The CRL problem is that the lists contain many certificates from specific certificate authorities. Without going into unnecessary details, they are broken up into intermediate CA certificates, and the certificate authority can issue lists in smaller parts, but the problem remains the same. The CRL has a sizeable size. Another problem is that the client does not have a fresh copy of the CRL, he needs to request it during the initial connection to the site, which can make the whole procedure much slower. All this doesn’t look very nice, so let's take a look at OCSP.
OCSP offers a much more beautiful solution to the problem and has a significant advantage over the CRL. Here we ask CA for the status of a single, specific certificate. This means that the CA should return only a simple answer: the certificate is either good or revoked, and this answer is much smaller than the CRL. Fine!
Indeed, OCSP exceeds the CRL in the speed of receiving an answer, but you have to pay for this advantage (do you also hate when this happens?). The price is quite high - this is your privacy ... If you think about the essence of an OCSP request, this is a very specific request for a single HTTPS certificate. In fact, there is a leak. When you send an OCSP request, you literally ask the certificate authority:
So this is not a perfect scenario. You now give out the history of visited sites to a certain third party, about which you don’t even know anything, and all for the sake of HTTPS, which seems to be supposed to increase your privacy and security. But hey, there's more.
Above, I talked about CRL and OCSP, two mechanisms for checking certificates by the browser, and they look that way.
After receiving the certificate, the browser will contact one of these services and send a request for the final status of the certificate. And what if your CA has a bad day and its infrastructure is offline? What if the situation looks like this?
Here the browser has only two options. He may refuse to accept the certificate because he is unable to verify his status. Or take the risk and accept the certificate, not knowing its status, whether it is withdrawn or not. Both options have their advantages and disadvantages. If the browser refuses to accept the certificate, then every time the CA infrastructure goes offline, your websites also go there. If the browser continues to accept certificates, it risks accepting a certificate that has been stolen and puts the user at risk. This is a difficult choice, but right now, today, nothing really happens ...
In fact, today browsers perform a so-called certificate revocation check with a partial failure. That is, the browser will try to check the status of the certificate, but if the answer did not come at all or did not come in a short period of time, the browser simply forgets about it. Even worse, Chrome is not even trying to verify the certificate. Yes, you read it correctly, Chrome does not even try to check the status of the certificate that it receives. You may find this strange, but I completely agree with their approach and I am pleased to announce that Firefox is also likely to start working the same way soon. Let me explain. The problem with a complete failure is obvious: if CA has a bad day, then we too will have it, and this is how we came to the logic of partial failure. The browser is now trying to verify the certificate for revocation, but completely abandons it if it takes too much time or if it seems that CA has gone offline. Wait, what were the last words? Certificate verification for revocation is canceled, “if it seems that CA has gone offline.” I wonder if the attacker can imitate such conditions?
If you are performing a MiTM attack, then you only need to block the certificate verification request and create the impression that the CA is not working. The browser will then encounter a partial verification failure and continue to happily use the revoked certificate. If no one attacks you, then each time you verify this particular certificate, you spend time and resources on verifying that the certificate has not been revoked. And once, when you are attacked - the only time you really need such a check - the attacker simply blocks the connection, and the browser goes through a partial crash. Adam Langley from Google best described what a certificate revocation is: this is a safety belt that breaks at the time of the accident, and he is right. Every day you get into the car and fasten your seat belt - and it gives you a pleasant and comfortable feeling of security. And then one day something is not going according to plan - you get into an accident, and here you fly out into the windshield. The one time you really need it, the seat belt lets you down.
Right now at this particular moment in time, the reality is that we cannot remedy the situation. However, something can be done and, possibly, in the future, the mechanism for revoking certificates will become truly reliable.
If the site is compromised and the attacker received a secret key, then he can fake this site and cause some harm. There is nothing good here, but it could be worse. What if the CA is compromised and the attacker received the secret key for the intermediate certificate? This would be a disaster, because then an attacker can fake literally any site that he wants by signing his own certificate. Therefore, instead of checking online intermediate certificates for revocation, Chrome and Firefox have their own mechanisms for the same task.
In Chrome, it's called CRLsets , and in Firefox, it's OneCRL . These mechanisms check certificate revocation lists by combining the available CRLs and selecting certificates from there. So especially valuable certificates like intermediate are checked, but what about usual, ours with you?
To explain what OCSP Must-Staple is, you must first briefly understand what OCSP Stapling is. I do not want to go into unnecessary details here, you can get comprehensive information from my blog on OCSP Stapling , but here’s the gist. OCSP Stapling eliminates the need for the browser to send an OCSP request by issuing an OCSP response along with the certificate itself. This is called OCSP Stapling, because the server must “staple” the OCSP response with the certificate and issue them together.
At first glance, this seems a bit strange, because the server seems to be “self certifying” its own certificate as unrecognized, but everything works correctly. The OCSP response is valid only for a short time and is signed by the CA in the same way as the certificate. So if the browser can make sure that the certificate is signed by the CA, then just so it can make sure that the OCSP response is also signed by this CA. This eliminates the big privacy problem and relieves the client of the burden of executing an external request. The best way! But really not the best, sorry. OCSP Stapling is a great thing, and we all have to support this technology on our sites, but do we really think that the attacker will be supported by an attacker? No, I do not think so, of course he will not do that. What we really need is to make the server support OCSP Stapling, and this is what OCSP Must-Staple is for. When requesting our certificate from CA, we ask it to set the OCSP Must-Staple flag on it. This flag indicates to the browser that the certificate should come with an OCSP response or it will be rejected. Installing a flag is easy.
After setting this flag, we must ensure that OCSP Staple is used, otherwise the browser will reject the certificate. In the case of compromise, if an attacker receives our key, he will also have to use OCSP Staple along with our certificate, and if he does not enable OCSP Staple, the OCSP response will say that the certificate has been revoked and the browser will not accept it. TA-dah!
Although Must-Staple seems like a great solution for checking certificate revocation, this is not the case. In my opinion, one of the biggest problems is that I, as a site operator, cannot precisely know how reliable the OCSP Staple tags are and how the client accepts them. Without OCSP Must-Staple enabled, this is not a problem, but if you enable OCSP Must-Staple and we are not sure if OCSP Staple is reliable or correct, this is a problem for the site. To try and get some feedback on the quality of OCSP Staple tags, we can activate a feature called OCSP Expect-Staple. I’ve written about it before, and you can find out all the details on the OCSP Expect-Staple blog, but here I’ll also explain in brief. In addition to the HSTS preload list, you ask the browser to send a report if it is satisfied with the OCSP Staple tag. You can collect the reports yourself or use my service report-uri.io , in both cases you will know exactly when your site has encountered problems when running OCSP Must-Staple. Since the use of the HSTS preload list is not as obvious as I would like, I also wrote a specification for defining a new security header called Expect-Staple to provide the same functionality at the cost of less effort. The idea is that now you can set this heading and enable the function of sending reports that we need, even before the activation of Must-Staple. Setting the header will be as simple as all other security headers:
If we are talking about the revocation of certificates, we must consider the topic of their falsification. If someone tries to compromise the CA or somehow get a certificate that he was not supposed to, then how will he act? If I hack a CA right now and get a certificate to your site, then you won’t know about it until you’ll get it in the news. Your company may even have an insider who will receive a certificate in circumvention of internal procedures, and he will do whatever he wants with him. We need one hundred percent transparency, and soon we will get it. This is Certificate Transparency .
CT is a new requirement that will become mandatory at the beginning of next year. It provides that all certificates must be entered in a public journal in order for the browser to trust them. You can read the article with a more detailed description of the CT, but the point is that the CA logs all the issued certificates in the CT log.
These magazines are completely open, and anyone can see them, so if someone gets a certificate on your site, then you will know about it. For example, here you can see all the certificates issued for my domain and search for your own. There is also a CertSpotter service from sslmate for the same purpose, and I use the Facebook Certificate Transparency Monitoring tool, which sends you an email every time a certificate is issued for a given domain. The CT standard is a fantastic idea, and I can’t wait for it to become mandatory, but there is one reservation. The fact is that CT is only the first step. It’s good to know about these certificates, but we still have all the mentioned problems with their revocation. However, we can solve only one problem at a time, and even the best revocation mechanisms in the world are ineffective if we don’t know which certificates to revoke. CT at least gives us this information.
Preventing the issuance of a certificate is much easier than trying to revoke it, and this is why authorization of certificate authorities (CAA) is needed. Again, there are details in the article by reference, but the bottom line is that we can only authorize specific certificate authorities to issue certificates to us, in contrast to the current situation, when we cannot specify any preferences at all. Authorization is as simple as creating a DNS record:
Although CA authorization is not a particularly strong mechanism, and it is not able to help in all situations of incorrect issuance of certificates, but in some cases it is useful, so you should declare your preferences by creating a CAA record.
At the moment there is a real problem that we can not revoke a certificate if someone received our private key. Just imagine what this will mean when you unleash the next global Heartbleed scale vulnerability! One thing you can try to do is limit the amount of leakage damage by shortening the validity of your certificate. Replace three years with one year or less. Let's Encrypt issue only certificates that are valid for only 90 days! With a shorter lifetime for your certificate, the attacker will have less time for abuse. In addition, we can do little.
To demonstrate the problem and how real it is, try logging in to a new subdomain that I opened on my site, revoked.scotthelme.co.uk . As you can probably guess, a revoked certificate is attached to this subdomain, and it is likely that it will load normally in your browser. If not, if your browser issues an expired warning, it means that your browser is still sending OCSP requests and you just informed CA that you visited my site. To prove that such a soft fail check is useless, you can add the domain
I would like to end the article with a question: should we correct the procedure for revoking certificates? However, this is a topic for another article.
Certificates
We are now seeing a real gold rush around certificates, as more and more websites are adopting HTTPS. In addition to the obvious advantages of security and privacy, there are other benefits from the introduction of secure connections, which I listed in the article “ Do you still think that you do not need HTTPS? ". Usually referred to as "SSL certificates" or "HTTPS certificates" fly away at a speed that we have never seen in the history of the Internet. Every day I research sites from the first million in attendance and analyze various aspects of their security, and every 6 months I publish a report. You can study these reports here , but for now let's take a look at the pace of HTTPS implementation.
Percentage of sites from the first million of the most popular sites according to Alexa statistics, where there is a redirect to the HTTPS version
We do not just continue to implement HTTPS, but the speed of implementation also increases. This is what real progress looks like. The process of obtaining a certificate over time becomes more simple, thanks to the great Let's Encrypt , moreover, certificates have also become free. In short, we simply send a request for a certificate (Certificate Signing Request, CSR) to a certificate authority (CA), and he offers to prove the fact of ownership of the domain. This is usually done by changing the DNS TXT record or placing a special code somewhere at a random URL on our domain. Once the task is completed, CA issues a certificate, and we can show it to browsers and enjoy the green lock and an indication of HTTPS in the address bar.
')
I wrote a few instructions on this process, including where to start , how to correctly update and how to use double certificates . It's all great, isn't it? But what's the problem? And the problem will arise when everything goes wrong and you have a bad day.
Hacked us
No one would ever want to hear these words, but the reality is that we have to hear them more often than we would like. Hackers can get anything when they have access to our server, and often they need a secret key. HTTPS certificates are public documents that we send to each visitor to our site, but the only thing that prevents others from using the same certificate is the lack of our private key. When the browser establishes a secure connection to the site, it checks that the server has a secret key for the certificate used. That is why no one can use our certificate. If a hacker gets a secret key, the situation changes.
If the attacker has taken possession of our secret key, then he can impersonate us. To repeat it: someone on the Internet can prove that he is you, although in reality he is not. This is a real problem, and before you think, “This will never happen to me,” remember Heartbleed . This tiny bug in the OpenSSL library allowed an attacker to steal your secret key, even if you complied with all security measures. In addition, there were countless cases in which secret keys flowed due to chance or negligence. The reality is that we may lose our secret key, and when this happens, we need a way to prevent an attacker from using our certificate. We need to withdraw it.
Feedback
In the event of compromise, we must revoke the certificate in order to eliminate the possibility of abuse. As soon as the certificate is marked as revoked, the browser knows that it cannot be trusted, even if it has not expired. The owner requested a review, and no client should accept this certificate anymore.
As soon as we learn about the hacking fact, we contact the CA and ask to revoke our certificate. You need to prove ownership of the certificate, and as soon as we have done this, the CA marks the certificate as revoked. Now we need a way to communicate this fact to every client who may need this information. Right at this moment the browser, of course, knows nothing, and this is a problem. There are two mechanisms that are used to disseminate information: these are the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP).
Certificate Revocation Lists
The CRL is really a very simple concept; it’s just a list of all the certificates that CA has marked as revoked. The client can send a request to the CRL server and download a copy of the list. Having a copy of this list, the browser verifies with him the certificate presented. If it is present there, then the browser knows that the certificate is invalid and cannot be trusted, it will then issue an error and break the connection. If the certificate is not listed, then everything is fine - and the browser will continue to work.
The CRL problem is that the lists contain many certificates from specific certificate authorities. Without going into unnecessary details, they are broken up into intermediate CA certificates, and the certificate authority can issue lists in smaller parts, but the problem remains the same. The CRL has a sizeable size. Another problem is that the client does not have a fresh copy of the CRL, he needs to request it during the initial connection to the site, which can make the whole procedure much slower. All this doesn’t look very nice, so let's take a look at OCSP.
Certificate status verification protocol
OCSP offers a much more beautiful solution to the problem and has a significant advantage over the CRL. Here we ask CA for the status of a single, specific certificate. This means that the CA should return only a simple answer: the certificate is either good or revoked, and this answer is much smaller than the CRL. Fine!
Indeed, OCSP exceeds the CRL in the speed of receiving an answer, but you have to pay for this advantage (do you also hate when this happens?). The price is quite high - this is your privacy ... If you think about the essence of an OCSP request, this is a very specific request for a single HTTPS certificate. In fact, there is a leak. When you send an OCSP request, you literally ask the certificate authority:
Is the certificate for pornhub.com valid?
So this is not a perfect scenario. You now give out the history of visited sites to a certain third party, about which you don’t even know anything, and all for the sake of HTTPS, which seems to be supposed to increase your privacy and security. But hey, there's more.
Complete failure
Above, I talked about CRL and OCSP, two mechanisms for checking certificates by the browser, and they look that way.
After receiving the certificate, the browser will contact one of these services and send a request for the final status of the certificate. And what if your CA has a bad day and its infrastructure is offline? What if the situation looks like this?
Here the browser has only two options. He may refuse to accept the certificate because he is unable to verify his status. Or take the risk and accept the certificate, not knowing its status, whether it is withdrawn or not. Both options have their advantages and disadvantages. If the browser refuses to accept the certificate, then every time the CA infrastructure goes offline, your websites also go there. If the browser continues to accept certificates, it risks accepting a certificate that has been stolen and puts the user at risk. This is a difficult choice, but right now, today, nothing really happens ...
Partial failure
In fact, today browsers perform a so-called certificate revocation check with a partial failure. That is, the browser will try to check the status of the certificate, but if the answer did not come at all or did not come in a short period of time, the browser simply forgets about it. Even worse, Chrome is not even trying to verify the certificate. Yes, you read it correctly, Chrome does not even try to check the status of the certificate that it receives. You may find this strange, but I completely agree with their approach and I am pleased to announce that Firefox is also likely to start working the same way soon. Let me explain. The problem with a complete failure is obvious: if CA has a bad day, then we too will have it, and this is how we came to the logic of partial failure. The browser is now trying to verify the certificate for revocation, but completely abandons it if it takes too much time or if it seems that CA has gone offline. Wait, what were the last words? Certificate verification for revocation is canceled, “if it seems that CA has gone offline.” I wonder if the attacker can imitate such conditions?
If you are performing a MiTM attack, then you only need to block the certificate verification request and create the impression that the CA is not working. The browser will then encounter a partial verification failure and continue to happily use the revoked certificate. If no one attacks you, then each time you verify this particular certificate, you spend time and resources on verifying that the certificate has not been revoked. And once, when you are attacked - the only time you really need such a check - the attacker simply blocks the connection, and the browser goes through a partial crash. Adam Langley from Google best described what a certificate revocation is: this is a safety belt that breaks at the time of the accident, and he is right. Every day you get into the car and fasten your seat belt - and it gives you a pleasant and comfortable feeling of security. And then one day something is not going according to plan - you get into an accident, and here you fly out into the windshield. The one time you really need it, the seat belt lets you down.
Problem fix
Right now at this particular moment in time, the reality is that we cannot remedy the situation. However, something can be done and, possibly, in the future, the mechanism for revoking certificates will become truly reliable.
Proprietary mechanisms
If the site is compromised and the attacker received a secret key, then he can fake this site and cause some harm. There is nothing good here, but it could be worse. What if the CA is compromised and the attacker received the secret key for the intermediate certificate? This would be a disaster, because then an attacker can fake literally any site that he wants by signing his own certificate. Therefore, instead of checking online intermediate certificates for revocation, Chrome and Firefox have their own mechanisms for the same task.
In Chrome, it's called CRLsets , and in Firefox, it's OneCRL . These mechanisms check certificate revocation lists by combining the available CRLs and selecting certificates from there. So especially valuable certificates like intermediate are checked, but what about usual, ours with you?
OCSP Must-Staple
To explain what OCSP Must-Staple is, you must first briefly understand what OCSP Stapling is. I do not want to go into unnecessary details here, you can get comprehensive information from my blog on OCSP Stapling , but here’s the gist. OCSP Stapling eliminates the need for the browser to send an OCSP request by issuing an OCSP response along with the certificate itself. This is called OCSP Stapling, because the server must “staple” the OCSP response with the certificate and issue them together.
At first glance, this seems a bit strange, because the server seems to be “self certifying” its own certificate as unrecognized, but everything works correctly. The OCSP response is valid only for a short time and is signed by the CA in the same way as the certificate. So if the browser can make sure that the certificate is signed by the CA, then just so it can make sure that the OCSP response is also signed by this CA. This eliminates the big privacy problem and relieves the client of the burden of executing an external request. The best way! But really not the best, sorry. OCSP Stapling is a great thing, and we all have to support this technology on our sites, but do we really think that the attacker will be supported by an attacker? No, I do not think so, of course he will not do that. What we really need is to make the server support OCSP Stapling, and this is what OCSP Must-Staple is for. When requesting our certificate from CA, we ask it to set the OCSP Must-Staple flag on it. This flag indicates to the browser that the certificate should come with an OCSP response or it will be rejected. Installing a flag is easy.
After setting this flag, we must ensure that OCSP Staple is used, otherwise the browser will reject the certificate. In the case of compromise, if an attacker receives our key, he will also have to use OCSP Staple along with our certificate, and if he does not enable OCSP Staple, the OCSP response will say that the certificate has been revoked and the browser will not accept it. TA-dah!
OCSP Expect-Staple
Although Must-Staple seems like a great solution for checking certificate revocation, this is not the case. In my opinion, one of the biggest problems is that I, as a site operator, cannot precisely know how reliable the OCSP Staple tags are and how the client accepts them. Without OCSP Must-Staple enabled, this is not a problem, but if you enable OCSP Must-Staple and we are not sure if OCSP Staple is reliable or correct, this is a problem for the site. To try and get some feedback on the quality of OCSP Staple tags, we can activate a feature called OCSP Expect-Staple. I’ve written about it before, and you can find out all the details on the OCSP Expect-Staple blog, but here I’ll also explain in brief. In addition to the HSTS preload list, you ask the browser to send a report if it is satisfied with the OCSP Staple tag. You can collect the reports yourself or use my service report-uri.io , in both cases you will know exactly when your site has encountered problems when running OCSP Must-Staple. Since the use of the HSTS preload list is not as obvious as I would like, I also wrote a specification for defining a new security header called Expect-Staple to provide the same functionality at the cost of less effort. The idea is that now you can set this heading and enable the function of sending reports that we need, even before the activation of Must-Staple. Setting the header will be as simple as all other security headers:
Expect-Staple: max-age=31536000; report-uri="https://scotthelme.report-uri.io/r/d/staple"; includeSubDomains; preload Fake certificates
If we are talking about the revocation of certificates, we must consider the topic of their falsification. If someone tries to compromise the CA or somehow get a certificate that he was not supposed to, then how will he act? If I hack a CA right now and get a certificate to your site, then you won’t know about it until you’ll get it in the news. Your company may even have an insider who will receive a certificate in circumvention of internal procedures, and he will do whatever he wants with him. We need one hundred percent transparency, and soon we will get it. This is Certificate Transparency .
Certificate Transparency
CT is a new requirement that will become mandatory at the beginning of next year. It provides that all certificates must be entered in a public journal in order for the browser to trust them. You can read the article with a more detailed description of the CT, but the point is that the CA logs all the issued certificates in the CT log.
These magazines are completely open, and anyone can see them, so if someone gets a certificate on your site, then you will know about it. For example, here you can see all the certificates issued for my domain and search for your own. There is also a CertSpotter service from sslmate for the same purpose, and I use the Facebook Certificate Transparency Monitoring tool, which sends you an email every time a certificate is issued for a given domain. The CT standard is a fantastic idea, and I can’t wait for it to become mandatory, but there is one reservation. The fact is that CT is only the first step. It’s good to know about these certificates, but we still have all the mentioned problems with their revocation. However, we can solve only one problem at a time, and even the best revocation mechanisms in the world are ineffective if we don’t know which certificates to revoke. CT at least gives us this information.
Authorization of certification authorities
Preventing the issuance of a certificate is much easier than trying to revoke it, and this is why authorization of certificate authorities (CAA) is needed. Again, there are details in the article by reference, but the bottom line is that we can only authorize specific certificate authorities to issue certificates to us, in contrast to the current situation, when we cannot specify any preferences at all. Authorization is as simple as creating a DNS record:
scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"Although CA authorization is not a particularly strong mechanism, and it is not able to help in all situations of incorrect issuance of certificates, but in some cases it is useful, so you should declare your preferences by creating a CAA record.
Conclusion
At the moment there is a real problem that we can not revoke a certificate if someone received our private key. Just imagine what this will mean when you unleash the next global Heartbleed scale vulnerability! One thing you can try to do is limit the amount of leakage damage by shortening the validity of your certificate. Replace three years with one year or less. Let's Encrypt issue only certificates that are valid for only 90 days! With a shorter lifetime for your certificate, the attacker will have less time for abuse. In addition, we can do little.
To demonstrate the problem and how real it is, try logging in to a new subdomain that I opened on my site, revoked.scotthelme.co.uk . As you can probably guess, a revoked certificate is attached to this subdomain, and it is likely that it will load normally in your browser. If not, if your browser issues an expired warning, it means that your browser is still sending OCSP requests and you just informed CA that you visited my site. To prove that such a soft fail check is useless, you can add the domain
ocsp.int-x3.letsencrypt.org to the hosts with the IP address 127.0.0.1 or block it in some other way - and try to connect again. This time, the page will load normally, because checking a revoked certificate will not work, and the browser will continue to load the page. Sense from such a test ...I would like to end the article with a question: should we correct the procedure for revoking certificates? However, this is a topic for another article.
Source: https://habr.com/ru/post/332730/
All Articles