We are moving fast to the encrypted world and the usage of TLS certificates increased dramatically.Security researcher Scott Helme discovered a way to break Certificate Revocation Checking Mechanism.
The process of getting a certificate has become more and more simple over time and now and it also free to get them.
In order to get a certificate, we should send a Certificate Signing Request (CSR) to the Certificate Authority (CA) and the CA will challenge us to prove our ownership of the domain. This is usually done by setting a DNS TXT record or Email based.
Once it has been satisfied CA will issue a certificate for you and then it needs to be installed on the server where our domain hosted to get green padlock and HTTPS in the address bar.
Public and Private keys
The certificates that we are using for HTTPS are public documents, we send them to anybody that connects to our site, however, the thing that stops other individuals utilizing our certificate is that they don’t have our private key. When a browser establishes a secure connection to a site, it checks that the server has the private key for the certificate it’s trying to use, this is no one can use our certificate. If an attacker gets our private key though, then it changes things.
When a browser establishes a secure connection to a site, it checks that the server has the private key for the certificate it’s trying to use, this is no one can use our certificate. If an attacker gets our private key though, then it changes things.
If some attacker steals your private key then they can prove that they are us. There are a number of ways that private keys are revealed by accident or carelessness.
Hope you remember Heartbleed, a small flaw with OpenSSL which allows attackers to steal your private key and you didn’t need to do anything mistakenly for it to happen.
If private key exposes then the only way to stop the attacker is by revoking the certificate by contacting CA Authority.
Certificate revocation
Once your certificate so that an attacker can’t abuse it. Once a certificate is marked as revoked the browser will know not to trust it, even though it’s valid. The owner has requested revocation and no client should accept it.
When we know we’ve had a compromise we contact the CA and ask that they revoke our certificate. We need to prove ownership of the certificate in question and once we do that, the CA will mark the certificate as revoked.
Browser doesn’t aware that certificate is revoked which is the problem and it will be sorted out with these two mechanism Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP).
Certificate Revocation Lists
A Certificate Revocation List (CRL) is a list of certificate serial numbers which have been revoked, are not any more legitimate, and should not be relied upon by any system user.
A CRL is generated periodically, the CRL is always issued by the CA which issues the corresponding SSL certificates. All CRLs have an (often short) lifetime in which they are valid and in which they may be consulted by a PKI-enabled application to verify a counterpart’s certificate prior its use.
To counter spoofing or denial-of-service attacks, CRLs are usually signed by the issuing CA and therefore carry a digital signature.
The problem with a CRL is that they contain a lot of revoked certificates from the particular CA. The other problem is that if the client doesn’t have a fresh copy of the CRL, it has to fetch one during the initial connection to the site which can make things look much slower than they actually are.
Online Certificate Status Protocol
The Online Certificate Status Protocol (OCSP) is an Internet convention utilized for acquiring the renouncement status of an X.509 computerized certificate.With OCSP we approach the CA for the status of a solitary, specific authentication.
This implies all the CA needs to do is react with a decent/renounced answer which is extensively littler than a CRL.
Truly OCSP offered a huge execution advantage over getting a CRL, When you send an OCSP request, you’re basically asking the CA this:
Is the certificate for gbhackers.com valid?
Hard Fail
Upon receiving the certificate, the browser will reach out to one of these services and perform the necessary query to ultimately ascertain the status of the certificate. What if your CA is having a bad day and the infrastructure is offline? What if it looks like this?
The browser has only two choices here. It can refuse to accept the certificate because it can’t check the revocation status or it can take a risk and accept the certificate without knowing the revocation status.
Both of these options come with their advantages and disadvantages. If the browser refuses to accept the certificate then every time your CA has a bad day and their infrastructure goes offline, your sites go offline too.
If the browser continues and accepts the certificate then it risks using a certificate that could have been stolen and exposes the user to the associated risks. It’s a tough call, but right now, today, neither of these actually happen.
Soft Fail
What actually happens today is that a browser will do what we call a soft-fail revocation check. That is, the browser will try to do a revocation check but if the response doesn’t come back, or doesn’t come back in a short period of time, the browser will simply forget about it.
Even is worse is that Chrome doesn’t even do revocation checks, at all. Yes, you did read that right, Chrome doesn’t even try to check the revocation status of certificates that it encounters.
Firefox looks like they will be joining the party very soon too.The problem we had with hard fail was obvious, the CA has a bad day and so do we, that’s how we arrived at soft fail. The browser will now try to do a revocation check but will ultimately abandon the check if it takes too long or it appears the CA is offline.
If you have an attacker performing a MiTM attack all they need to do is simply block the revocation request and make it look like the CA is offline. The browser will then soft fail the check and continue on to happily use the revoked certificate.
Adam Langley at Google came up with the best description for what revocation is, it’s a seatbelt that snaps in a car crash, and he’s right. You get in your car every day and you put your seatbelt on and it makes you feel all warm and fuzzy that you’re safe. Then, one day, things don’t quite go to plan, you’re involved in a crash and out of the windscreen you go. The one time you needed it, it let you down.
Fixing the problem
Right now at this very moment in time, the truth is that there is no reliable way to fix this problem, revocation is broken. There are a couple of things worth bringing up though and we may be able to look to a future where we have a reliable revocation checking mechanism.
Proprietary mechanisms
If a site is compromised and an attacker gets hold of the private key they can impersonate that site and cause a fair amount of harm. That’s not great but it could be worse. What if a CA was compromised and an attacker got access to the private key for an intermediate certificate?
That would be a disaster because the attacker could then impersonate pretty much any site they like by signing their own certificates. Rather than doing online checks for revocation of intermediate certificates, Chrome and Firefox both have their own mechanisms that work in the same way.
Chrome calls their CRLsets and Firefox call their OneCRL and they curate lists of revoked certificates by combining available CRLs and selecting certificates from them to be included. So, we have high-value certificates like intermediates covered, but what about you and I?
OCSP Must-Staple
To explain what OCSP Must-Staple is, we first need a quick background on OCSP Stapling. I’m not going to go into too much info, you can get that in my blog on OCSP Stapling, but here is the TL;DR.
OCSP Stapling saves the browser having to perform an OCSP request by providing the OCSP response along with the certificate. It’s called OCSP Stapling because the idea is that the server would ‘staple’ the OCSP Response to the certificate and provide both together.
At first glance, this seems a little odd because the server is almost ‘self-certifying’ its own certificate as not being revoked, but it all checks out. The OCSP response is only valid for a short period and is signed by the CA in the same way that the certificate is signed.
So, in the same way the browser can verify the certificate definitely came from the CA, it can also verify that the OCSP response came from the CA too. This solves the massive privacy concern with OCSP and also removes a burden on the client from having to perform this external request.
Winner! But not so much actually, sorry. OCSP Stapling is great and we should all support it on our sites, but, do we honestly think an attacker is going to enable OCSP Stapling? No, I didn’t think so, of course they aren’t going to.
What we need is a way to force the server to OCSP Staple and this is what OCSP Must-Staple is for. When requesting our certificate from the CA we ask them to set the OCSP Must-Staple flag in the certificate.
This flag instructs the browser that the certificate must be served with an OCSP Staple or it has to be rejected. Setting the flag is easy.
Now that we have a certificate with this flag set, we as the host must ensure that we OCSP Staple or the browser will not accept our certificate. In the event of a compromise and an attacker obtaining our key, they must also supply an OCSP Staple when they use our certificate too.
If they don’t include an OCSP Staple, the browser will reject the certificate, and if they do include an OCSP Staple then the OCSP response will say that the certificate is revoked and the browser will reject.
OCSP Expect-Staple
Whilst Must-Staple sounds like a great solution to the problem of revocation, it isn’t quite there just yet. One of the biggest problems that I see is that as a site operator I don’t actually know how reliably I OCSP staple and if the client is happy with the stapled response.
Without OCSP Must-Staple enabled this isn’t really a problem but if we do enable OCSP Must-Staple and then we don’t OCSP Staple properly or reliably, our site will start to break. To try and get some feedback about how we’re doing in terms of OCSP Stapling we can enable a feature called OCSP Expect-Staple.
Expect-Staple: max-age=31536000; report-uri="https://scotthelme.report-uri.io /r/d/staple"; includeSubDomains; preload
I’ve written about this before and you can get all of the details in the blog OCSP Expect-Staple but I will give the TL;DR here. You request an addition to the HSTS preload list that asks the browser to send you a report if it isn’t happy with the OCSP Staple.
Rogue certificates
One of the other things that we have to consider whilst we’re on the topic of revocation is rogue certificates. If somebody manages to compromise a CA or otherwise obtains a certificate that they aren’t supposed to have, how are we supposed to know?.
If I were to breach a CA right now and obtain a certificate for your site without telling you, you wouldn’t ever learn about it unless it was widely reported. You could even have an insider threat and someone in your organization could obtain certificates without going through the proper internal channels and do with them as they please. We need a way to have 100% transparency and we will very soon, Certificate Transparency.
Certificate Transparency
CT is a new requirement that will be mandatory from early next year and will require that all certificates are logged in a public log if the browser is to trust them. You can read the article for more details on CT but what will generally happen is that a CA will log all certificates it issues in a CT log.
These logs are totally public and anyone can search them so the idea is that if a certificate is issued for your site, you will know about it. CT is a fantastic idea and I can’t wait for it to become mandatory but there is one thing to note and it’s that CT is only the first step. Knowing about these certificates is great but we still have all of the above-mentioned problems with revoking them.
You can also use CertSpotter from sslmate to do the same and I use the Facebook Certificate Transparency Monitoring tool which will send you an email each time a new certificate is issued for your domain/s.
Certificate Authority Authorisation
Stopping a certificate being issued is much easier than trying to revoke it and this is exactly what Certificate Authority Authorisation allows us to start doing. Again, there are further details in the linked article but the short version is that we can now authorize only specific CAs to issue certificates for us instead of the current situation where we can’t indicate any preference at all. It’s as simple as creating a DNS record:
scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"
Whilst CAA isn’t a particularly strong mechanism and it won’t help in all mis-issuance scenarios, there are somewhere it can help us and we should assert our preference by creating a CAA record.
Conclusion
As it currently stands there is a real problem, we can’t revoke certificates if someone obtains our private key. Just imagine how that will play out the next time Heartbleed comes along! One thing that you can do to try and limit the impact of a compromise is to reduce the validity period of certificates you obtain.
Instead of three years go for one year or even less. Let’s Encrypt only issue certificates that are valid for ninety days! With a reduced lifetime on your certificate, you have less of a problem if you’re compromised because an attacker has less time to abuse the certificate before it expires. Beyond this, there’s very little we can do.
Note: This article was originally published in Scott Helme blog. All the Content of this Article Belongs to Original Author Scott Helme. GBHackers on Security won’t take any credits. This article has been  Published with all the Appropriate Permission. Credits $ Source are Belongs to Scott Helme
